Tokens: what artificial intelligence really consumes when you give it a job

A lawyer who uses artificial intelligence to polish an email, translate a clause or prepare for a meeting rarely thinks about consumption.

You type. You receive an answer. You carry on working.

With a subscription, the experience seems particularly simple: you pay a monthly fee, and the sense that each query consumes resources disappears.

That tranquillity changes when we stop conversing with artificial intelligence and start delegating work to it.

A modern system can receive an objective, read documents, search for information, use tools, review its results and correct its course. It can also divide parts of the assignment among several specialised agents.

At that point, an idea emerges that runs counter to almost all our intuitions:

The length of the answer does not tell you how much work the machine performed to produce it.

Ask a trainee to summarise a thousand-page case file in four lines. The result may be four lines long, but a thousand pages had to be read to produce it.

Something similar happens with artificial intelligence. The difference is that it can perform a vast amount of intermediate work without any of it being visible in the answer.

That is why it is worth understanding tokens — not to become a programmer, but to learn how to delegate better.

1. The fuel, the engine and the load

A token is one of the units into which a model divides the information it processes. It may correspond to a word, part of a word, a symbol, a number or even certain bytes. The ratio varies with the language, the content and the tokenisation system. There is no universal conversion between pages, words and tokens.

A simple analogy is enough to understand the concept:

• Tokens are the fuel.
• The model is the engine.
• The context window is the carrying capacity.

They are three different things.

Input tokens include what we provide to the system: instructions, questions, documents, parts of the conversation and, depending on the architecture, tool definitions and retrieved results.

Output tokens are what the model generates. In some systems, they also include reasoning work that does not appear in full in the final text. OpenAI's API, for example, reports reasoning_tokens within the output tokens consumed.

The context window determines how much information the model can have available during a request. The fact that a case file fits inside it does not mean that sending the entire file — or keeping it present throughout the assignment — is a good idea.

For this article, we will use a single example throughout:

A 100-page contract which, once converted to text, amounts to approximately 40,000 tokens.

This is an illustrative, deliberately rounded figure. Actual consumption must be measured using the particular document, language and model involved.

2. Scene one: a single query

Suppose we give the complete contract to a model and ask:

“Summarise the main risks for the tenant in ten points.”

The system must process approximately 40,000 tokens even if its answer occupies only one page.

As an example, on 14 September 2026, the base API rate for input tokens for GPT-6 Astra and Claude Fable 5.1 is $10 per million tokens. Processing our 40,000 tokens once would therefore cost approximately $0.40 in input charges.

That is not the total cost of the assignment. It does not include the additional instructions, output, possible reasoning, tools or any subsequent operation.

The example demonstrates something more important: a short answer may require an extensive reading exercise.

It also shows why available capacity should not be confused with the wisdom of using it. Astra and Fable 5.1 currently support context windows of around one million tokens, but there is no prize for filling them. With Astra, moreover, a request containing more than 272,000 input tokens is billed at higher multipliers for the entire request.

A very large desk allows us to open many documents. It does not oblige us to empty the entire archive onto it.

3. Scene two: twenty questions about the same contract

Now imagine that we ask twenty successive questions.

If a simple integration processed the entire contract again with every request, the document alone would account for:

40,000 × 20 = 800,000 input tokens.

At the base API rate used in our example, that would cost $8 before any other consumption is counted.

This does not mean that every application works in this way. Modern products may maintain state, reuse parts of the context through prompt caching, compact conversations or combine several techniques. It is therefore incorrect to claim that every conversation inevitably rebills the entire history from scratch.

The economic principle nevertheless remains:

Maintaining and reprocessing context has a cost, even when the interface does not display it.

Prompt caching allows repetitive information to be reused at a lower price, but it is worth describing the mechanism precisely. According to the API rates checked on 14 September 2026, Claude Fable 5.1 charges:

• $10 per million tokens for standard input.
• $12.50 per million tokens to write content to a five-minute cache.
• $20 per million tokens to write it with one-hour retention.
• $0.25 per million tokens for cache reads and refreshes.
• $50 per million output tokens.

For our contract, writing 40,000 tokens would cost approximately $0.50 with five-minute retention or $0.80 with one-hour retention. Each subsequent read or refresh of those same 40,000 tokens would cost around one cent.

