Cancelling seats and composing your own applications turns a fixed cost into a variable one. That is an improvement. It is also a new meter, and the meter has no seat count to cap it. This note sets out when the meter is worth managing — and when managing it is the more expensive mistake.
Per seat per month becomes per token per request
The fourth invoice is the easiest of the five to contest. A long tail of single-purpose tools, each priced per seat per month, each covering one workflow. Compose the application yourself against the systems you already run, and the seat price disappears.
Something appears in its place. A seat is fixed and knowable: multiply the price by the headcount and the year is budgeted. A meter is variable, and its size is decided by how people use the thing you built, after you built it. Most finance functions have never carried a technology line of that shape.
For reference, the seat you are cancelling: Microsoft 365 Copilot Business lists at $18.00 per user per month on an annual commitment, $25.20 monthly.
Source: microsoft.com/microsoft-365/copilot/business — 23 Aug 2026 · FACT
What the meter actually costs
The spread between model tiers is the whole of the routing argument, so it is worth stating precisely rather than in round numbers.
| Model | Input, per 1m tokens | Output, per 1m tokens |
|---|---|---|
| Claude Opus 5 | $5.00 | $25.00 |
| Claude Sonnet 5 | $2.00 | $10.00 |
| Claude Haiku 4.5 | $1.00 | $5.00 |
| OpenAI gpt-5.6-luna | $0.10 | $0.60 |
Sources: platform.claude.com/docs/en/about-claude/pricing and developers.openai.com/api/docs/pricing — both read 23 Aug 2026 · FACT
Two mechanisms compress those figures further, and both matter more than they look. Asynchronous batch processing runs at half price on both sides of the meter. Cached input tokens cost roughly a tenth of standard input rates. Neither requires a routing decision; both require someone to have thought about it.
One mechanism works the other way, and it is the reason per-token list prices are not directly comparable across model families: the newer Claude tokenizer produces around 30% more tokens for the same text than its predecessors. A price per token is not a price per unit of work. Any comparison that ignores this is arithmetic, not analysis.
The bill is smaller than it feels — until the work becomes agentic
Two shapes of use, same company, same people.
Chat-shaped. Sixty people, thirty interactions each per working day, about 1,500 tokens per interaction — five hundred in, a thousand out.
| Routing | Annual token cost |
|---|---|
| Everything to the top tier | ≈ $12,500 |
| Everything to the mid tier | ≈ $5,000 |
| Twenty per cent top tier, the rest to a small model | ≈ $2,700 |
Illustrative arithmetic on the list prices above; 21 working days per month · ILLUSTRATIVE
Routing cuts that bill by roughly three quarters. It also cuts it by about ten thousand dollars a year, which does not pay for the week it takes to install, and would not clear our own qualification threshold. We publish that threshold: the annual line under contest must be at least four times the price of the product that contests it. A $12,500 line does not reach it. We would decline the work.
NUVAI'S OWN
Agent-shaped. The same sixty people, three agent runs each per working day. An agent run is not a large prompt; it is a sequence of steps, and every step re-sends the accumulated context together with everything the tools returned. Token consumption grows with the square of the conversation, not with its length. Call it a quarter of a million tokens per run, most of it on the input side.
| Routing | Annual token cost |
|---|---|
| Everything to the top tier | ≈ $102,000 |
| Twenty per cent top tier, the rest to the mid tier | ≈ $53,000 |
Illustrative arithmetic on the list prices above · ILLUSTRATIVE
Same headcount. Same company. Eight times the bill, and now it clears the threshold with room to spare.
The finding is not that routing saves money. It is that the shape of the work, not the number of users, decides whether there is anything to save. And for agent-shaped work the input side carries most of the bill — which means caching and context discipline are the larger lever, and model routing is the second one. Most of the market has the order reversed.
| Human-facing — chat, projects, assistants | Programmatic — composed applications, agentic workflows |
|---|---|
| Failure modeA person waits, or switches tool for an hour | A pipeline stalls or errors quietly; nobody notices until a deliverable is late |
| What is exposedIndividual productivity | Business processes, and the commitments made on top of them |
| DetectionImmediate — the person tells you | Whenever somebody happens to look |
| The remedyNone required. Keep the tool | Stop calling a provider directly from anything the business depends on |
Human-facing — chat, projects, assistants
- Failure mode
- A person waits, or switches tool for an hour
- What is exposed
- Individual productivity
- Detection
- Immediate — the person tells you
- The remedy
- None required. Keep the tool
Programmatic — composed applications, agentic workflows
- Failure mode
- A pipeline stalls or errors quietly; nobody notices until a deliverable is late
- What is exposed
- Business processes, and the commitments made on top of them
- Detection
- Whenever somebody happens to look
- The remedy
- Stop calling a provider directly from anything the business depends on
The remedy is not to leave the provider. The remedy is narrower than that, and cheaper.
NUVAI'S OWNRouting is a mechanism, not a discount
A gateway sits between your applications and your model providers and does three things. It sends each request to a model chosen by the request rather than by the developer who wrote that line of code. It fails over when a provider does not answer. And it puts logging, spend limits and data policy in one place instead of in every application.
The published evidence for the first of those is thinner than the vendor material suggests. The RouteLLM work is the most cited: learned routers cut cost by more than half in some configurations without measurable quality loss, and the routers transfer when the underlying models are swapped.
Source: Ong et al., RouteLLM: Learning to Route LLMs with Preference Data, arXiv 2406.18665, rev. Feb 2025 · FACT
Its honest limit: those are public benchmarks, not your workload. Gateway vendors quote 50% to 85%. Those are vendor claims about vendor products measured on workloads that are not yours, and they belong in the direction column, never the precision column.
CLAIM
Two costs that rarely appear in the vendor arithmetic. The router is itself a model decision, made automatically, thousands of times a day — and a misroute is a quality failure your users notice before your dashboard does. And the gateway is a dependency: if you cannot switch supplier on it within six months, it is not a partnership.
What survives
The frontier tier survives, on the work where being wrong is expensive. Nothing in the routing argument says otherwise; it says the opposite, because routing only pays when there is a meaningful share of work that genuinely needs the top model and is being crowded in with the work that does not.
Systems of record survive. The gateway acts on requests; it does not hold the ledger.
And the reason to install one at €10m–€250m revenue is not the saving. At that scale the saving usually fails our own threshold. The reason is that a gateway is the only place where you can see what left the building, which model saw it, and what it cost — priced as a by-product of a routing decision you were making anyway.
The gateway is a system of record in waiting
The moment it holds the only record of which model saw which data, it has quietly become one. That is exactly how the fragile thing you are now paying to replace got built: nobody set out to build it, it accumulated.
So it graduates like anything else. Anything composed that becomes business-critical is rebuilt on a supported tier or replaced by a bought product. And its log is not an operations artefact — it is your model inventory, which is to say it is the registry: owner, data touched, classification, per application. Compliance becomes a by-product of ordinary governance rather than a parallel programme.
And yes, that includes us
Our own composed applications run on the same meter, under the same discipline, and a practice selling routing while paying list price for its own inference would deserve the question.
The self-cancelling part is more specific here. If your token bill does not clear the 4× rule, the correct advice is to turn on caching, use the batch endpoint where latency allows, and revisit in two quarters. That is a paragraph, not an engagement, and it is free. What you hold if we do build it is the gateway inside your own tenant, its registry entry, and a team that can change a routing policy without calling anyone.
We are the last invoice of this kind you buy for that workflow.
What would change this conclusion
Stated so it can be checked rather than defended.
- A price cut at the top tier. Frontier prices have fallen repeatedly. Each fall narrows the spread and weakens the routing case at the same time as it weakens the case for worrying about the bill at all.
- Agent adoption faster than assumed. The chat-shaped figures above are already the minority case in engineering teams. If agent-shaped use reaches the commercial and finance functions this year, the threshold is crossed by companies that have not budgeted for it.
- Routing quality. If learned routers do not hold up on messy enterprise workloads, the honest version of this argument reduces to caching, batching and a hard-coded model per use case — which is most of the saving with none of the router risk.
Run your numbers
Tab C of the calculator takes your headcount, the shape of your use and today's list prices, and returns the contestable annual line and a verdict against the 4× rule. Most readers will get "leave it". That is the correct answer, and it is also the reason to trust the ones who do not.