Input and output tokens in coding agents

The general idea

Language models count text in tokens, small chunks of a few characters each. Providers meter two directions separately: what you send in and what the model generates back. Most bill the generated side at a higher rate per token.

Why agents are read-heavy

A coding agent works in turns. Each turn sends the system instructions, the history so far and whatever its tools returned: file contents, search hits, compiler errors. The reply is often a short edit or a structured answer.

So a single run usually reads far more than it writes. Trimming context usually saves more than asking for shorter answers.

How DevFlow counts them

The OpenCode backend sums the token figures from every step of a run. Uncached input, generated output, cache reads and cache writes are kept as four separate numbers, and each lands in its own column of the agent_invocations row.

Reasoning tokens from thinking models are stored under a separate <model>:reasoning key. They stay visible but never distort the main counts.

How they are summarised

For the planned public model pages, the export will take the median of uncached input and the median of generated output for each model and role. Medians resist the occasional giant run that would skew an average.

Each figure will cover a trailing 90-day window. A model and role pair with fewer than 30 runs will be published as empty rather than as a noisy number.

Reading the numbers

High input with low output points to an exploring role, such as planning or review. The reverse suggests a role that writes code. Comparing the same role across models is fairer than comparing two different roles.