There is a useful way to think about these files. The model has no memory of its own; when the session ends, everything it will ever be able to recall about that refactor is what it managed to write down at the time. The session file is the agent’s dream journal, kept while the dream is happening. Six agents keep six very different journals, and the differences are not cosmetic. They decide what the agent can resume, what a tool like a history browser can show you, what you can audit six months later, and what is silently lost.

A companion post covers where these files live on disk. This one is about what is inside them. We measured it.

Method

We ran a read-only measurement harness over every session store on one machine: 184 Claude Code sessions, 2,706 Codex rollouts, 14 Cursor Agent transcripts, 20 Copilot CLI sessions, 61 OpenCode sessions, and 111 Hermes sessions, spanning August 2025 to July 2026. The harness parses every event, classifies it (user message, assistant message, tool activity, metadata), and records aggregates only: counts, byte sizes, ratios, field coverage, timings. No transcript content leaves the analysis, and the numbers below are corpus totals, not excerpts. The script and the raw aggregates are in the Agent Sessions repo.

Honest caveats, stated up front. This is one machine and one user, so the usage mix differs per agent: Codex did most of the daily work here, Cursor saw fourteen sessions. Cross-agent comparisons are indicative, not a controlled experiment. Where a number depends on usage rather than format, we say so.

Finding 1: the journal is almost all margin notes

The first thing the data shows is how expensive remembering is. Divide each store’s total size by the number of user-visible messages in it, and you get the cost of remembering one human sentence:

The headline ratio is starker than the bar chart. In the Claude Code corpus, visible conversation text (what you typed plus what the model said to you) is 3.0% of the bytes. In Codex it is 2.6%. Everything else is tool calls, tool output, reasoning items, metadata envelopes, and bookkeeping. The journal is almost entirely margin notes about the dream, not the dream itself.

That is not waste, mostly. Tool output is the evidence of what actually happened, and it is the part you grep for later. But the volumes are worth knowing: the largest single Codex session on this machine is a 212 MB JSONL file, and Claude Code’s largest is 19 MB. Any tool that reads these naively into memory will eventually meet one of those.

Cursor is the interesting outlier. At 1.8 KB per user message, with half its bytes being visible text, its transcript is lean because it is incomplete: in our corpus it records zero tool events and zero per-event timestamps. The transcript reads well and remembers almost nothing about how the work was done. It is a diary with the verbs removed.

Finding 2: some agents know what they cost, and some have no idea

The second axis is self-knowledge: what the format records about its own execution. The spread here is wide.

Copilot CLI is the quantified dreamer. Every assistant message carries the model name, output token count, and request IDs; every tool execution carries the model that requested it; and at shutdown it writes a full accounting event: total conversation tokens, premium request count, API duration, even the size of its own event file. Hermes keeps a ledger in the same spirit: its sessions table has thirty-three columns, including input, output, cache-read, cache-write, and reasoning token counts, plus estimated_cost_usd and actual_cost_usd. OpenCode records tokens and a cost figure on each message row. These three can answer “what did this session cost” from local data alone.

The bigger names are thriftier. Codex writes turn-level token_count events with cumulative usage, which is enough for totals but not for per-message attribution, and no dollar figure. Claude Code stamps every assistant event with the model and a usage block, which is genuinely good, and also the occasion for a correction: our companion post claimed Claude Code writes no per-event model. Wrong. In this corpus, all 36,376 assistant events carry message.model. We measured our own claim and it failed; the fix is in both posts.

Cursor’s transcript records none of this. The model hint lives in a separate metadata database, and the events themselves are undated. If you want to know what a Cursor session cost, the answer is on the vendor’s dashboard, not your disk.

Finding 3: the dreams they are no longer allowed to reread

Reasoning is where the field is converging, quietly, on the same policy: sealed.

Codex is explicit about it. In the forty most recent rollouts here, all 7,339 reasoning items are opaque encrypted_content blobs. They sit on your disk, in your file, and neither you nor the agent that wrote them can read them back.

