> I'll bite. I suspect that these plans aren't as intensely subsidized as people assume. I believe that API usage is probably also not subsidized at all. First, yes, subs are probably subsided, but I bet a significant % of users are profitable to serve, especially the "chat" users who don't use dev tools and have short context window conversations. Yes, I think the subs also exist as a driver to get lock-in and market share. Claude Code, for example, is very good and I stopped using their competition when they released their superior product.

I somewhat agree, somewhat disagree with this. I think API based is not subsidised. If you do some basic napkin math they should have enough room there to serve the models below cost if the models aren't insanely large (you can compare with 3rd party openrouter offerings and have an idea of what $/Mtok you can serve per model size. e.g. Haiku level models can be ~700B tokens and still be profitably served)

I think 20-200$ all-you-can-prompt are likely subsidised. If you track token usage (there are many 3rd party tools that do this) you can get 4-5x the API usage out of them (it used to be even higher before they added weekly limits. People were seeing 10-20x usage). Now I think that's a bit tough to make the napkin math work out. I've compared sessions served over API with sessions from subscriptions, and you get much more usage out of them, even with 5h / weekly limits. Strictly for coding, I think they're subsidising them.

I somewhat disagree that they're doing it for market share / user lock-in. I think signals and usage trends are much more valuable for them. While there might be user retention for "casual" users (i.e. web) I think the power users in coding will move as soon as the competition has a better product. So at the end of the day having data to improve models and have the "best" model in a niche is more productive than retaining users with an inferior product. That is an assumption tho, and there isn't much math you can do to figure that out from the outside.