Theo on Token Costs, Coding Agents, and the Price of AI Capability

Lauren, known as poteto and the creator of pstack, has become a prominent agentic developer. A post claimed that the 1.5 trillion tokens on her Cursor profile represented $132 million a year. That is an astonishing figure, but it depends on assumptions about token pricing that I think are badly wrong.

Her profile shows 1.5 trillion tokens over 30 days. I use a lot of tokens myself and have not reached 100 billion, so her usage is extraordinary. The interesting question is what that aggregate actually costs, and what she is doing with it.

The broader lesson is to examine the numbers behind confident claims about AI. Peter's calculation starts with a real usage total, then assumes an average price of $8 per million tokens and arrives at roughly $11 million per month. That assumed rate is the part I dispute.

An aggregate token count combines cache reads, cache writes, ordinary input, and output. Those categories have very different prices. You cannot simply average a model's input and output prices and apply that figure to all tokens without knowing the mix.

For my own usage, mostly Opus 5.5, the average across all token types is about 41 cents per million, far below the $8 assumption. Cache reads and writes account for most of my spending, while ordinary input and output make up less than 8%. My mix does not prove Lauren's price, but it shows why the calculation needs more information.

Peter then assumes a 90% discount and compares the resulting annual bill with the cost of 26 senior engineers. I think that comparison misses the productivity enabled by agents: those engineers would also need tools and inference budgets. The discount and the underlying token mix are both assumptions, not facts established by the profile.

I speculate that Cursor's arrangements and Lauren's model mix could bring an effective aggregate rate down to around 20 cents per million, or about $25,000 a month under the same simplified calculation. Long agent runs may also produce more cache hits. These are estimates, and the aggregate number alone cannot establish the actual bill.

Consider the value alongside the cost. Companies sometimes spend more than that on events that attract less attention than a few of Lauren's posts. Her work also generates product feedback and code changes: I have seen improvements to Cursor and work on Grokbot. Marketing, engineering and research all belong in the discussion.

Depending on the mix, I speculate the effective rate could be lower still. I cannot infer a precise amount from the public profile, and even my estimates should not be treated as a bill. My main objection is that the $132 million headline takes an unsuitable average and treats it as known.

The other part of the argument is how fast inference cost falls for a given level of capability. An Artificial Analysis chart compares the cost per task at different intelligence-index thresholds. A frontier model can be expensive at launch, while later models reach a similar score for much less.

In the chart I cite, Sonnet 4.5 reached an index score above 20 at about 56 cents per task in September 2025; roughly a year later, GPT-6 Luna low reached that range at about 0.45 cents. At the next threshold, I compare $2.50 with about 3 cents. These are benchmark comparisons, not a guarantee that every real-world workflow becomes cheaper by the same factor.

This matters to the disagreement about whether lab employees understand real token budgets. I compare the early days of computers with people pushing the limits of agentic engineering today. Experiments can look extravagant at current prices while revealing workflows that later become affordable.

A critic argues that benchmark prices do not mean applied intelligence is getting cheaper. I think the distinction is that people often choose the newer, more capable model and do more with it. Spending may stay constant or rise while the price of a comparable capability falls, much as buying the latest phone can hide lower prices for an earlier generation.

I prefer newer small models such as GLM-5.3 Flash for long-running agent work over older frontier models. The improvement is not only a benchmark score: in my experience the newer model is more pleasant to work with and more reliable at taking successive steps. Retiring an inefficient old model does not erase the availability of a cheaper, more capable replacement.

I compared GPT-5's token rates with DeepSeek V4 Flash: the input rate was about 21 times lower and output about 55 times lower. Even allowing three times as many reasoning tokens, my calculation came out close to 20 times cheaper. The exact result depends on the workload and token mix.

Benchmarks have limitations, particularly when current models saturate old tests or the tests are poorly designed. But when inexpensive models now perform well on tests that challenged older systems, that is still useful evidence of progress. We need better, newer evaluations rather than dismissing every old comparison.

The objection is that a problem which cost ten cents to solve a year ago may still cost about ten cents today, and that difficult tasks have not improved in reliability at the same rate as benchmark prices. That is a fair distinction to investigate, but I disagree that it proves comparable intelligence has not become cheaper.

I tried an older model, GPT-4o, in an agent harness and found that it struggled to use tools and continue the task. Modern models can use the harness much more effectively. Comparing only the price of the final result can obscure the extra work an agent now does on the user's behalf.

I was wrong about this myself. When Windsurf added command execution, I dismissed it as a beginner feature: I thought I could run the command myself. I failed to anticipate how valuable it would be for a model to use a shell and other tools as part of its own workflow.

A comparison with three-year-old models is hard because the workflows were so different. You often had to set up the environment, locate the file and ask for a specific edit yourself. A modern agent can take a broader instruction and do much more of that work, so the tasks need careful definition.

To make a more controlled comparison, I ran SkateBench, a test involving naming skateboard tricks. It is not a complete measure of software engineering, but it provides a repeatable task. OpenAI's o1, released in December 2024, scored 67.7% at roughly 11.5 cents per question in my run.

Gemini 3 Flash, released exactly a year later, scored higher in the displayed result at about 0.2 cents per question: approximately 58 times cheaper. A later GLM Flash result scored 70.8% at about $0.00016 per question, which I calculated as roughly 680 times cheaper than o1. These are my benchmark results, not universal cost ratios.

At this pace, I expect the machine running the agent's tools and shell could eventually cost more than inference for some workloads. But the practical objection still matters: benchmark equivalence does not necessarily translate directly to outcomes in every application.

Take a bug fix. Previously I might reproduce the bug, find the right file, select code, ask a model to edit it, and manually restart and check the app. Now I can give an agent a screenshot and ask it to investigate, run the application and verify the fix. The ticket may cost a similar amount in tokens, but the human work has changed.

I chose SkateBench because I struggled to identify a real coding task that o1 could complete reliably enough for a clean comparison. Gemini 3 Flash performed better at a fraction of the cost. I asked my critic to provide real tasks from a year ago so I could test them as a benchmark; the disagreement remained unresolved.

My frustration is that people may welcome claims about AI prices because the claims fit what they already believe. I think cheaper inference also puts pressure on model providers' margins. The discussion should distinguish actual evidence about prices and outcomes from assumptions about what will happen.

Using my own rough estimate, I suggested that an equivalent level of capability might become much cheaper over the next year if the trend continued. That is a projection, not a promise. In practice, users may choose smarter models, tackle harder tasks and delegate more work instead of keeping the same workload.

Nor is Lauren's usage meant to be normal for every engineer. I see it as an unusual power user exploring the frontier. Her spending should be considered across engineering, research, product improvement and marketing, rather than judged solely as dollars spent to produce a fixed amount of code.

Lauren says she aims to be a power user so she can give useful feedback and improve the products. I have seen that work happen. If people want to question excessive token use, they should examine the purpose and the outcomes rather than assuming that a large aggregate number explains the experiment.

When a large numerical claim circulates, check the arithmetic and the assumptions. An AI assistant can help inspect a calculation, but the question is still whether the relevant inputs are known. In this case, an aggregate token count leaves out the pricing categories and agreements needed to determine the bill.

Look as well for arguments that substitute speculation about someone's motives for engagement with the numbers. I am sharply criticizing people I know because I think the claims are harmful to the conversation. I also want to acknowledge my own mistaken predictions about model limits, falling costs and agents running commands.

I have been wrong before and expect to say so publicly when the evidence changes. The goal is to understand the underlying information: what was measured, what was assumed, and whether a benchmark or price comparison actually answers the question being asked.