The Anthropic prospectus: AI is getting more efficient. But who knows the real costs?

Ok, first this: congratulations. What Anthropic has delivered this year is a top performance, and the early investors may be pleased, and with them everyone who could buy stakes in the funding rounds before the planned listing; the company is not on the stock exchange yet, the prospectus is filed, there is no date. The last round in May valued the company at 965 billion dollars, and at the end of June, according to the prospectus, 112 billion in cash and 19 billion in short-term investments were in the till, around 130 billion together. There is still a lot of money there. So, and now one thing up front: all numbers in this article are in the IPO prospectus Anthropic filed on 26 October, or in reports that analyse it, and they are linked below. What I read from them is my opinion, and I mark it as such. What I have not read, I say too. The AI industry is showing impressive numbers right now: revenues are rising faster than for any technology before, models are getting better, costs per token are falling. And one question is asked surprisingly rarely: what does it actually cost to solve a problem with AI completely, reliably and permanently? Not per token. Per solved problem.

The numbers from the prospectus

This is the table from the prospectus that matters, cut down to what I need here. All in millions of dollars, from the section "Summary Consolidated Financial Data".

What follows from that, purely arithmetically: compute and infrastructure were 55 percent of revenue in the half year, in the second quarter according to reports 48 percent, at 5.6 billion of cost against 11.6 billion of revenue. The company itself puts it as revenue in the second quarter having grown 1,368 percent, compute cost 300 percent. As one number, calculated from the table: per dollar of compute, around 63 cents of revenue came back in 2025. In the first half of 2026 one dollar 82. In the second quarter two dollars 08. Not less compute, that went up. But per compute dollar more than three times the revenue within a year and a half. For me that is the most remarkable number in the whole prospectus. And the number that almost gets lost in the bubble discussion: the operating loss shrank to 693 million in the half year, from 8 billion in the whole previous year. And in the second quarter alone, according to analyses of the prospectus, there was an operating profit for the first time, around 970 million on 11.6 billion of revenue. The huge net loss is, to the tune of 72 billion, an accounting item from revaluing convertible notes, because the company became worth more. Not money that flowed out. That is in the prospectus, in the footnote to the table.

And I say why exactly this number interests me so much, so nobody thinks I read prospectuses for fun. It is exactly the number we look at with our customers: what comes back per compute dollar, not as revenue, but as work done. With us every task carries its cost report, prompts, tokens, rework, and next to it what the customer gets out of it. And it is the number we optimise our own training environment by: small models instead of big ones where they suffice, scripts instead of model calls where possible, budget and deadline on every run. When a provider of this size triples its ratio in a year and a half, that is not a stock market topic for me. It is confirmation that efficiency per compute dollar is the lever everything in this business turns on. And, quite openly: we hope the same works for us, at our scale. More work done per compute dollar. That is what we measure ourselves by, and what we will be measured by.

Plus: commitments for compute capacity in the order of 540 to 570 billion dollars over several years, according to Fortune's analysis. And, to my own surprise when reading: sales, marketing and partnerships nearly sextupled in half a year compared to the whole previous year, to 3.2 billion. That is more than all personnel.

And I say this before I get critical, so it does not get lost: what Anthropic has delivered this year is a top performance. From a subsidised business to an operating profit in a year and a half, with revenue that more than tripled in the half year, with models I use every day and that get better every month. That is not just a good year, it is one of the best I have seen in this industry. And whoever reads the table also sees: there is still a lot of money there. 112 billion in cash and 19 billion in short-term investments at the end of June, according to the prospectus. Whoever had said two years ago that a provider would earn eleven billion in one quarter with models and make an operating profit doing it would have been laughed at. I do not belittle that. I only look at the bill that comes afterwards.

What the 48 percent measure, and what not

