Posted by martinald 22 hours ago
In agentic coding, cached input tokens is 90% of the API "cost". It doesn't require GPU compute, and DeepSeek has shown that it can be done 50~100x cheaper with MLA/CSA/HCA, and a whole bunch of disks. This should collapse the margin.
> That is, for your $100/month fee, you get $3600 equivalent of API usage. This is presumably because Anthropic has figured out some clever things to do with model routing and input caching, and also can subsidize with investor money and take a hit on their operating margins.
My take: this is exactly what Anthropic wants everyone to think. In reality, 90% of that $3600 are for cached input tokens, that can be made to cost next to nothing, as shown by DeepSeek.
> The challenge is: when you let a session idle for >1 hour, when you come back to it and send a prompt, it will be a full cache miss, all N messages. We noticed that this corner case led to outsized token costs for users. In an extreme case, if you had 900k tokens in your context window, then idled for an hour, then sent a message, that would be >900k tokens written to cache all at once, which would eat up a significant % of your rate limits, especially for Pro users.
Using the current Opus pricing, that pre-lunch 900k tokens should roughly consist of:
720k input tokens = 0.72 x $5 = $3.6
180k output tokens = 0.18 x $25 = $4.5
900k 1h cached writes = 0.9 x $10 = $9
500M cached input tokens = 500 x $0.5 = $250
$267.1 in total, with 93.6% from cached input tokens. The portion that requires GPU compute is about 3% of the total.
Post-lunch, the 900k tokens should consist of:
900k input tokens = 0.9 x $5 = $4.5
900k 1h cached writes = 0.9 x $10 = $9
So Anthropic is fine with the $267.1 accumulated over 3~4 hours before lunch, but not fine with the $13.5 incurred immediately after lunch. Why?
The only plausible explanation is that the actual cost of caching is way less than the API pricing. If you use a coding plan, Anthropic doesn't really care about your cached input tokens usage. Indeed they want you to show your ccusage screenshots. On the other hand, if you pay by API tokens, the margin is huge for cached input tokens.
Only when you do something that requires a lot of FLOPs, e.g. the post-lunch 900k input tokens, the cost becomes real.
So it seems they do care.
Meanwhile, they don't really care if you use hundreds of millions of cached input tokens, which doesn't consume any FLOP.
Anthropic was extremely capacity constrained at that point. They still are but not to that extent.
I'd note that OpenAI offers 24 hour caching. I'd be surprised if Anthropic hasn't optimised their caching for Claude code too.
SemiAnalysis recently posted that their actual Opus usage works out at $0.99 because of caching.
The principles remain though.
Aren’t these techniques all “lossy” compression, and one of the reasons people complain about loss in quality as the context size grows larger?
We’re oohing and aahing about models, when the ones a few versions ago did a good enough job for most of the dumb coding, etc we do
Requirements evolve in use, and fully hands-off LLMs simply cannot be trusted to only change the things you ask them to change, so I don't think it's likely that products will, in the main, be developed that way.
And if you don't need that fully-hands-off stuff, then the models that run on at least reasonably modest desktop hardware are surprisingly close to being enough.
The future of AI most definitely involves making something twice as good as Fable that is virtually its own employee, and not on reducing inference costs because to be honest Fable isn't actually that expensive.
The real utility behind an AI model (imagining that it can be made twice as good as it is now) would be being able to scale a small business up and down instantly without hiring (to implement a new feature or whatever), which is costly and time consuming these days.
I've set up my own SearXNG instance on my VPS and integrated it into Pi alongside the webfetch tool, and GLM 5.2 has so far been great at finding things. I asked it to give me the current news from an Austrian online newspaper that's difficult to parse because of its aggressive ad overlays. Both ChatGPT and Claude failed in their native chat apps. GLM 5.2 in Pi was clever enough to search for the RSS feed and gave me a detailed overview.
The lack of vision is a real shame, though. I've implemented workarounds in Pi that are okay, but they're not as good and the whole experience feels awkward.
I also have my fork of metamcp that replaces firebase MCP spec with my own that tells the model to use crawl4ai and SearXNG instead.
I've been using this wia Librechat with every commercial and open weight model I tested.
The search is way better than OpenAI and what ClaudeCode uses, but Gemini is way faster. That will change soon as I'm planning to put these instances in a DC with gigabit pipe.
Firebase is not cheap, but it retrieves everything, bypasses captchas and so on.... As long as one uses it for 1% of Web queries the cost is manageable.
This is the key statement in the article. I think people don't realize that these "open" weight models exist because giving away your product at a loss is a time honored marketing strategy. There's nothing guaranteeing that the next iterations will be open (remember "Open"AI?).
The Chinese labs are profit seeking companies. If they can't recoup their investment through API use, they won't be able to train more models. But if the argument is 'who cares, training models will be so cheap anyone will be able to do it ',then check the comment elsewhere on this comment section about free alternatives for consumer and enterprise software.
Oh... And the variation 'what we have today is already good enough for everyone' argument is just another incarnation of '640Kb should be enough for everyone'.
https://github.blog/changelog/2026-07-01-kimi-k2-7-is-now-av...
Cursor Composer 2 and 2.5 are also fine tunes of Kimi K2.5
It looks like politics don't matter when it comes to economics.