Picking a model for your coding agent, by the numbers

Most advice about which model to use in a coding agent is taste dressed as a benchmark. This article takes a different route: four fields in the model catalog decide whether a model can drive an agent at all, and one of them decides most of your bill. Read those first, then argue about quality among what survives.

The numbers below come from our live catalog on 6 August 2026 and will drift. The method will not.

Output price is the number that matters

Start here because it is the one people get backwards.

A chat workload sends a lot and receives a little. A coding agent inverts that. It writes diffs, rewrites files, explains reasoning and does it across many turns per task. The output side of the ledger is where an agent lives, and output is priced several times higher than input almost everywhere.

Among tool-capable models with a context window of 400,000 tokens or more, the current spread in our catalog looks like this:

From $0.336 to $36 per million output tokens. A hundredfold spread on the number that dominates.

That does not mean the bottom of the table is the answer. It means the difference between a considered choice and a default is large enough to be worth twenty minutes. A team running an agent hard on Opus that could have run two thirds of the work on Sonnet or Luna is leaving real money on the table, and a team running everything on a flash model is probably paying for it in turns.

Three filters that come before price

Price only matters among models that can do the job. Three catalog fields decide that, and all three are readable programmatically.

Tool support, or the agent does nothing

A coding agent is a tool-calling loop. It reads files, writes files and runs commands through tool calls. A model without tool support cannot drive it, no matter how good it is at code.

The failure is quiet, which is what makes it worth a filter rather than a test. The request returns 200 and the model explains what it would do instead of emitting a tool_calls array. Nothing errors. It reads as the agent ignoring instructions.

curl -s https://api.apexapi.dev/v1/models \
  -H "Authorization: Bearer $APEXAPI_KEY" \
  | jq -r '.data[] | select(.type == "chat" and .capabilities.tools == false) | .id'

Four chat models come back today, and they are not guessable from their names. Assert on this at startup.

Max output tokens, the truncation you will misdiagnose

This is the field almost nobody checks and the one that produces the most confusing symptom.

Twenty-one of the eighty chat models in our catalog currently publish no max output token figure. Where the figure is absent, the gateway applies a conservative fallback cap rather than letting a request run unbounded. That is the right default, since an uncapped output on a runaway agent loop is a billing incident. It also means a model with no published figure is a poor choice for a task that emits a large diff in one response.

The symptom is a response that stops mid-file. It looks like the model losing the thread. It is a cap doing its job.

The models with genuinely large single-response headroom are the exception rather than the rule. DeepSeek V4 Flash and V4 Pro publish 384,000 max output tokens, several times more than the 128,000 that the GPT-5.x and Claude families publish, and many times the 65,536 typical of the Gemini and Qwen entries. If your agent regularly rewrites whole files in one turn, that column deserves more weight than the price column.

Context window, and why bigger is not free

Context is the field people over-optimize. Most of the models above sit near or above a million tokens, so the window is rarely the binding constraint any more.

The trap is treating headroom as a target. Context you fill is context you pay for, on every turn, because an agent resends history constantly. A million-token window used well costs the same as a small one. Used carelessly it is a way to spend input budget faster.

The exception worth knowing: within a single model family, windows are not uniform. Claude Haiku 4.5 carries 200,000 while the rest of the Claude family carries a million. Assuming family-level consistency is how a working setup breaks when someone switches to the cheap variant.

The right choice is often two models

The single-model question is usually the wrong question.

The work an agent does splits cleanly. Planning an approach, reasoning about an unfamiliar codebase and reviewing a risky change benefit from a strong model, and those turns are a minority of the total. Applying a plan, renaming things, writing boilerplate and fixing a lint error do not benefit much, and those turns are the majority.

Running the whole session on the strong model pays a premium on the majority. Running it all on the cheap model saves money on the majority and then loses it in extra turns on the minority, which is the failure mode that makes people conclude cheap models do not work.

Because the model is a settings field rather than a property of the session, you can switch mid-task. Plan on Opus 5 or Sonnet 4.6, apply on Luna or DeepSeek V4 Pro, review on the strong model again. Everything runs on one key and one balance, so there is no re-authentication step between switches, and that friction is usually what stops people doing this even when they know it works.

If you want the setup for that, how to connect Cline to every model with one API key covers where the fields live, and the same pattern applies to Cursor, Continue, Codex CLI and the rest.

Measure the task, not the token

List prices predict a bill badly for agents, because the variable that moves most is turns, not price.

The number worth tracking is cost per completed task. A model at $0.336 per million that takes eleven turns to land a change can cost more than a model at $7.20 that takes two, and which way it falls depends entirely on your codebase and your prompts. It is not predictable from the price table, which is precisely why it is worth measuring once rather than reasoning about repeatedly.

Every response carries its exact cost in USD in the X-ApexApi-Cost header, to eight decimal places, including on streaming responses. Sum it across a task and you have the real number rather than an estimate. Do it for five representative tasks on two candidate models and the decision usually makes itself.

Two habits that make the measurement trustworthy. Use a separate API key for the agent, so its spend is isolated from everything else you run. And put a daily spend limit on that key, because the failure mode of a non-converging loop is a lot of tokens in a short time. A key can carry a daily limit, a monthly limit, a model allowlist and an expiry date, which are described in the authentication docs. The allowlist is quietly useful here too: if the agent key only permits the three models you chose, a mistyped model ID fails closed instead of billing you at premium rates.

A short procedure

Filter. Tool support true. Max output token figure published and larger than your biggest single edit. Context window that fits the repository slice you actually send.

Shortlist on output price, not input price, and not on the headline benchmark.

Pick two, one strong and one cheap, rather than agonizing over one.

Measure five real tasks on each, summing the cost header, and compare cost per completed task rather than cost per call.

Cap the key with a daily limit and an allowlist before you let anything run unattended.

That is a morning of work and it outlasts every model release, because the models change and the four fields do not. The current numbers live in the model catalog, and the pricing page explains how billing works, in real dollars with no credit currency in between.