Top
Best
New

Posted by martinald 22 hours ago

GLM 5.2 and the coming AI margin collapse(martinalderson.com)
650 points | 424 commentspage 2
throwdbaaway 20 hours ago|
Seems like a pretty pointless post that still centers around output tokens.

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.

nozzlegear 19 hours ago||
Aren't the American AI labs desperately struggling to find a market beyond just agentic coding?
le-mark 18 hours ago|||
I have heard but don’t have first hand knowledge that at least one company (financial services BPO) has moved most of their previously manual processing to llms. The person I talked to wasn’t forthcoming with any detail. This is what we’d expect to see though.
dgellow 12 hours ago|||
All AI labs. Not just Americans
throwdbaaway 19 hours ago|||
The current top comment in https://lobste.rs/s/ua1gxl/glm_5_2_coming_ai_margin_collapse correctly zoomed into cached input tokens, but landed on the opposite conclusion:

> 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.

throwdbaaway 19 hours ago||
While we are all speculating, Boris kindly provided some guidance in https://news.ycombinator.com/item?id=47880089

> 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.

Roark66 4 hours ago|||
Recently I started getting messages from Clause Code (on a plan). "You're restoring an old session are you sure you don't want to compress the context? This will use a substantial amount of your usage quota"

So it seems they do care.

throwdbaaway 2 hours ago||
That's exactly what I said. They do care when FLOPs are involved. Restoring an old session with 900k tokens will require a lot of FLOPs to reprocess the 900k token.

Meanwhile, they don't really care if you use hundreds of millions of cached input tokens, which doesn't consume any FLOP.

nl 9 hours ago|||
I wouldn't be too fixated on the specific numbers in that post.

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.

stingraycharles 19 hours ago||
> MLA/CSA/HCA

Aren’t these techniques all “lossy” compression, and one of the reasons people complain about loss in quality as the context size grows larger?

throwdbaaway 19 hours ago||
Indeed they are all lossy. Not sure how much they contribute to the quality loss in long context though. I got a 700k session with DSV4 Pro (official API), and the model was still coherent and didn't make any tool call error.
stingraycharles 17 hours ago||
That’s a low bar though, and the least I would expect.
throwdbaaway 13 hours ago||
Well I wouldn't call it a low bar, since some of the edits were quite complex. And 1M context in less than 6GB of VRAM is truly impressive, but somehow this gets way less attention than the crappy turbo quant from Google.
scope2093 12 hours ago||
I'd like to understand this please. Why would the 1M context be kept in VRAM if you're using DSV4 Pro through the API? Or did you refer to different sessions?
throwdbaaway 11 hours ago||
Different sessions. With https://github.com/fairydreaming/llama.cpp/tree/dsv4, 1M context with DSV4 Flash takes less than 6GB of VRAM. I can't run DSV4 Pro, but it should take less than 9GB of VRAM for 1M context, based on the numbers shared in https://arxiv.org/html/2606.19348v1.
scope2093 10 hours ago||
Thank you for the links/docs. I'm quite excited to try it myself.
softwaredoug 20 hours ago||
I also think we’ll approach a point where increasing intelligence is not really going to suddenly improve most work tasks. I bet that’s already happened actually.

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

dofm 19 hours ago||
The thing is they are inventing new things people will want to do. But for example, "loops", fully hands-off agentic coding etc., seem really unlikely to get much traction because that just isn't how software is designed within its producer/user community.

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.

Havoc 13 hours ago|||
I’ve been on a GLM coding plan since they launched ~year ago and it’s been at „good enough“ since the start. Tangible behind absolute SOTA but like you say most coding isn’t rocket science.
aetherspawn 18 hours ago||
I don’t think this is true. All the models prior to Fable were honestly dumb as rocks, and Fable is too sometimes, but at least it’s helpful now and not a hindrance.

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.

peepee1982 12 hours ago||
There is mention of GLM 5.2's poor web search capabilities, but I see that as a harness responsibility.

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.

xienze 6 hours ago|
[dead]
throwthrowuknow 8 hours ago||
I don’t see it. GLM 5.2 seems noticeably worse than Opus and especially GPT 5.5, the poor vision capabilities are also a massive strike against it since these are a huge improvement in the frontier models that can make all the difference when working on anything visual. Running it locally is its biggest advantage but for a lot of use cases that isn’t needed and is a burden to set up and maintain.
cmiles8 5 hours ago||
Companies like Amazon taking out loans to fund more AI infrastructure, coupled with AI companies that are massively overvalued and burning cash, coupled with companies saying there’s no ROI from AI investments, coupled with the margin from selling AI models trending to zero paints a nasty picture that can’t continue much longer.
devinodowd 8 hours ago||
I wonder if anyone has actually measured the difference in verification time between these models. A senior dev in a high cost of living area costs the company something like $200 an hour. If a cheaper model produces code that takes an extra 20 minutes to debug or verify because it missed a subtle edge case, you have already lost any savings from the lower API bill. It feels like the real moat for labs like Anthropic is the level of trust a reviewer can have in the output without reading every single line. Curious how much people trust GLM over something like Opus? Is there much of a marginal difference here?
tokoi 5 hours ago|
[flagged]
mountainofdeath 1 hour ago||
History is littered with the corpses of companies that had exceptional but expensive products that were replaced with cheap, good enough products.
Roark66 4 hours ago||
The author mentions lack of good Web search. I've been using slightly modified crawl4ai and searXNG together with firebase for the rare sites that insist on throwing wrenches in the works of my LLMs.

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.

wartywhoa23 5 hours ago||
An entertaining thread on just what a dismal rat race the life of a clanker shepherd has become.
glimshe 6 hours ago|
"There is no doubt that using Z.ai's official API and subscription is almost certainly a non-starter, with their terms being at best weak and the deep connection to Mainland China."

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'.

lukax 6 hours ago|
Well, Microsoft just started offering Kimi K2.7 through Copilot hosted on Azure.

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.

More comments...