Subscriptions are, and will likely remain, the best deal in town. Unfortunately, larger companies aren't able to do that. When your monthly token costs are in the $5-10k range, the local inference starts to look a lot more attractive
In the case where you pay for tokens without a subscription, the analysis is still very much not in favor of buying hardware.
The assumption previously used was that you can run a Sol level model on an M6 or whatever hardware $20k gives you. That is not true, it was an assumption made to show that even giving your own hardware every reasonable advantage it still loses.
Lets compare buying tokens of the best model you might run on your own hardware (still being unrealistic in favor of your own hardware) vs that same class of model on the market. I think one of the best models you might be able to run is GLM 5.4, but lets just look at chinese models generally:
$20k workstation, best case: $15k M5 Ultra 512GB, 36-month amortization, ~$440/mo. Runs a GLM-5.3-class model at ~30 tok/s. Saturated 24/7 it produces roughly 58M output tokens/month.
Buying those tokens:
DeepSeek V4 Pro @ $0.87/M $50
Kimi K2.6 @ $4.00/M $232
GLM-5.3 @ $4.40/M $255
Kimi K3 @ $15.00/M $870 (does not fit on the box)
The economics can never work in your favor for buying your own hardware here, unless you can utilize it or sell excess capacity and you have access to nearly free electricity. The reason is someone else can buy the same hardware at scale (or realistically more efficient hardware), park it somewhere with very cheap electricity, and sell tokens. They can get very high utilization that you are not likely to get.
And keep in mind I am giving 'your own hardware' no overhead or maintenance cost, despite your condition that it's in a large corporate environment. In reality corporate IT would make it almost impossible to set up and your would need huge lead times to buy the hardware and get it installed.
> $20k workstation, best case: $15k M5 Ultra 512GB, 36-month amortization, ~$440/mo. Runs a GLM-5.3-class model at ~30 tok/s. Saturated 24/7 it produces roughly 58M output tokens/month.
For agentic coding, ~90% of the cost comes from cached input tokens. This cost increases quadratically with the session length. If sessions go near 1M context, the number of cached input tokens can easily exceed 1B in a day.
So yes, at that speed for sure. But if the speed goes up? or the ability to batch at the same speed goes up? The economics start to shift. The gap is much closer, and you'd end up with a box you can still use or sell later.
As speed goes up the cost / Mtoken will necessarily go down at roughly the same ratio so it will wash out. The still use hardware or sell hardware value is factored in to the amortized monthly cost, it assumes a 3 year markdown, and does not factor in the cost of money which should almost cancel the resale value in the end, which I think is quite accurate (any residual cost on a graphics card after 3 years is so small compared to the current price it should be discounted and in included there).
Where you might win by owning your own hardware:
- Hardware costs go up, and thus api costs go up. You've locked in your pricing.
- Chinese/Open models become illegal/hard to access the way we do now. OpenAI and Anthropic are trying very hard to build a regulatory capture scheme to do this. I think they will be unsuccessful because China just won't participate.
Fascinating article. I daily catch LLMs in “lies” like: “I found the root cause of the bug” or “this approach is twice as fast”. It’s hard to say what causes this uninformed certainty - is it intrinsic to being trained on human writing, or something that comes from the RLHF process afterwards, but it’s extremely annoying. It’s one thing to have a LLM make poor decisions, but it feels worse to have it “lie” to you in the process.
This is a "don't make me tap the sign" moment. LLMs are next token prediction models. If there are factual errors, confused ideas, etc. in the preceding tokens, that will affect the generation of subsequent tokens, and the error accumulates.
Case in point, I hit an error in a SQL query today because it turned out I was trying to do something that wasn't supported by the query engine. I pasted the error message and a bit of background info into my Claude Code session with Sonnet 5 High, it worked on a response for an unexpectedly long amount of time, including consulting the advisor model, and then came back with an explanation of the mistake I made in my query. Except it turned out I pointed it to the wrong file, and there wasn't a mistake in that file. It had completely taken for granted that the pasted error output was a real error and went on some wild goose chase.
Part of why the current gen models feel so smart is that they're getting better (via CoT and training) at recognizing when something is wrong and then back up to reassess. So it's easy to forget that it really is just token prediction, and (pending the next big advancement) there's only so much you can do with that.
I don't see how "it's just token prediction" is relevant to that at all.
Sure, the model can go wrong, but sometimes it's able to realise that and correct its course. Stronger models are better at doing this.
People do exactly the same thing! Haven't you ever wasted a lot of time chasing down a blind alley?
To say the LLM has immutable limits because it only predicts the next token and can't backtrack is like saying we have immutable limits because we can't travel backwards in time. It's a true statement but not particularly relevant or helpful.
I have found it extremely helpful to keep the “token prediction machine” metaphor front and center in my work with llms, not because it expresses some fundamental limit of the technology but because it allows me to have a mental model about where and how to use the technology in my process.
Contrast this to the “chat” mental model. If you are chatting with someone and they lie to you, that is a transgression. A bad prediction is just a normal outcome. These are _human_ judgements but you address transgressions differently than normal but incorrect outcomes. That’s a helpful distinction for me when building my tooling.
If anything, that we are getting so much traction out of text prediction is the most magical part of llms. But it doesn’t change that you shouldn’t treat what they output the same as what a human says.
Hmm, what specific differences does it make in practice?
For me, the huge one is that LLMs are currently bad at learning from experience. I don’t trust any kind of automatic MEMORY.md or whatnot; in fact I greatly prefer starting from a clean slate each time because the LLM’s baseline general knowledge is so good.
In terms of accuracy and “lying”, I don’t really see a huge difference. Most LLMs are unfortunately a bit sycophantic and over-confident, but you sometimes see that in people as well.
The biggest difference is I view any interaction with an llm that doesn’t produce an artifact that can be verified with skepticism.
That is I very rarely even use a “chat” interface anymore. Under the covers I’m still using the mainline agents but I’m treating them more like black box Unix tools that take text in and spit text out.
My interactions are evolving to have very small llm cores wrapped with old fashioned deterministic programming.
This makes the boundary/verification step more deterministic and less susceptible to bad predictions. But it also has the side effect that I rarely interact with llm output that has “tone” (for instance sycophantic output). That usually only happens when I’m debugging what went wrong, particularly around model upgrade cycles.
> People do exactly the same thing! Haven't you ever wasted a lot of time chasing down a blind alley?
Thus is why I think calling out that it is just predicting tokens is relevant. LLM are trained on human written communication. Humans say they found the root cause often, so the LLMs say it often. Even when not true.
Idk if thats true or not, but LLMs mimicking some average speech written pattern isnt crazy to me.
LLMs aren’t just blindly parroting human speech, though -- they’re not trivial Markov chains any more, copying words and phrases at the surface level.
You can argue back and forth about whether LLMs are actually “conscious”, whatever that means, but it’s clear that they can be tremendously effective and useful. They can use language to get stuff done.
This line of thinking is quite confusing to me. If you keep following it then ultimately we must reckon with the reality that we only experience time in one direction. While it might be technically true that "there is only so much you can do with that" I think it might also be a completely useless statement to make.
I think it provides a necessary pointer to the idea that we will need more than prediction to make a viable general AI - that the prediction model is useful, but has fundamental limitations.
> Except it turned out I pointed it to the wrong file, and there wasn't a mistake in that file.
That’s a fairly common error, on my part. I may have a wrong file, selected in the Xcode Navigator, and the LLM accepts that, as the problematic file. In other cases, I’m just plain wrong, in my diagnosis. Maybe the error manifests in that file, but is caused, in another one. I have taken to giving the LLM as many involved files as possible, when asking for help.
I found that, as the LLM progressed through my project, learning more and more about it, it caught these errors, but early on, it ran with my wrong input, and gave bad advice.
It still, occasionally, gives bad advice, but that’s just because it was probably trained on bad code. I have found that it gives good advice, more often than not. It’s just incumbent on me, to treat its input as “advice,” and carefully consider it, before integrating it into my own work.
I have just upgraded my account. In order to do this, I had to create a new one, for billing purposes. This means that it needs to start over, learning the project. I am in the process of exporting from the previous account, but I’m not sure how well this will transfer the accumulated knowledge.
> as the LLM progressed through my project, learning more and more about it… This means that it needs to start over, learning the project. I am in the process of exporting from the previous account, but I’m not sure how well this will transfer the accumulated knowledge
LLMs don’t learn though. Are you talking about some sort of architecture.md file collection being built? This files should be just easy to copy?
Oh, no. The LLM definitely learns my project. It learns my coding and documentation style, and remembers files. Sometimes, that's a pain, as it remembers old versions of files, and disregards newer ones.
That's actually a real advantage. Right now, I am getting it to compile a tutorial for the app. Since it's starting from scratch, I can't rely on it remembering much, so I have to "start from the beginning," and give it a lot of information that the other account already had.
ChatGPT, as a chat interface. I just switched from Plus to Pro. There may be a file, but I haven't seen it, and I know that the export process is non-trivial (it said it would "take several days").
IIRC ChatGPT does use "memory" systems to maintain familiarity with a given chat's subject.
I believe that's an important ingredient for creating AI psychosis - human and AI become slowly more unhinged together in a feedback loop until it finally spirals out of control.
Ungrounded LLM outputs are a bit like your dreams. Without anything to test hypotheses against, stuff can pop in and out of existence and physics is just advice.
Ground your LLM. Tests, documentation, give it many ways to run the thing its reasoning about. It needs to be able to test its hypotheses on its own.
Take yourself out of that loop so you only find out once it's sure.
That’s exactly why I don’t believe LLMs will cure cancer anytime soon, make terrible lawyers, shouldn’t be trusted for medical decisions, etc. software and maths are some really the niches where we have great, battle tested, reliable validation tools. That’s not the case for “softer” domains
Software is a very "spiky domain"; things either work or fail, and there is sharp delineation between and easy verification.
Hm. Two orthogonal properties! This sounds like a 2x2 matrix!
Let's swap hard/easy around & explore the 4 possibilities...
There are domains with sharp delineation and hard verification; they are not at risk until AI gets much better. Humans operate in these domains by applying tremendous deep thought and subjective judgment - our superpower.
Domains with soft delineation and easy verification are most at risk: "it's a picture of a cat" remains true through a wide range of perturbations - eg. skewing the image or moving it across a pixel or correcting its white balance or even changing the cat. AI music? Lots of domains already solved by AI here but they're also not that meaty.
My prediction is the next interesting stuff will happen where verification is hard but there's no sharp delineation. It's the world of "I'll know it when I see it". Good customer service?
The only people who think LLMs would make good lawyers are the people selling LLMs. The more practical among us recognize that LLMs are our amazing tools for searching through and making sense of large amounts of text with a high level of sophistication, which can significantly enhance the productivity of a human lawyer.
And they are, at least for Claude I know it writes random mocks and tests in its virtual env even in the web version, cause it sometimes annoyingly includes them in the final result. It's the only reason it produces anything that runs.
Love LLMs gonna keep using them. It feels like your suggested approach is expensive, in terms of tokens. I feel (second time I say this) that when I steer the process I get pretty good results vs my coworkers that let the LLMs run away. I do have data on our token usage, not much in terms of quality of the delivery.
I keep thinking about the c compiler implementation that anthropic shared earlier in the year that had all the requirements you mention and arguably wasn’t that great.
Thr thing is that both you and your agent should have a way to verify the solution.
OBVIOUSLY, the compiler experiment was just a cringe pr stunt. But it has a point: everything works better with a good testing loop, and compilers always have one by thr nature of the work they do
> It’s hard to say what causes this uninformed certainty - is it intrinsic to being trained on human writing, or something that comes from the RLHF process afterwards
LLMs are trained to produce some form of output that is NOT nothing/dunno. The so called hyperspace collapses onto something, instead of collapsing onto lack of answer tokens.
If you watch the thinking traces of just about any modern LLM, you might be surprised at how much "uncertainty" is in there. Weak models with no thinking limits vacillate back-and-forth back-and-forth on a topic for potentially thousands of tokens before gradually spiraling towards some kind of an answer. Which makes it all the more interesting that "I don't know" is so rarely the final prediction, even with so much waffling in the chain of thought.
Until the big labs decide to start adding synthetic "I don't know" outcomes to their data sets, I've been thinking that the best way to evaluate uncertainty is to have a separate LLM monitoring the conversation and asking it to classify if the agent is overstating its confidence. On the other hand I've also noticed that most models will tell you they don't know something if you specifically include it in the prompt, eg "if you don't know the answer, just say so" and/or "be clear about any gaps in your knowledge that would reduce the confidence of your response" etc. but even with the big frontier models I have noticed some quality degradation if I throw too many instructions into the system prompt. I have a little more faith in harness-level engineering than in praying to the token generation gods.
That said, there is a completely different form of "uncertainty" in which the LLM tends to place very high trust in its own prior outputs as well as user provided inputs. Again if you look at the thinking traces, these models will try very very hard to rationalize the inputs they are given, falling back to the possibility of user error only after working through several alternative possibilities, maybe even investigating data or source code in the process. And if your context is big enough, the model might just completely miss when pieces of information conflict.
LLM aren't logic machines. It's concepts of "root cause" and "faster" are purely linguistic, including all the internal conflicts of those loose definitions.
In that sense an LLM wouldn't even think it "lied" being confidently incorrect, in human terms it's just a "whoopsie". Apparently we want exactly that.
More accurate to say restaurants are about people, not food. May be an apt analogy - chefs and cooks spend their time in the kitchen preparing food for a diner they don’t see.
This makes me think - should we be using non-monospace fonts for coding agent chat to improve readability? Wonder if we can get Claude and Codex to do that automatically in supported terminals
I've been using proportional fonts for programming for more than thirty years. Makes things much easier to read and it's only a problem where people try to make patterns out of the code
Nope. It might improve readability for individual words, but for blocks of code with similar features at irregular lengths, uniform kerning provides structure and a bunch of clean edges that help you visually orient yourself. Just like title text and body text generally need different kerning, so do body text and code.
(As a full time developer for over a decade that got a design degree, I have experimented with it a lot!)
In contrast, I’m on the $200 max plan for Codex and I hit the 5 hour limit near daily at work. I typically am having it work on about 5 tasks an hour. I’ve never hit a 5 hour limit on Claude on the $200 plan but I have hit my weekly limit.
reply