Claude Code turns out to have gone the same way, with less announcement. Its thinking blocks have a thinking text field and a cryptographic signature. In the thirty most recent sessions on this machine, 2,567 of 2,628 thinking blocks have a signature and an empty text field. About 2.5% still carry plaintext. The agent’s private reasoning is now certified rather than recorded: the file can prove the thinking happened, and cannot say what it was.

The rest of the field is split. Copilot writes both a reasoningText and a reasoningOpaque field, hedging per message. OpenCode stores reasoning as first-class part rows, 743 of 1,207 with readable text, the rest empty depending on the provider. Hermes keeps a plaintext reasoning_content column.

There are real reasons for sealing: provider policies, distillation concerns, resumability across stateless APIs. But it changes what your archive is. A year of session history used to include why the agent did things; increasingly it only includes what it did. If the why matters to you, the readable summary the agent chooses to say out loud is now the only record of it, which is worth knowing when you decide how much to trust that summary.

Finding 4: remembering is not the same as being able to recall

The last measurement is retrieval. A memory you cannot search is barely a memory, and this is where the two storage philosophies split cleanly.

The JSONL camp (Claude Code, Codex, Copilot, Cursor) has no index of any kind. Finding a word in this machine’s 3.4 GB of Codex history means reading 3.4 GB: a naive grep -rl takes 10.8 seconds, and a full structured parse of the corpus takes 16.6 seconds. Do that on every keystroke of a search box and you understand why history browsers build their own indexes.

Hermes answers the same class of question in 0.4 milliseconds, four orders of magnitude faster, because it ships a trigram full-text index inside its database. It pays for recall honestly: twelve of its eighteen tables are search infrastructure, and actual message content is about 11% of the database’s bytes. Hermes spends most of its memory on being able to remember. OpenCode sits in between: proper relational rows (a query away from anything) but no full-text index, and reconstructing one message means joining an average of 3.6 part rows.

Neither philosophy wins outright. JSONL survives crashes by construction (a truncated last line is the entire failure mode), diffs cleanly, and can be read by any tool ever written. Databases answer questions. The scorecard shows how each agent actually trades this off:

The bottom row deserves its own sentence. None of the six formats has public schema documentation. Every parser of these files, including ours, is built by reverse engineering, and every one of them breaks a little when a vendor renames a field. For files this valuable, that is a strange industry norm.

What a session format should be

Having read a million events written six different ways, here is the standard we would hold any of them to, and how the field measures against it.

Write like a log, read like a database. Append-only JSONL for the write path, because a crash mid-write should cost one line, not a database recovery. A sidecar index (SQLite is fine) for the read path, rebuilt from the log whenever it is stale. Today every agent picks exactly one half: the JSONL camp cannot search and the database camp cannot tail -f. Hermes is closest to the right shape, but the log half of it is inside the database rather than beside it.

Attribute every message. Model, timestamps, token usage, and cost belong on each message, not in a session header, because sessions switch models mid-flight and post-hoc accounting depends on it. Claude Code and OpenCode are closest here. Codex should move usage from turn level to message level. Cursor should start writing timestamps into its own transcript, which in 2026 is a modest ask.

Seal reasoning honestly. If reasoning must be opaque, say so in the format: a documented field, a stated policy, and a user-visible switch where policy allows one. Claude Code’s silent shift from plaintext thinking to signature-only is the pattern to avoid, less because of the sealing than because nothing announced it. Users planning to audit their own history a year out deserve to know the why is no longer being kept.

Publish the schema. One versioned page per vendor, listing the event types and stability guarantees. Codex already versions its files internally and tolerates unknown fields, which is most of the work. The ecosystem that wants to exist around these files — history browsers, usage analytics, team knowledge tools — is currently built on guesswork.

The files themselves are the good news. Every agent in this study writes its journal locally, completely, and by default, and none of it leaves your machine on its own. The formats are six dialects of the same instinct, and the instinct is right: the work is worth remembering.

Agent Sessions is a free, local-only macOS browser for all six of these stores; it reads them read-only and never writes back. The measurement script and raw aggregates behind every number here are in the repo, and the companion post on the exact disk locations is here.

