My AI coding agents read 1.2 billion tokens in 32 sessions. Most of it was text they'd already seen.

I asked my coding agents a simple question: how much did you actually read while we built this project?

The answer: about 1.2 billion tokens, across 32 work sessions in Claude Code and Codex.

A token is roughly ¾ of a word, so that's around 900 million words. About 10,000 novels. For one side project.

The part that bothered me wasn't the size. It was that most of it wasn't new. It was the same conversation being re-read turn after turn. The same test output. The same files. The same "so, how do you run the tests here?" that I had already answered on Friday.

So I built simem. It's free, MIT-licensed, and runs entirely on your machine. This post walks through the three problems it solves, with screenshots and numbers instead of vibes.

TL;DR

• Every new session starts from scratch. simem gives the agent a short summary of your project before you type anything.
• Memory is stuck in one app, one account, one folder. With simem it belongs to the project, and every Claude Code account, Codex and Cursor share it.
• Agents pay for the same text again and again. simem trims noisy tool output before it lands in the conversation: 81–99% off a full test or install report, and it never drops a failure line.
• Install: two commands inside Claude Code or Codex, then say "set up simem".

Problem 1: Every new session is Groundhog Day

You know this one.

On Friday you and your agent spent two hours on the billing module. You picked Postgres over SQLite for a reason. You found out the test suite needs a flag to run. You agreed never to deploy from a laptop.

On Monday you open a new session, and the agent knows none of it.

So it does what any smart new hire would do. It lists folders, reads the README, opens package.json, searches for "test", opens a dozen source files, and then asks you how the tests run. You can wait while it rediscovers your project (and pay for every page it reads), or you can type the whole explanation again.

The worst version: it confidently undoes a decision you made last week, because nobody told it that decision existed.

The right side of that image isn't a mockup. It's the real primer simem gave my agent at the start of a session in simem's own repo, trimmed to fit.

What simem does about it

What earlier sessions learned stays on your computer and comes back on its own, at three moments:

1. When a session starts, the agent gets a short summary of the project: the latest work (from any agent), the decisions still in force, the build and test commands that worked, and how the code is laid out.
2. With each message you send, simem adds the saved notes that clearly match what you wrote. Mention the database, and the reason you chose it comes along.
3. Whenever you ask ("what did we decide about payments?"), it searches everything earlier sessions saved.

To be clear about what it doesn't do: the agent still opens files to do the real work. What it stops doing is re-learning the project every morning.

Three details that matter if you care about cost:

• Building memory costs zero tokens. simem pulls decisions, constraints and preferences out of what you said using local rules, plus the apps' own session summaries. No model calls.
• It knows your project on day one. On install it imports your past sessions for the project, again without spending a token.
• It plays nicely with prompt caching. The primer stays byte-identical while your memory hasn't changed, so the provider's cache keeps hitting.

Problem 2: Your memory is locked in one app, one account, one folder

It's 4 PM. You hit the usage limit on your Claude account. You have a second account, or Codex, with plenty of quota left.

You switch, and you're back to a stranger who has never seen your code.

The same thing happens in quieter ways all the time:

• you open a new git worktree to run agents in parallel,
• you re-clone the repo,
• you rename the project folder,
• you try Cursor for one task.

Each agent keeps its memory inside its own app, and often ties it to the folder path. Switch any of those, and the memory stays behind.

simem's memory belongs to the project, not to an app or a login. The project ID is your repo's first commit, so it's the same in every clone and every worktree.

The best part in daily use: open Codex after Claude Code (or the other way round), type "continue", and the primer already holds the other app's latest work. No handoff doc and no copy-paste.

Moving to a new machine? Use simem memory export / import, or point simem at a folder you already sync (iCloud, Dropbox), optionally encrypted.

Problem 3: Your agent pays for the same text again and again

This is the one most people don't see, so here's the mental model I use.

Think of a conversation with your coding agent as a stack of paper. Every time you send a message, the whole stack goes to the AI, and the AI reads all of it again. Every page it reads costs money or eats into your plan's limit. Pages only leave the stack when the app compacts the conversation.

So what's on the stack? In my project, the biggest thing by far was reports from tools the agent ran: about 1.2 million tokens from 1,743 commands. Next came files the agent opened, about 430,000 tokens.

