Capability rises. The bill depends on how you use it
In recent months we have seen models that reason better, context windows of up to a million tokens and agents that can work on long tasks on their own. The price per token no longer rises automatically with capability: some new generations even launched at lower rates than their predecessors, while the top models moved into a separate price tier. Cost per task can still grow, because a model that “thinks” longer, reads more context and takes more steps consumes more tokens for the same result.
For a business, the useful question is not “what is the strongest model?” but “what quality do we need here and what is it worth paying?” A good support email reply, invoice extraction and an architecture plan do not share the same requirements. Cost discipline starts with that separation.
Start at medium effort; raise it only when needed
Most platforms now let you choose the effort level for the same model, from low up to very high or maximum. Less effort means faster, cheaper answers; more effort can improve quality on hard problems, but it can multiply the tokens consumed. In practice, test on a set of real examples and raise effort only when the result clearly fails (omissions, logic errors, incomplete plans), noting which type of task needed it.
It is worth knowing that a new-generation model run at lower effort often matches the previous generation at high effort. So avoid both extremes: running everything at maximum “to be safe” or staying on minimal settings that force the team to fix the output. A short log of the task type, the level used and whether a second attempt was needed helps you set an internal policy, not just a passing preference.
In multi-agent flows, put power where it matters
When a flow uses an orchestrator and several subagents, total cost depends on how many calls each role makes and how expensive the model behind it is. A practical rule: reserve the most capable models for steps where mistakes are expensive — analysis, design, review — and use more economical models for routing, short summaries or formatting when quality stays acceptable.
In agent setups, check who consumes the most: sometimes an orchestrator on an expensive model drives up the bill even though the heavy work is already delegated. Match power to the role, not to habit, but do not split the flow without reason: prompt caching is tied to the model used, so a flow that switches models often loses part of the discount. Before building a multi-model cascade, compare the simple option: a single capable model run at lower effort.
Capable models with a strong quality–price ratio
Not every task needs the top of the range. For classification, structured extraction, rewriting or a first draft on clear data, a fast and more affordable model can be enough, for example from the Gemini Flash or Claude Haiku classes. And mid-tier models from recent generations often cover work for which, until recently, you would have picked the top model. The condition stays the same: test them on your data, not only on public demos.
Build an internal ladder: an economical model for volume and predictable steps; a mid-tier model for most project work; a top-tier model for hard cases or final review. Change tiers after measured failure, not after the impression from a single conversation.
Use the discounts that already exist: caching and batch processing
Two mechanisms lower the bill without lowering quality. The first is prompt caching: when you repeatedly send the same opening (system instructions, documentation, the product catalogue), the part already processed can be reused, and tokens read from the cache cost a fraction of the normal price (around 10% at Anthropic). The condition is that the stable part comes first and does not change between calls: a date or a unique ID placed in the instructions cancels the saving.
The second is batch processing. Tasks nobody is waiting for on the spot — classifying a catalogue, overnight summaries, extraction from an archive — can be sent asynchronously at roughly half price with the main providers. Separate interactive flows from those that can wait a few hours, and you will see the difference directly on the bill.
Send less context, but the right context
Part of the cost comes from the volume of text sent on each call: long history, whole files or irrelevant documentation. Before an expensive step, limit context to the sources that task needs. A good index, targeted search or a short list of relevant files usually costs less than “take the whole repository”. Million-token context windows are useful, but they are not an invitation to fill them: you pay for every token sent, on every call.
Likewise, separate steps that can run as rules without a model — validation, table-based calculations, notifications — from steps that truly need interpretation. Fewer AI calls on predictable flows means a smaller bill and more control.
Measure cost per accepted outcome, not per call
A cheap call that produces a wrong draft and three correction rounds can cost more than a dearer call that passes review first time. On a pilot, track service cost, human review time and acceptance rate. Those three numbers say more than a marketing table’s price per million tokens.
Define upfront what “done” means: required fields complete, no invented data, company rules respected. Without that criterion you optimise for speed, not value. A concrete framework for the baseline and ROI calculation appears in the guide on measuring an AI pilot.
When you switch models, redo the measurements: new generations may use a different tokenizer, and the same text can mean more tokens, and therefore a different bill at the same listed price. For agents, set budget limits per task or per session where the platform allows it, so a stuck flow cannot consume without control.
How we apply cost discipline in a project
For a project discussion, useful inputs are: the task types you want to automate, estimated monthly volumes and an example of a result the team considers correct. From there we can propose a role-based architecture — what runs on rules, what on an economical model or in batch, what on a more capable one — with human review where mistakes have commercial or legal impact.
The goal is not to always use the newest model, but to deliver a process you can sustain: predictable in effort, transparent in cost and good enough for daily work. AI capability is worth it; waste is not.