In an ideal scenario, one five-minute cache write and nineteen subsequent reads would amount to approximately $0.69 in input charges, rather than $8 without caching. The actual figure will depend on whether the content remains reusable, the intervals between requests, refreshes, new parts of the context and the way the system is built.

For someone who does not program, there is a much simpler rule:

When you genuinely change subject, start a new conversation.

Price is not the only reason. Carrying forward case files, instructions and decisions that are no longer relevant can also make it harder for the model to identify what matters.

4. Scene three: the contract goes to an agent

So far, we have been asking questions. An agent works differently.

It receives an objective and works through a cycle:

1. It analyses the assignment.
2. It decides on the next step.
3. It uses a tool or consults a source.
4. It examines the result.
5. It adjusts its strategy.
6. It continues until it reaches a stopping condition.

The difference can be summarised as follows:

In a chat, the user normally decides each step. In an agentic system, we authorise the system to decide some of the steps required to reach the objective.

Now consider this assignment:

“Analyse the contract, identify the legal and economic risks, verify the statutory references, compare the problematic clauses with current sources and prepare a final report.”

The result may be only three pages long. To produce it, however, the agent might:

• reread different clauses;
• extract dates, amounts and obligations;
• run searches;
• open and assess several sources;
• discard unsuitable results;
• draft an initial report;
• verify its own citations;
• correct errors;
• and generate the final version.

Each pass through the cycle may involve new model requests, fresh context, reasoning tokens, tool results and, in some cases, specific charges for using those tools.

That is why, in agentic AI, the economic unit is no longer the answer.

It is the entire execution that we have authorised.

“How long is the report?” is no longer an adequate question. We need to ask how many steps were taken, what information was processed at each one, which tools were used, how many times the work was retried and what condition caused the agent to stop.

5. Scene four: the contract goes to a team of agents

The next step is a multi-agent system.

A coordinating agent can divide the contract among specialists: one examines the obligations, another the guarantees, another the economic consequences, and a fourth verifies sources and references. The coordinator then brings the findings together and prepares the final answer.

This can provide greater capacity, parallelism and specialisation. It can also multiply consumption very quickly.

Let us take our example to a deliberate extreme. If we send the complete 40,000-token contract to 25 agents:

40,000 × 25 = 1,000,000 input tokens.

At a base API rate of $10 per million tokens, it would cost $10 merely to give them the document. Their instructions, reasoning, tools, responses, communications and the coordinator's synthesis would still need to be added.

We are not describing a recommended configuration. This is a stress test showing how the architecture can matter more than the size of the document.

A better-designed system could process the contract once, create a shared structure and give each specialist only the clauses and background information that it needs. It could also prevent several agents from running the same search or repeating a review that has already been completed.

Anthropic published data in 2025 about its own research system. In its experience, agents used approximately four times as many tokens as a chat interaction, while its multi-agent system used around fifteen times as many. These are not universal multipliers and cannot be used to calculate the cost of any agent. They are observations from a specific architecture built for complex, parallelisable research.

The same technical account explains that some early prototypes created 50 subagents for simple queries, searched indefinitely for sources that did not exist or became distracted by unnecessary updates. Those behaviours were not desirable capabilities; they were failures that Anthropic had to correct by improving its delegation and termination rules.

The lesson is not that agents consume too much or that teams should be avoided.

It is this:

The harness that organises the work — its limits, tools, memory, allocation of context and stopping criteria — is as important economically as the model it uses.

Teams of agents make sense when the task is sufficiently valuable, can genuinely be divided and benefits from parallel work. Using them for every assignment adds activity without guaranteeing better results.

6. Subscription, API and intermediary provider

The economics also depend on the method of access.

With a subscription, the user does not normally receive a bill for every million tokens. Instead, they work within certain allowances and limits, which may vary according to the model, tools and intensity of use.

With an API, the relationship is more direct. Input, cache, output and, where applicable, tools or other services are metered.

There is also a third situation that is common in businesses and law firms: purchasing a specialised solution that uses models from OpenAI, Anthropic or other providers underneath.

The invoice may be fixed, but the variable cost does not disappear. It is initially borne by the intermediary. That may influence which model it uses, how much context it provides, how many steps it allows and how often it activates agentic functions.