That matters because this data is often the only durable record of how a piece of work actually happened: the command that failed, the path you settled on, the reason a function looks the way it does. It is genuinely valuable and genuinely scattered. Most people assume old agent history is gone, or trapped somewhere unreachable, when in fact it is sitting in a predictable file a couple of directories deep. Here is where each major agent actually keeps it, grounded in how Agent Sessions parses each one.

Claude Code — per-project JSONL

If you have wondered where Claude Code stores history, the answer is a tree of JSONL files under your home directory:

~/.claude/projects/<encoded-cwd>/<session-id>.jsonl

The clever, occasionally confusing part is the folder name. Claude Code takes the working directory you launched from and replaces every / with a -, so a session run in /Users/you/Repository/app lands in a folder named -Users-you-Repository-app. One directory per project, one .jsonl file per session, named by the session UUID. Agent Sessions also honors the CLAUDE_CONFIG_DIR and CLAUDE_CONFIG_DIRS environment variables and Claude Desktop’s local-agent-mode roots, because Claude Code will follow those when they are set.

The format is JSON Lines: one JSON object per line, one line per event. If you want to read Claude Code JSONL yourself, two details will trip you up. First, the user’s message text is not at the top level. It is nested inside message.content, while Codex and others keep it flatter. Second, there is no per-event model field. Claude Code records a version (like 2.0.5), a cwd, a gitBranch, and a sessionId, but which model answered is simply not written per turn. Events also thread as a tree through uuid and parentUuid, and some lines are metadata (summary, file-history-snapshot, or anything flagged isMeta) rather than conversation. Parse for type == "user" and skip the meta lines, or your transcript fills with noise.

Codex — date-sharded rollout files

Codex session files live in a location that is easy to state and easy to get wrong:

~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl

The gotcha is the environment variable. If CODEX_HOME is set, that entire tree moves: the real root becomes $CODEX_HOME/sessions, and anything hard-coding ~/.codex/sessions quietly finds nothing. Inside, Codex shards by date into YYYY/MM/DD/ folders and writes one append-only JSONL file per session, named rollout-YYYY-MM-DDThh-mm-ss-<uuid>.jsonl. The timestamp is baked into the filename, which is why Codex’s own resume picker sorts sessions newest-first by the name rather than by file mtime.

Two more things worth knowing. Codex is deliberately tolerant of schema drift, so field names vary between client versions and unknown fields should be preserved rather than dropped. And when you run with the Responses API under zero-data-retention or stateless mode, reasoning items come back as opaque encrypted_content blobs. They are base64, they are not decryptable locally, and a viewer should treat them as sensitive and leave them alone. CLI, Desktop, and VS Code Codex all write into this same rollout corpus, which is convenient: one location covers three surfaces.

Cursor — one session, two stores

Cursor is the odd one out because it splits a single session across two files in two formats. The readable transcript is JSONL:

~/.cursor/projects/<project>/agent-transcripts/<id>/<id>.jsonl

The per-session metadata lives in a small SQLite database next door:

~/.cursor/chats/<md5(project-path)>/<session-id>/store.db

That <md5(project-path)> is exactly what it looks like: the workspace folder is the MD5 hash of the project path. To assemble complete Cursor Agent history you read the JSONL for the actual events and the store.db for the session name, model hint, timestamps, and workspace context. One without the other gives you half the picture.

There is an honest boundary here, and it is worth stating plainly. This covers Cursor Agent transcripts, the ones that produce a JSONL file. Cursor’s older IDE-chat history that lives only inside the database is stored as protobuf message blobs, and those are not decoded into transcript events. If a chat never produced an agent transcript, there is nothing readable to show.

OpenCode — a session database, not files

OpenCode is the cleanest example of the industry drift toward databases. Recent versions (v1.2 and up) keep the OpenCode session database at a single path:

~/.local/share/opencode/opencode.db

