Input tokens

Input tokens are everything the harness sends up in a model provider request: the system prompt, every message so far, the definitions of every available tool, and every tool result that's been fed back. They're the 'reading' side of the bill and are priced lower per token than output tokens, but there are a lot more of them, and their count grows on every turn because the whole history is re-sent.

That growth is the trap. Early in a session a request might be a few thousand input tokens. After an hour of reading files and running tests it can be well over a hundred thousand, and every additional request pays for all of it again. A session that feels slow and expensive late in the day is almost always an input-token problem, not an output one.

Two things help. The prefix cache lets the provider skip re-processing the unchanged prefix, so repeated input is billed as cheaper cache tokens. And you control what enters the window: read the files that matter rather than the directory, pipe noisy command output through head or a grep, and compact or start fresh once the useful part of the history is behind you.