When assessing a professional provider, therefore, it is not enough to ask whether it “uses artificial intelligence”. It is worth finding out:

• which models and versions it uses;
• whether it changes model according to the task;
• what limits it applies to agents and tools;
• how it selects context;
• whether it can explain which operations it performed;
• and how it measures cost, quality and errors.

A flat fee may simplify the purchase. It does not make the architecture irrelevant.

Next project · AI Economics — Complete, comparable rates for OpenAI, Anthropic, Gemini, Grok, DeepSeek, Kimi and other providers will be collected in a future independent monitor. Until then, this article retains only dated, verifiable examples.

7. The new professional skill: knowing how to commission and constrain work

A lawyer already knows how to delegate.

Lawyers do it when instructing a trainee, an associate or an external expert. They define the problem, provide the background, delimit the sources and decide what result they need.

Compare two assignments involving our contract.

Open-ended assignment:

“Analyse this contract and tell me everything you find.”

What does “everything” mean? Should it search case law? From what period? May it consult the internet? How many sources? Should it also examine the tax consequences? When may it consider the work complete?

We do not know.

Controlled assignment:

“Review clauses 7 to 12. Identify departures from the default legal regime and flag those that disadvantage the tenant. Use only the contract and the official sources I provide. Do not run more than eight external searches. Open the original source before citing it. Deliver a brief table and a conclusion of no more than 400 words. If information is missing, say so. Request authorisation before expanding the scope.”

The second assignment determines:

• the objective;
• the scope;
• the sources;
• the permitted tools;
• the format;
• and the stopping condition.

That does not diminish the analysis. It directs it.

There is, however, a fundamental distinction:

The prompt directs. The system controls.

Writing “do not spend too much” or “do not run more than eight searches” guides the agent, but it does not, by itself, create a reliable technical limit.

In a professional application, the harness should be able to impose:

• a maximum number of agents;
• a maximum number of steps;
• a maximum number of tool calls;
• a financial budget;
• context and output limits;
• a maximum execution time;
• stopping criteria;
• activity logging;
• and human authorisation to expand sensitive or costly assignments.

Measurement should not be limited to the number of tokens either. A more expensive model may solve correctly on the first attempt what another requires four attempts to complete. An additional search may prevent a false legal assertion. A second review may detect a significant professional error.

The relevant metric is the cost per useful, properly verified result.

8. What we can do tomorrow

If we use an AI application:

• Start a new conversation when the matter changes.
• Attach only the documentation that is necessary.
• Choose a level of capability proportionate to the difficulty.
• Distinguish between a “short answer” and “shallow analysis”.
• Define the scope, sources, result and stopping condition.
• Ask the system to request authorisation before expanding the work.
• Verify what the subscription actually includes.

If we build or purchase a professional system:

• Measure consumption across the complete task, not only per call.
• Use prompt caching to reuse repetitive context.
• Avoid giving every subagent the entire case file.
• Route routine tasks to models that are capable enough and economical.
• Reserve frontier models for work that genuinely requires their capabilities.
• Introduce hard limits for steps, agents, tools, time and budget.
• Record the model, version and configuration that produced each result.
• Evaluate quality and cost before scaling the process.

This is not simply about spending less

Optimising tokens does not mean making artificial intelligence do less work.

It means making it do the right work.

Efficiency and depth are not opposites. The objective is to allocate the machine's intellectual resources according to a logic similar to the one we would use to organise human resources: define the objective, provide the necessary information, select the appropriate capability, supervise the process and know when to stop it.

Tokens are not a measure of intelligence.

Nor do they guarantee quality.

They are one of the units that allow us to observe and account for part of the system's work.

As artificial intelligence moves beyond answering questions and begins to use tools, make operational decisions and coordinate agents, understanding that work becomes increasingly important.

The professional question is therefore no longer simply:

“Can the machine do it?”

There is another question that is probably more important:

“What work am I authorising it to perform in order to get there?”

Scope note

This article concerns resource consumption and the basic economic architecture of assignments performed using artificial intelligence.

Confidentiality, professional secrecy, data location and retention, and the handling of client documents are separate and overriding concerns. They are addressed separately in AI and business documents: knowing where your PDFs are is not enough.