Agent Spend

Agent Session Logs Already Know What You Spent

· · 5 min read
llmtoolingagents

Token prices keep falling and the bills keep rising. GPT-3-quality output that cost $60 per million tokens in 2021 sold for $0.06 three years later, yet OpenAI’s 2025 inference bill alone was around $8.4 billion, four times the year before. Usage is growing faster than the price cuts, and the fastest-growing slice is agents: one analysis of agentic coding tasks found them consuming on the order of a thousand times more tokens than chat-style coding help, mostly on input as the agent re-reads the codebase turn after turn.

The models are also getting more expensive in absolute terms. Businesses using AI spent April 2026 getting 45.8% of their tokens from premium models and paying 55.9% of their cost for them, because the more capable a model is the more it charges per token, and agent work gravitates to the capable end. So the question “what are we spending on this” is not a procurement curiosity. It is the difference between an agent programme that pays for itself and one that quietly does not.

Before reaching for a metering proxy, I wanted to know what the coding agents I already run log on their own. So I pointed a throwaway script at the session directories of omp and pi, and summed everything.

The short version: the logs contain per-message cost, computed by the agent itself, for every model call including subagent conversations. One month of my usage came to $7,976.69. A hand-checked session matched the script to four decimal places.

The scope

Two coding agents, one machine, no new infrastructure. The reader walks the local session logs of omp and pi, sums the cost each response record already carries, and later joins sessions to work items through git history: Linear projects and tickets, then pull requests. Nothing is instrumented. If the agent stops writing these logs tomorrow, the ledger stops with it, which is the honest failure mode for a measurement project.

Left out on purpose: cloud sessions that never touch this machine, re-pricing tokens from published rate tables, and anything that needs a proxy in the request path. The point is to find out how far already-collected data goes, and where it stops being enough.

What is in a session file

Both agents store sessions as JSONL under a directory named after the working directory, under ~/.omp/agent/sessions and ~/.pi/agent/sessions. Each assistant response is one record with the model, provider, and a usage object. The usage object carries token counts split by class, and a cost object the agent computed itself:

"usage": {
  "input": 2, "output": 574,
  "cacheRead": 0, "cacheWrite": 700943,
  "cost": {
    "input": 1e-05, "output": 0.01435,
    "cacheRead": 0, "cacheWrite": 4.38089375,
    "total": 4.39525375
  }
}

That is a large cache write from an Opus session. Cache write is billed at a premium on Anthropic, and it shows up exactly where you would want it, attributed to the message that caused it. Records also carry a responseId, one per API call, so summing is trivially dedupe-safe. Anthropic records add a cache TTL breakdown; other providers do not, which caps how precisely you can model cache pricing outside Anthropic.

Nothing here is scraped or estimated. The agent did the pricing when the response came back.

Subagent conversations are separate files

The part I expected to be hard, attributing subagent spend, turned out to be a directory listing. When a session spawns subagents, each one gets its own transcript next to the parent: omp writes them as named files in the session’s directory, pi nests them under hash directories per run. Same record format inside. Walk the directory, sum the parent, sum the children.

One session from late August made this concrete. It ran 113 subagents. The parent conversation cost $732.01, the subagents $903.69, so more than half the session’s spend happened outside the conversation I was watching. Any metering approach that only sees the top-level API key would have undercounted it by that much.

What the sums say

Across 54 omp sessions in the last 30 days, grouped by model:

$  6591.27  claude-opus-5
$   691.42  glm-5.3
$   586.49  claude-fable-5
$   106.40  glm-5.2
$  7976.69  TOTAL

The cheapest capable model carried nearly all the subagent work, which is only visible because subagent transcripts are separate. The pi corpus summed to almost nothing, twelve cents, because most of those sessions ran local or free-tier models. Same format, same script, one path changed.

I verified the reader against one session by hand: summing the per-message costs in an editor gave the same $1,635.70 the script produced. Compaction is append-only with an epoch marker, so replays of long sessions do not double-count rewritten turns.

What the logs cannot say

The honest limit: no record carries a branch, pull request, or ticket. The session header stores the working directory and timestamps, nothing more. So the logs answer “how much, when, on which model, in which directory” but not “for what shipped work”.

That is a join problem, not a logging problem. The join from session logs to git history and pull requests is what the Agent Spend project is for, and it is the piece none of the gateway products sell because they never see the session.

The reader is a few hundred lines of stdlib Python. If you run a coding agent, check your own sessions directory before signing up for a metering proxy. The numbers are probably already on disk.

All articles