Older installs used per-file JSON under ~/.local/share/opencode/storage/session, and Agent Sessions still falls back to that when no database is present. But the modern layout is one SQLite file. The detector prefers it whenever opencode.db exists and actually contains a session table, then reads session metadata, message rows, and — this is the part people miss — separate part rows. A single message’s content is spread across multiple part rows, so reconstructing a turn means joining messages to their parts and ordering by time. It is a real database schema, not a log you can tail.

The others — Copilot and Hermes

Two more worth a mention, because they show the same two patterns.

GitHub Copilot CLI writes JSONL under ~/.copilot/session-state/, and it recently changed its layout. Legacy installs wrote a flat <session-id>.jsonl; current versions (v1.0.11+) write <session-id>/events.jsonl inside a per-session directory, with the session name living in a sibling workspace.yaml. Same format, moved one level deeper.

Hermes went the OpenCode route. Current versions store everything in ~/.hermes/state.db, a SQLite database, with a legacy ~/.hermes/sessions/session_*.json fallback for older installs. Check the database first; fall back to JSON only when it is absent or empty.

The whole map, in one table

What to take from this

The pattern underneath the mess is a slow migration from flat JSONL to SQLite. JSONL is trivial to append to and trivial to read one line at a time, which is why the CLI-first agents started there. Databases give you indexed queries and atomic writes, which is why OpenCode and Hermes moved. Both are honest choices. Neither is documented as prominently as it should be, and every one of these paths has at least one detail that quietly breaks a naive reader: the encoded folder name, the relocating environment variable, the two-store split, the message-versus-part rows.

None of this data leaves your machine unless you send it somewhere. It is all sitting locally, and it is all readable if you know the path and the format.

Agent Sessions reads every one of the locations above into a single searchable macOS app. It is free, local-only, and has no telemetry; it opens these files read-only and never writes back into them. If you would rather not memorize six paths and two schema quirks, the source is on GitHub, and more posts like this one live at /blog/.

Agent Sessions ships a Quota Meter with a Session Runway drawer built to answer what the percentage can’t: how much of the Claude limit is left as a trajectory rather than a level, which session is spending it, and when the current pace runs the window dry. The math below is everything that view computes, including the places where the source data forces some honesty about precision.

What the percentage actually reports

Because both providers meter on rolling windows, the question of when the Claude limit resets has no fixed daily answer; the reset lands five hours after the window opened, wherever that happened to fall in your day. A moving target already argues for tracking a rate. The raw reading argues harder, because it is coarser than most people assume.

On Claude, Agent Sessions reads usage from the OAuth endpoint, and that payload reports whole-percent values: five_hour.utilization and limits[].percent move in steps of a full 1%. One percent of a 5-hour window is the finest change the endpoint will ever show. The app polls every 60 seconds, but the fetch underneath is cache-first: when the shared usage cache is younger than 180 seconds, the cached payload is served and the live API call is skipped. The sharing is deliberate, and the second half of this post explains it. The immediate consequence is that a raw Claude percentage is coarse and slightly behind reality at the same time.

A perfectly fresh percentage would still be ambiguous, though, because a level admits opposite explanations. As an illustration: “29% used” at 10:00 and “29% used” at 10:30 are the same reading, and one can be a quiet morning while the other is a session that consumed a quarter of the window in ten minutes and just went idle. Nothing in the number separates those cases, because nothing in the number involves time.

Turning token logs into a rate

The alternative is arithmetic on data every agent already writes to disk. It takes three steps.

Per-session tokens per second. Every agent turn appends its token usage to the session transcript. Agent Sessions tails those files and computes a recent tokens-per-second figure for each session. Two adjustments come straight from how the logs behave:

• Cache reads are billed at a steep discount, so the parser weights them at 10% of their raw count. Without the weighting, a session re-reading a large context looks like it is torching the quota while it is mostly paying the cache rate.
• Streaming writes duplicate usage rows that share a message id, so the parser dedupes on the id. Otherwise every burst would be counted several times.

There is also a bootstrap problem, since a measured rate needs two samples spaced apart. The first completed turn therefore yields a provisional rate from that turn’s own duration, so a number appears immediately, and a measured burst rate replaces it once a second sample lands. Provisional rates are additionally capped at the largest measured rate among peer sessions, because a cache-heavy first turn can read as tens of thousands of tokens per second and would otherwise claim nearly the whole attribution split by itself.

