Five coding agents, five formats, one table

This post compares how five coding agents — Claude Code, Codex, OpenCode, Gemini CLI and DeepSeek Harness — write down what they did: where the record lives, its format, how it counts cached tokens, whether it states a cost, and where it names the model. Then it shows the one table Caprock turns all five into, so their numbers can be added up.

Update, 2026-10-20: Caprock now reads a sixth, Hermes Agent, from its own SQLite database, and carries Hermes's cost figure through as it does OpenCode's.

A reader looked at Caprock and guessed what it does underneath: "parsing JSON, and sweating to build a coherent image out of huge and heavy JSON files." He was right, and it is the part of the product nobody sees. None of the five writes its record the same way, none promises to keep its format as it is, and Claude Code deletes its record after 30 days.

How each agent records its work

Three ways to get a believable wrong answer

Reading the files is not the hard part. The obvious reading of each can give you a number that looks right and is not.

Cached tokens counted twice. Claude Code reports fresh input and cache reads side by side. Codex reports the whole prompt as input, with the cached part as a subset of it. Treat the two the same way and every cached Codex token is billed twice — once at full price.

Tokens counted twice. Codex writes both a running total and a per-turn figure, and often writes the same sample twice in a row. Summing the per-turn figure on one real session gave 261,111 tokens; the true count was 137,739.

The model in the wrong place. Codex names the model in a turn context in 4 transcripts out of 100. In the other 96 it is inside the session's base instructions. Read only the obvious field and most of your Codex work has no model, so no price.

None of these mistakes raises a parsing error.

One table

Caprock reads all five as they are written and turns each into the same rows: one per turn, tool call or lifecycle event, with the same columns whichever agent produced it — agent, model, fresh input, cache read, cache write, output, cost, the folder the work touched.

That table is yours to take out. On my machine, on 1 October:

$ caprock export > record.tsv
$ wc -l record.tsv
  305162 record.tsv

Three hundred thousand rows from four agents, in about five seconds, as TSV, CSV or JSON lines. It reads the database without writing to it, works with Caprock stopped, and leaves out prompts and replies unless you ask for them. Here is one reply from each agent in it:

Look at the tokens_in column. Claude Code's fresh input is 2 tokens, because almost everything came from the cache; Codex's is 4,656 because the cached part has already been taken out of it. In the files they came from, those two numbers mean different things. Here they mean the same thing.

Four of the five report tokens and no cost, so Caprock prices them from a dated table of each provider's list prices. OpenCode computes its own cost, and that figure is kept as it is — two arithmetics over the same tokens would give one session two totals.

Why this is the part worth having

When a vendor changes its format, the table stays the same. The work of noticing is done once here, instead of by everyone trying to count what their agents cost.

The columns are documented in the schema. It is plain SQLite on your disk, with network features off by default.