The AI Model Price War: Choose Models Without Chasing Every Price Cut

Don’t choose your coding models by whichever provider just cut its per-token price. Choose a small roster by task, pin it behind your own configuration, and revisit the numbers on a schedule; that turns a price cut into a one-line routing change instead of a week of agent reconfiguration.

The useful question is not “which model is cheapest?” It’s “which model finishes this class of work at the lowest total cost, with an acceptable review burden and latency?” The token invoice is one input to that answer, and often not the biggest one.

Price the task, not the million tokens

Per-million-token tables are necessary and still misleading. A coding-agent run also consumes repeated repository context, tool results, hidden or visible reasoning tokens where applicable, retries, test output, and sometimes separately billed tools. A model that costs half as much per token but needs two extra repair turns is not half-price in your workflow.

Start with data you already have. Pick 20 representative tasks from the last month: a small bug fix, a test failure investigation, a dependency upgrade, a medium refactor, a documentation update, and a CI repair. Run candidates using the same harness, repository state, instructions, permission policy, and time limit. Record four numbers: wall-clock seconds, input tokens, output tokens, and whether a developer accepted the result with only normal review edits.

Then calculate a deliberately boring metric: cost per accepted task. If you want an even more honest number, add the median review time in dollars. A $0.09 run that creates 18 minutes of cleanup is expensive next to a $0.24 run that produces a clean, test-passing patch.

# Cost for one run; prices are dollars per million tokens.
python3 - <<'PY'
in_tok, out_tok = 18000, 6000
in_rate, out_rate = 2.00, 10.00
cost = in_tok / 1_000_000 * in_rate + out_tok / 1_000_000 * out_rate
print(f"${cost:.4f} per run")
PY

With 18,000 input tokens and 6,000 output tokens, that example is $0.096 per run. At 400 runs a workday for 22 workdays, it becomes $844.80 a month. That scale is enough to justify measurement. It is not enough reason, by itself, to migrate an agent stack every time a list price moves.

Keep three model slots, not a leaderboard

Most teams don’t need a permanent bake-off among a dozen models. They need explicit defaults that stop the expensive model from becoming the answer to every autocomplete, issue triage, and formatting request.

• Fast/default: low-latency, inexpensive work—test scaffolds, straightforward edits, log summarization, search-oriented repository questions, and first-pass issue classification.
• Build/reasoning: the model you use for multi-file changes, debugging, migration plans, and implementation runs that must interpret tool output and recover from failed tests.
• Escalation: a higher-cost option invoked only after the default model fails a defined condition, such as two failed test-repair loops, an incomplete plan, or a patch touching a designated risk area.

Put those slots in a checked-in config, not in every developer’s editor preferences. The exact syntax depends on your harness, but the principle is the same: workflows refer to fast, build, and escalation; a single provider-specific mapping resolves them. Pin a dated or versioned model identifier where the provider offers one. “Latest” is convenient until a quiet capability or behavior change lands in the middle of an incident response.

models:
  fast:
    provider: google
    model: gemini-3.7-flash
  build:
    provider: openai
    model: gpt-5.3-codex
  escalation:
    provider: anthropic
    model: claude-opus-4-7

routing:
  escalate_after_failed_test_repairs: 2
  max_agent_minutes: 12
  max_cost_per_run_usd: 1.50

Those names are examples, not a prescription. The important part is the budget and escalation rule. A model that is excellent at reading a 40-file change can still be a bad default for “add a missing unit test.”

Use price changes to challenge a route, not to declare a winner

Current pricing already shows why a single “cheap versus expensive” ranking does not survive contact with production. OpenAI lists distinct input, cached-input, cache-write, and output prices, while Google offers Standard, Batch, Flex, and Priority variants and separately prices some tools. Anthropic’s list-price document also distinguishes normal input, output, cache writes, cache hits, batch processing, and—in some cases—regional scope. Compare the rates that match how you actually call the API, not the largest number in a screenshot.

Treat a provider announcement as a trigger for a narrow test. If a lower-priced model now looks plausible for your build slot, rerun your 20-task suite and compare acceptance rate, median duration, and cost per accepted task. Promote it only if the savings survive the whole suite. A five-minute code-generation demo is not evidence that it will recover from a package-lock conflict, preserve an internal API boundary, or stop after it has made the requested change.

Put guardrails where the expensive behavior starts

The biggest spend surprises are usually not from a developer asking one hard question. They come from loops: an agent rereads the repository, calls search repeatedly, keeps feeding verbose test output back into context, or runs unattended against a queue. Set ceilings before you tune model selection.

For an interactive coding session, start with a 12-minute wall-clock cap, a maximum of two automatic test-repair attempts, and a per-run budget that forces a handoff rather than silently continuing. For batch work, use the provider’s discounted asynchronous tier only when latency genuinely does not matter. Batch is a cost control, not a substitute for a quality gate.

Also meter non-model calls. Search grounding, browser or computer-use steps, retrieval, and generated tool output can change the bill and the behavior of a run. Google’s pricing documentation, for example, charges grounded search requests separately after an included allowance and notes that tool use can generate billable token traffic. If your agent has tools, log tool calls next to tokens and duration.

Review the roster monthly, but test on a fixed cadence

Set a 30-minute monthly pricing review: update a small internal sheet with current input, output, cached-input, batch, and tool prices for the models you permit. Record the source URL and the date checked. This is enough to catch material changes without creating a standing procurement meeting around every launch.

Run the quality suite less often—quarterly is a reasonable starting point—and immediately only when one of three things happens: a provider deprecates a model, changes a model version behind an alias, or cuts the estimated cost of one of your routes enough to matter. Decide that threshold in advance. For a team spending $300 a month, saving 20% is $60; don’t burn two engineers’ afternoons chasing it. For a platform spending $30,000, the same percentage is a real experiment.

The price war is useful because it gives you options. Your job is to make those options interchangeable enough that a better price—or a model regression—changes a config file, a test result, and a rollout decision, rather than everybody’s daily workflow.