From tokens to quota. Tokens per second is not quota. The account-level percentage moving over time is the only ground truth for quota burn, so the app distributes that account-wide rate across active sessions in proportion to their token rates. Each session ends up with a percent-per-second figure, displayed as quota minutes per hour. The unit is less exotic than it sounds: 100% of a 5-hour window is 300 quota minutes, so a session showing 40 m/h (an illustrative number) spends forty of those minutes for every hour it keeps running.

Projecting run-out. With a rate in hand, run-out is division: remaining percent over burn rate. When the projected run-out lands before the reset, the drawer can warn while there is still time to act. One implementation detail deserves a warning label, because the obvious version is wrong. When no fresh account projection exists, the tempting fallback is to assume run-out at the reset time, which makes the implied rate remaining / time-to-reset. That denominator shrinks toward zero as the reset approaches, so the per-session numbers inflate at exactly the moment a calm reading matters most. Agent Sessions anchors the fallback to average burn instead: percent used divided by elapsed window time, with elapsed floored at 10 minutes so a heavy burst right after a reset cannot inflate the early-window side by the mirror-image mechanism. The average-burn rate never blows up, stays conservative by construction, and hands over to measured velocity whenever a fresher projection arrives.

Coarse by design on Claude

The two providers do not give out equal data, and the app does not pretend they do.

Codex writes fine-grained rate-limit samples into its own session logs and serves account state over local CLI-RPC, updated frequently. Per-session burn can be read directly, projections form readily, and a “fresh” indicator on Codex genuinely means fresh. When the question is how fast you are approaching the Codex usage limit, the transport supports a live answer.

Claude offers no equivalent. The only account signal is the OAuth usage endpoint, and Agent Sessions reads it through a cache file shared with the Claude Code statusline (/tmp/claude/statusline-usage-cache.json). A running Claude Code session keeps that file warm, and the app re-serves it rather than issuing its own request whenever the file is younger than 180 seconds. That is cooperation rather than laziness: polling the endpoint aggressively earns a 429 with a retry clamp of about five minutes, and independent polling would compete with the statusline for the same budget. The cost of cooperating is that Claude’s projection extras, the live ETA badge and the sharpening from average burn to measured velocity, form far less often than they do for Codex. When the underlying number has not moved, the app says it is waiting for a usable sample. Inventing a trajectory from a flat number would produce a reading that is confident, precise-looking, and made up.

The burn measurement survives all of this on purpose. Per-session burn comes from token attribution in the transcripts, which the app reads directly and continuously, so the Session Runway bars stay live on Claude regardless of how stale the account projection is. An earlier version gated the burn display on a fresh projection, and that gate was removed for Claude precisely because it made the bars appear late and flicker. What degrades on Claude is projection polish; the answer about which session is eating the window, and how fast, does not degrade at all, and that answer is the reason the drawer exists.

What the drawer shows

A session that is burning but projected to fit inside the window gets a small smiling face in its run-out column, with a quieter dot available in Preferences for anyone who wants less personality. A session on track to run past the reset carries its projected run-out time and rises up the ranking. Freshness is enforced per row as well: when the latest token sample is older than 30 seconds, the rate falls back to a waiting state rather than showing a stale figure, so a stopped session clears quickly. By default the drawer appears only when the runway is actually running low; it can also be pinned always on or always off.

The practical difference, again with illustrative numbers: instead of “7% used,” the readout becomes “this session spends 40 quota minutes per hour, it is the main drain on the window, and at this pace it runs out 25 minutes before the reset.” That sentence supports a decision. Pause the expensive session, or let the small ones ride to the reset.

Try it

Agent Sessions is a free, local-only macOS app for browsing and searching Claude Code and Codex sessions; the Quota Meter and Session Runway ship with it. There is no account and no telemetry, and it reads the same local logs your agents already write. The code behind everything described above is public: download it or read the source on GitHub.