Capability rises. So does the price per outcome
In AI projects, progress shows quickly: better reasoning models, agents that can split work and integrations closer to a company's real systems. In parallel, cost per token, per agent minute or per high-effort session rises. If you treat every task as a maximum-power demo, the bill outruns the value delivered.
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
Many platforms offer an effort or “reasoning” level for the same model: less effort means faster, cheaper answers; more effort can improve quality on hard problems. In practice, start at a medium level on a set of real examples. Only if the result clearly fails — omissions, logic errors, incomplete plans — raise the effort and note which task type required it.
This approach avoids two extremes: running everything at maximum “to be safe”, and staying permanently on minimal settings that force the team to correct. A short log of task type, level used and whether a second attempt was needed helps you set an internal policy, not just a momentary 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 raises the bill even though the hard work is already delegated. Practical example: you can assign a highly capable model to subagents solving difficult tasks and a lighter model to coordination, so overall usage stays predictable. The principle stays: match power to the role, not to habit.
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. Google Gemini Flash-class models, for example, are often chosen when you need a good quality–cost ratio at higher volume — provided you 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.
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”.
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.
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, 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.