What I know from the table: the items and their magnitude. What I do not know from it, and that is not an insinuation but a limit of what the summary contains: what exactly is in "compute and infrastructure". How much of it was computed for paying customers and how much for research, training and internal use. The prospectus itself says the compute carries both, customer operation and model development. How that is split is not on the pages I read. Nor over how many years own hardware is depreciated. That is in the detailed part of the prospectus, and I have not read that completely. That is my state, not the state of the world.

My opinion, as opinion: a prospectus is prepared the way it may and should be prepared. That is not wrong, that is its purpose. So I read it as what it is: the provider's view of the provider. The calculation that interests me starts where the prospectus ends.

A cheaper component does not make a cheaper system

In software architecture we have known this for decades. The database server gets faster. The cloud offers cheaper instances. A new library speeds up one step tenfold. And the overall system still did not get cheaper, because integration came on top, complexity, monitoring, maintenance. What always counts is the total bill.

With AI it is no different. A model that handles a task for a few cents sounds efficient. But what if the result is wrong? If the context is lost? If three more calls are needed? If a human has to check, correct or redo the result entirely? Then the cheap operation has become an expensive business process. I described that with the Harvard study: 30 percent more code, 49 percent longer review, zero effect at the end. The cost of a model answer is not the cost of a solved task.

Twenty dollars versus eighty dollars

An example, invented, but the way I see it every week. A company has a coding agent build a function into an existing application. It analyses the code, creates classes, changes interfaces, adds queries. Model cost: twenty dollars. Impressive. Then it turns out: the function accesses data of another domain directly, security checks are missing, existing interfaces were bypassed, the implementation can hardly be extended. An experienced developer needs half a day to find and correct that. Twenty dollars have become several hundred.

Another agent might have cost eighty dollars, because it read the system first. In return it respected the architecture, reused what existed, wrote tests, delivered something maintainable. Which one was more economical? The answer is obvious. Still, almost all tools are compared by cost per token or by a benchmark.

The metric that is missing

With us every piece of work carries its cost report, I showed that in the workshop day: a normal task, twenty prompts, around a hundred thousand tokens, measured. That is the start. The second half is how much a human still had to touch afterwards, how many rules were violated, how much was corrected later. Only both together make a number you can decide with.

Four levels of efficiency

A model can shine on the first level and be uneconomical on the other three. Conversely, a more expensive model in a well-built architecture can be the better decision. And that applies doubly to agent systems: when several agents delegate, check and start over on errors, every role costs. Some roles demonstrably bring something, the checker who is not the writer, for example. Not every one. Sometimes a single, well-guided agent is cheaper than a swarm. Complexity has to deliver a demonstrable benefit, otherwise it is just effort. That is architecture, not AI.

The commitments behind it

Back to the prospectus. The demand is obviously enormous. Just as obvious is the scale of what is being committed for it: over half a trillion dollars of compute capacity over several years. Those are not incurred losses, and not every announced agreement is binding in the end. But it shows how much future demand is needed for that capacity to be utilised. And the big cloud providers are several things at once: the prospectus names Amazon as holder of convertible notes, AWS, Google Cloud and Azure as distribution platforms, and AWS Trainium and Google TPUs as the compute base. That the same groups offer their own models is well known. That is not reprehensible. It just makes the bill harder to read.

For a judgement on the economics of the technology, revenue growth plus falling relative compute cost is therefore not enough. You would have to know how training, inference, infrastructure commitments, financing, research and customer operation are distributed in the long run. And above all: how much benefit arises at the customer in the end. That is the same separation I made with OpenAI: benefit of the technology and return for the investors are two questions.

What I measure

A system that generates code ten times faster and causes twice the maintenance cost is no progress. Only such metrics allow a reliable statement about productivity.

What stays

The progress is real, and it would be wrong to belittle it. It would be just as wrong to conclude from individual metrics the economics of the whole technology. The real task is not to regard AI as a model but as part of a technical and economic system, and to measure the quality and cost of complete solutions, not the performance of individual models. That takes architectural understanding, stable contexts, clear domain boundaries, controlled processes, traceable quality criteria. The best models play a role in that. They are one component.

Sources and status