PraxisIQFuseIQby PraxisIQ
AI Economics

Token optimization is not about buying the cheapest model

Lower model prices do not guarantee lower operating costs. The best optimization decisions account for the whole workflow, including retries, review, and output quality.

PraxisIQ EditorialSeptember 4, 20266 min read
COST PER COMPLETED OUTCOMEOne taskLowest unit priceRetryRetryExcess contextReviewRetryUnfinishedHigher unit priceOne well-scoped callCompletedPrice per token is not price per result

Token optimization is often reduced to a price comparison. One model costs less per million tokens than another, so the cheaper model appears to be the obvious choice.

That logic works only if the models produce equally useful results with the same number of calls, the same amount of context, and the same level of human review. In production, they rarely do.

The unit price of a token matters. The design of the workflow matters more.

Start with the transaction

Before comparing models, define the unit of work. It might be a support case resolved, a contract reviewed, an invoice reconciled, a work item completed, or a qualified opportunity researched.

Then calculate the full AI activity required to complete that transaction. Include system prompts, retrieved context, user input, output, evaluation calls, retries, tool calls, and any fallback to another model. This exposes the difference between the advertised model rate and the actual cost of the workflow.

A cheap model that needs several attempts may cost more than a stronger model that succeeds on the first pass. It may also consume more employee time.

Context is often the largest avoidable cost

Many applications send far more information than the task requires. They attach full documents when a relevant section would be enough, repeat instructions on every turn, retain long conversation histories, or retrieve large amounts of marginally relevant material.

Context should be treated as an engineered resource. Teams can reduce it by improving retrieval, summarizing stable information, caching reusable content, separating tasks, and setting limits appropriate to the workflow.

The goal is not to starve the model. It is to provide the smallest amount of high-quality context needed for a reliable result.

Route work based on difficulty and risk

Not every task needs the most capable model. Classification, extraction, summarization, reasoning, code generation, and executive communication have different requirements.

A routing strategy can send routine, low-risk work to a smaller model and reserve more capable models for complex or consequential decisions. The routing rules should account for task type, data sensitivity, required accuracy, latency, and the cost of failure.

Routing should also include escalation. If confidence is low or an evaluation fails, the workflow can move to a stronger model or a human reviewer. That is more disciplined than using the largest model for everything or the cheapest model for everything.

Measure retries and failed loops

Agentic systems can generate hidden consumption. An agent may call the same tool repeatedly, search without converging, regenerate an answer after an evaluation failure, or continue working after the useful result has already been produced.

These loops are not visible in ordinary seat-license reports. They require workflow-level tracing and limits. Track the number of model calls, tool calls, retries, elapsed time, and stop conditions for each completed or failed transaction.

Optimization often begins by fixing behavior, not negotiating price.

Include the cost of review

A lower-cost output that requires extensive correction can be an expensive result. Human review should be measured as part of the transaction.

For each workflow, ask:

  • What percentage of outputs require review?
  • How long does review take?
  • What types of errors are reviewers correcting?
  • How often is the work rejected or repeated?
  • Can the workflow safely use sampling instead of reviewing every result?

These answers help determine whether the model, prompt, context, or process needs to change.

Optimize for value per completed outcome

The right target is not tokens per se. It is the cost and quality of a completed business outcome.

For a contract workflow, that might be cost per agreement structured and reconciled. For engineering, it might be cost per accepted work item. For service operations, it might be cost per case resolved without reopening.

Once the outcome is clear, teams can compare approaches honestly. A more expensive model may be justified for difficult work. A smaller model may be sufficient for extraction. A deterministic rule may be better than a model call. Some steps may not need AI at all.

Token optimization is a design discipline. It connects model choice, context, orchestration, evaluation, and human effort to the business transaction. The companies that manage those elements together will make better decisions than those that simply chase the lowest published rate.

Written by

PraxisIQ Editorial

PraxisIQ

The PraxisIQ editorial byline. Pieces published under it are reviewed by the delivery leads responsible for the work they describe.

Estimated reading time 6 minutes.

Insights subscription

Get new PraxisIQ Insights when they are published.

We publish when there is something specific from delivered work. No cadence filler.