Yep, most wealth is ultimately dependent on some kind of ability to scrape off tiny bits of practical accomplishments of value achieved by large numbers of people. In some cases, such as your housing example, this is a very direct dependency. In other cases the dependency is indirect and less visible.
The smarter ones among the rich have realized this and are open for something like a universal basic income precisely for that reason: to protect their wealth and the position in the food chain this wealth affords them.
OpenRouters moat is that a) everyone knows it, but not their gazillion competitors, and b) their API URLs and key are already configured in your OpenCode/Oh-my-Pi/whatever harness or agent you use.
As long as they offer stable services and do charge the same API prices as competitors (or even less maybe, since they have the most inference providers on board, because OpenRouters' prime popularity also exists with inference providers) you do not really have an incentive to go through the hassle of changing all your configurations.
They are reselling inference. That is not a novel concept, indeed, a stationary merchant like Walmart does conceptually the same. Although since inference doesn't require any stockkeeping, I would rather compare it to Amazon Marketplace.
But it's been novel for inference services when OpenRouter was founded. And nowadays they have a considerable foothold in the market. There are competitors, but the one everyone knows is OpenRouter.
And since they do not need to maintain any stock, don't need to do anything with queries but route them through 1:1, the most complex thing they do from a business perspective is that they collect your money and route the right amounts to various inference providers that served you.
And you do not have flat priced quota for Fable 5, right? Because nobody has, as far as I know. So you'll probably not route any task to the "current best available SOTA".
Also: quota. Implies you do not have unlimited access even for flat prices. Which in turn implies that as soon as you hit the quota on the most expensive flat price plan, even you will suddenly discover the magic of economically sensible behavior.
OpenRouter is basically a payment system for LLM tokens. Yes, it does route TCP connections from you to an inference providers' cloud, too, but what is way more important is that it routes money from your wallet to inference providers'wallets.
The latter is the core business of Stripe. For them, buying OpenRouter to become the premier channel for LLM token money makes perfect sense. At least if you assume that the current state of labs offering heavily subsidized subscriptions directly is only temporary and the future lies in people buying tokens and switching between models fluidly - and I consider that the future, in light of the recent developments with Kimi K3.
They are simply out of ideas to keep the most expensive party in the history of mankind going.
That's it. Simple as that. When you grasp for straws in panic mode, you don't exactly spend time strategizing and weighing the pros and cons of each straw carefully.
The speed at which tokens are crunched, even on the same hardware, differs between models as well. Using more tokens is only a problem if they are processed at the same speed as with a comparison model.
I'd guess the slowness is mostly due to there currently being only one provider, Moonshot AI. And they are overwhelmed with demand.
Let's judge the speed of the model when its weights are released and every inference provider on the planet offers it, so demand can spread out a bit.
It's the same topic with token budget comparisons and subscription pricing - don't people understand that this doesn't really matter for open weights models? The pricing is going to be determined by the inference providers, and until they had a chance to evaluate the model on their infra and set token prices accordingly, one doesn't really have anything tangible to compare with other open models nor with closed ones.
OpenCode exists, it is your "open source coding agent" that is practically on par with Claude Code and Copilot in terms of being able to do the 80% of things that most people actually use.
DeepSeek v4 Flash/Pro also exist, they are open weight and on par with Sonnet, just a bit below Opus. Again: practically useful and sufficient for 80% of things most people actually do. And most of the remaining 20% are benchmarks designed to push the limits, not productive work.
Using these already is way cheaper than your typical Claude API prices. What's still missing is a) mindshare - everyone still thinks "claude = coding" and everyone thinks he/she really needs the very best models because he/she is doing such incredibly complex stuff - and b) someone pushing such a stack as a convenient solution for corporations to easily dump their token money into, complete with user management, enrollment, monitoring, all that enterprisey stuff you need if you want to sell to, well, enterprise customers.
True, it's very useful for scammers, grifters, international terrorists and authoritarian governments to funnel monetary value around without having to rely on the traditional financial system where they may be blocked and their money confiscated.
I think the main reason is to minimize the market for closed-source models from US companies.
China knows that doing what Anthropic/OpenAI/Google/... are doing is impossible for them. No one outside of China in any sane condition will send their data to compute farms IN CHINA like people currently do with US-based frontier models. Even if they could muster the inference power.
Hence they do the second-best thing possible to attack the dominance of the US-based corporations: reduce their moat by open-sourcing models that are not fully equal, but practically useful and good enough for easily 90% of typical tasks people use agents for in their daily lives. But way cheaper to run.
As long as this arms race in AI continues, China as "number two" will have some incentive to continue open-sourcing models. But of course the US government might force a change if they continue to enforce limited public access to new frontier models - there is no market to minimize if a model is not allowed to be publicly available.
They captured like 90% of the German ticket market by closely watching Ticketmaster and basically repeating their playbook. Eventim also owns some venues, has exclusive contracts with many of them it doesn't outright own, hosts an official fan resale site, offers promotional services and generally integrates a lot of the business around large events vertically.
What's actually interesting is that it seems to be possible to compete with Ticketmaster only by copying their playbook on a large-enough scale, and Germany appears to be large enough. The Netherlands right next to Germany don't seem to have been large enough, as Ticketmaster basically controls them.
The typical job of a CTO is nowhere near "finding out what business needs and translate that into pieces of software". The CTO's job is to maintain an at least remotely coherent tech stack in the grand scheme of things, to develop the technological vision of a company, to anticipate larger shifts in the global tech world and project those onto the locally used stack, constantly distilling that into the next steps to take with the local stack in order to remain competitive in the long run. And of course to communicate all of that to the developers, to set guardrails for the less experienced, to allow and even foster experimentation and improvements by the more experienced.
The typical job of a Product Manager is also not to directly perform this mapping, although the PM is much closer to that activity. PMs mostly need to enforce coherence across an entire product with regard to the ways of mapping business needs to software features that are being developed by individual developers. They still usually involve developers to do the actual mapping, and don't really do it themselves. But the Product Manager must "manage" this process, hence the name, because without anyone coordinating the work of multiple developers, those will quickly construct mappings that may work and make sense individually, but won't fit together into a coherent product.
Developers are indeed the people responsible to find out what business actually wants (which is usually not equal to what they say they want) and map that onto a technical model that can be implemented into a piece of software - or multiple pieces, if we talk about distributed systems. Sometimes they get some help by business analysts, a role very similar to a developer that puts more weight on the business side of things and less on the coding side - but in a lot of team constellations they're also single-handedly responsible for the entire process. Good developers excel at this task and find solutions that really solve the problem at hand (even if they don't exactly follow the requirements or may have to fill up gaps), fit well into an existing solution (even if that means bending some requirements again, or changing parts of the solution), are maintainable in the long run and maximize the chance for them to be extendable in the future when the requirements change. Bad developers just churn out some code that might satisfy some tests, may even roughly do what someone else specified, but fails to be maintainable, impacts other parts of the system negatively, and often fails to actually solve the problem because what business described they needed turned out to once again not be what they actually needed. The problem is that most of these negatives don't show their effects immediately, but only weeks, months or even years later.
LLMs currently are on the level of a bad developer. They can churn out code, but not much more. They fail at the more complex parts of the job, basically all the parts that make "software engineering" an engineering discipline and not just a code generation endeavour, because those parts require adversarial thinking, which is what separates experts from anyone else. The following article was quite an eye-opener for me on this particular topic: https://www.latent.space/p/adversarial-reasoning - I highly suggest anyone working with LLMs to read it.