And tool reports are mostly noise. Run your tests and you get hundreds of lines of ✓ passed, ✓ passed, ✓ passed… with the one line you care about buried in the middle.

That's a jest run with one failing test out of 341, put through simem's actual filter. 112 lines in, 12 lines out. The failure, the expected and received values, the stack location and the summary are all still there, word for word. Everything else is saved on your disk in case the agent needs it later (simem out <id>).

Now remember the stack of paper. That report doesn't get read once. It gets read again on every turn after it:

That's a single test run. A real session has dozens of them, plus installs, builds and big file reads. Every page simem keeps off the stack is saved again on every later turn. The longer the conversation, the bigger the saving.

Here's how much each kind of report shrinks:

Look at the last row. A wall of compiler errors gets 0% trimmed, on purpose. The rule is simple: simem never drops a failure line. If every line is an error, every line stays.

It also guards the other big item on the stack, files:

• Large-read guard: when the agent tries to read a file over 800 lines in full, it gets the outline first, once. If it asks again, it gets the whole file.
• Re-read guard: reading an unchanged file that's already in context gets flagged once.
• Local code search: code_search returns path:line-range plus the signature, and code_read returns one function instead of the whole file.

The honest numbers

I don't trust tools that only show their best case, so here's the full picture. I took about 1,700 real tool reports from my own 32 sessions and ran them through simem:

Why only 22%? In my project the agent was already cutting most reports short itself, so there was less left to trim. When a report arrives in full, like a complete test run or package install, simem cuts 81–99% of it. Your numbers will depend on your work, and the repo includes a script that measures them on your own sessions (node scripts/replay-filters.mjs).

What it looks like in a real session

I didn't go looking for this one. In Claude Code, simem shows a short notice on its own (once per session, when it has saved at least 1k tokens that day). I asked the question it suggested, and the agent answered from simem's own records:

• ~310k tokens kept out of context, measured, across every agent session in the project.
• Six commands did most of it. Just 6 runs through simem exec kept out ~222k tokens, about 37k each. One large-read guard stopped a ~75k-token file read.
• ~22.9M tokens not re-sent, estimated, because whatever stays out of context isn't sent again on every later turn.
• The agent also pointed out where the rest of the savings are: command output filled ~4.1M tokens over 8,799 calls, and only 6 of those went through simem exec.

Every figure simem reports says whether it's measured or an estimate. I'd rather under-promise.

What simem doesn't do

Anything that touches your coding agent deserves suspicion, so here are the limits:

• No proxy. simem never sits between you and the model provider. It works through the apps' own hooks and tool (MCP) interfaces.
• No credentials. It never reads your API keys or logins.
• No server. Memory lives in ~/.simem on your machine. Nothing is uploaded.
• Secrets stay out. API keys, tokens, private keys and passwords are redacted from everything simem stores or shows.
• Your permission settings stay in charge. It only trims a command's output automatically when your settings would have allowed that command anyway.
• Easy to undo. simem init --remove restores every file it touched. Deleting ~/.simem removes all memory.

Install it in about a minute

Claude Code (desktop app or CLI):

/plugin marketplace add thinhledev/simem
/plugin install simem@simem

Codex:

codex plugin marketplace add thinhledev/simem
codex plugin add simem@simem

Then start a new session and say "set up simem". The agent asks before each step, installs the CLI, shows you what simem init will change, and runs it once you agree. You do this once per machine, not per project.

Prefer the terminal? npm install -g @simem/cli && simem init (Node.js 22.5+), or with Homebrew and no Node.js needed:

brew tap thinhledev/simem
brew trust --formula thinhledev/simem/simem
brew install simem
simem init

Day to day, you just talk to it

Try it, then tell me your number

Here's my ask. Install simem, work normally for a day, then ask your agent:

"How much did simem save?"

Post your number in the comments. I'm curious how it looks across different stacks, and especially where it doesn't help, because that's what I'll fix next.

If it saves you tokens (or just saves you from explaining your test setup one more time), a ⭐ on GitHub helps other developers find it.

GitHub: thinhledev/simem · npm: @simem/cli