DEV Community: Ethan

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

Ethan — Fri, 23 Oct 2026 02:23:21 +0000

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:

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.
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.
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:

	Before	After simem	Shorter by
All tool reports	1.16M tokens	0.90M tokens	22%
Test reports	26k tokens	14k tokens	46%

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

Say to your agent	What happens
"Why did we pick Postgres?"	Searches every agent's past sessions, by keyword and by meaning.
"Remember that we deploy only from CI."	Saved as a decision. Every agent and account sees it from now on.
"Forget that."	Archived for good, even if old transcripts mention it again.
"How much did simem save this week?"	Your real token usage and what simem kept out, measured vs estimated.
"Continue." (in the other app)	Picks up the other agent's latest work.

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

Hit Your Claude Code Usage Limit? Switch to Codex Without Losing Context

Ethan — Sat, 15 Aug 2026 04:08:22 +0000

It was 4:07 PM. I was three files deep into a refactor, the agent finally understood the weird shape of my billing module, and then:

You've reached your usage limit. Try again at 6:00 PM.

I had two other coding agents installed and signed in. Both had quota left. Neither had the faintest idea what I'd spent the last two hours doing.

So I did what everyone does. I opened the second agent, re-explained the goal, pasted the plan, watched it read twenty files to rebuild context I had already paid for, and then watched it cheerfully undo a decision I'd made on Tuesday - because nobody told it that decision existed.

That afternoon is the reason I built mixai.

npm install -g mixai-cli

The actual problem isn't the limit. It's that context is trapped.

Most of us now have more than one AI coding agent installed. A Claude Code subscription. Codex through a ChatGPT plan. Cursor's free tier. Antigravity's free tier. On paper that's a lot of capacity.

In practice it behaves like four separate, amnesiac contractors who refuse to talk to each other. Every one of them keeps its context in its own private session format, in its own directory, and none of them can read the others'. So the moment one stops - quota, rate limit, or just "I'd like a second opinion on this" - you personally become the integration layer. You're the one carrying the objective, the constraints, and the "no, we tried that, it didn't work" across the gap.

That's the expensive part. Not the limit - the re-explaining.

What mixai does

mixai is a small command-line tool that sits beside the agents you already use. It doesn't replace them, doesn't proxy your requests, doesn't touch your API keys, and doesn't send anything to a server. It does two things:

1. It hands your work off between agents in one command.

mixai switch codex --from claude

That writes a checkpoint of your current session to a local .mixai/ folder - the objective, the conversation, your branch and HEAD, a patch of your uncommitted changes, and the project's accumulated decisions - then opens Codex with a continuation prompt pointing straight at it. You type "continue." That's the whole ritual.

2. It gives every agent a shared memory of your project.

Decisions, constraints, and preferences get captured once and are available to all of them. Ask any agent "why did we drop the queue?" and the answer is already in context, because a different agent recorded it three weeks ago.

The part I care about most: creating a handoff never calls a model. It's file parsing and file writing. It costs zero tokens, which is exactly what you need, because the moment you most want to switch agents is the moment you have no tokens left to spend on switching.

Why this matters if you're optimizing for cost

Here's the thing nobody says out loud: your quotas don't run out at the same time.

Claude's window resets on its own clock. Codex is tied to your ChatGPT plan. Cursor and Antigravity have their own free tiers. They are four independent budgets, and most developers burn one to zero and then just... stop for the day, because moving to another agent has felt more expensive than waiting.

Make the handoff free and the math flips completely. You stop treating "AI coding capacity" as one bucket you can empty, and start treating it as four buckets you rotate through.

Every one of those arrows is one command, and none of them costs a token. You're not sharing credentials or pooling accounts - each agent signs in the normal way, with its own login, under its own plan. mixai just makes moving between them cost nothing.

For a hobbyist on free tiers, that's the difference between a 90-minute coding session and an all-day one. For a team paying for seats, it's the difference between "wait for the reset" and "keep shipping."

What actually moves between agents

I want to be specific here, because "it transfers your context" is the kind of sentence that means nothing.

When you run mixai switch, it:

Reads the source agent's own local session log - the real conversation, not a summary you had to write.
Snapshots the workspace - branch, HEAD, git status, and a diff of your tracked changes.
Writes a checkpoint to .mixai/checkpoints/<id>/ and mirrors it to .mixai/current/:
- BRIEF.md - a deliberately tiny file: current objective + git state
- HANDOFF.md - objective, last outcome, recent conversation, relevant memory
- TRANSCRIPT.md - the full extracted conversation, for when more detail is needed
- WORKSPACE.patch - your uncommitted changes as a diff
Launches the target agent with a continuation prompt that says, in effect: read this checkpoint, inspect the live git state, and continue the unfinished objective - don't redo completed work.

Your repository stays the source of truth. The checkpoint is just a portable bundle that any agent can read, because it's plain Markdown and a patch file. If mixai vanished tomorrow, you could open HANDOFF.md yourself and paste it anywhere.

The memory half: agents that stop starting from scratch

Handoff solves the moment of switching. Memory solves everything after it.

Every checkpoint gets indexed into a local SQLite database and distilled into durable facts - decisions, constraints, preferences - plus a short summary. Then:

Recent history stays verbatim. Older history folds into compact digests, and those digests fold into a project-level digest.
Durable facts never expire. A constraint you set in month one is still there in month six, even after the raw conversation that produced it has been compressed away.
Search works out of the box using SQLite's FTS5 full-text index with BM25 ranking. If you happen to have Ollama running locally, it layers in semantic search automatically. If you don't, it just works with keyword search.

mixai memory search "why did we pick Postgres over Mongo"

Any agent can ask that. Not just the one that was there.

Once you run mixai integrate in a project, this stops being something you have to remember to do. It wires into each agent's lifecycle hooks: relevant memory is injected per prompt, context is restored after a compaction or reset, and agents that speak MCP get direct tools (memory_search, memory_save, context_brief, list_handoff_targets, switch_to_provider) instead of shelling out.

That last pair matters more than it sounds: it means an agent that notices it's hitting a limit can check which other agents are ready and offer to hand off - and only after you say yes.

Smaller prompts, and honest numbers

Context windows are the other place tokens quietly evaporate. mixai is fairly aggressive about staying small:

Memory search returns previews, not full records. You drill into the full text only when you actually want it.
Older summaries are rolled up into digests instead of accumulating forever.
Everything injected into a prompt is hard-capped by a character budget.
Two on-demand code-map tools - code_outline and code_find_references - let an agent jump to the right lines instead of reading (and re-reading) whole files. Unlike an always-loaded "repo map," they add nothing to every message.

And then there's the part I'm oddly proud of: mixai refuses to make up savings numbers.

mixai memory savings

disclosure: 2 event(s), ~549 tokens (2197 chars)
Total: ~549 tokens (2197 chars) across 2 event(s).
This counts only exact, measured deltas mixai can prove from its own
compression - it does not estimate what re-exploring the repo without
mixai would cost.

Every number there is a real measured delta between what would have been sent and what was actually sent. There is no "saves you 80% of your tokens!" mechanism, because measuring that honestly would require knowing what a from-scratch agent would have spent re-exploring your repo - and mixai can't observe that. There's also mixai memory spend for a full per-agent, per-purpose cost breakdown.

Getting started (about two minutes)

# 1. install
npm install -g mixai-cli

# 2. see what you've actually got installed and signed in
mixai status

# 3. once per project: wire it into your agents
cd your-project
mixai integrate

Then use it:

# hand off when you hit a limit
mixai switch codex --from claude
mixai switch cursor --from codex
mixai switch claude --from cursor

# branch a separate conversation, leaving the original alone
mixai fork codex

# save a checkpoint without opening anything
mixai export

# route a one-off task to whichever agent is available
mixai run "Explain the architecture and flag the riskiest module"
mixai run --write "Add input validation and tests"

# ask your project's memory a question - costs nothing
mixai memory search "why did we drop the queue"
mixai brief

mixai brief is the one I reach for most often, honestly. After a context compaction, it reloads the objective, live git state, and the most relevant project memory - without the agent re-reading your repository to figure out where it was.

The honest caveats

Node.js 22.5+ is required for the persistent-memory features (it uses Node's built-in SQLite).
macOS gets one-click desktop handoffs. On other platforms you use the agents' terminal CLIs via --surface interactive.
For desktop handoffs, mixai prints a short instruction to paste into the app it just opened. It's a copy-paste, not magic.
You need at least one supported agent installed and signed in: Claude Code, Codex, Cursor, or Antigravity.
npm install -g does not wire mixai into your projects. mixai integrate is a separate, per-project step - and mixai integrate --remove cleanly undoes every change it made.

And what it deliberately is not: it's not a proxy, not a model router in front of an API, and not a place you put credentials. Each agent uses its own local login. Everything lives in .mixai/ inside your project, gitignored by default. Nothing is uploaded.

Try it

If you've ever stared at a "usage limit reached" message with two other perfectly good agents sitting idle on your machine, this is for you.

📦 npm: npm install -g mixai-cli
🐙 GitHub: github.com/thinhledev/mixai - MIT licensed, and a ⭐ genuinely helps
🐛 Issues and ideas: github.com/thinhledev/mixai/issues

I'd especially like to hear which agent combinations you rotate through, and where the handoff still loses something it shouldn't. That's the part I'm still tuning.

What's your current workaround when an agent hits its limit mid-task? I'm genuinely curious - drop it in the comments.

How I Improved My Verbal English with NativeSpeech 🤯

Ethan — Tue, 07 Oct 2025 09:06:27 +0000

MOTIVATION

I still remember the first time I froze during a live architecture walkthrough. My hands were shaking, the cursor blinked, and instead of explaining the tradeoffs I muttered “um” and “so” until the meeting drifted. As a non-native English developer, those moments cost me: unclear PR feedback, awkward stakeholder demos, and missed callbacks after interviews.

I wanted something practical, not generic chitchat drills, but targeted practice for explaining systems, debugging live, and answering interview follow-ups. That pressure to communicate clearly drove me to find a tool I could use every day between sprints, not just on weekends.

“I wanted to explain my microservice design in three minutes, without sounding like a translator.”

SOLUTION

My problems were concrete: I stumbled over technical vocabulary when under pressure, I couldn’t narrate a live debug session succinctly, and asynchronous standups turned into vague messages because I lacked concise phrasing.

I evaluated a few solutions (language courses, meetups, and mock interviews). Then I found NativeSpeech and decided to try it because it has some awesome features: interactive, AI-driven speaking practice with real-time feedback, AI-evaluated scores so I could track progress, and built-in exercises/stories to practice different contexts. The site also mentions a Chrome extension for practicing in other web tab (e.g you can use the extension on ChatGPT website).

What convinced me most: the app isn’t just about repeating phrases, it offers an interactive mode and a pronunciation checker, plus translation/listen features that help me map technical terms to natural phrasing. That was exactly what I needed: targeted, measurable practice that fits between meetings.

My 30-Day, Developer-Focused Routine

Below is the exact routine I followed. I treated it like a sprint: measurable goal, daily standups with myself, and metrics to measure.

Set the goal (Day 0): “Explain my microservice architecture + a recent bug root cause in under 3 minutes, with <10 filler words.”.

Block time (Daily, 20 minutes): I reserved a 20-minute slot after lunch. Consistency beat duration, 20 minutes every weekday.

Warm up: Pick an AI-generated short story or prompt in NativeSpeech’s library to loosen pronunciation and rhythm. This warmed my mouth and reduced initial stumbles.

Roleplay: system design: I used Interactive Mode to roleplay, “You’re a PM. Explain the microservice flow and why we chose eventual consistency.” I focused on intent and tradeoffs, not code lines. The AI teacher provided instant feedback and maintained a continuous interactive conversation.

Record a bug explanation: I narrated a recent bug fix: what happened, root cause, and the patch. Then I replayed it, counting filler words and noting sentences where technical phrases broke my flow.

Example dev scenario: “We had a N+1 query in the notification service; I explained how a missing index plus lazy loading caused a cascade. I practiced summarizing the root cause in one sentence, then the mitigation in two bullet sentences.”

Review & log metrics: I recorded words per minute (rough measure), number of filler words, fluency score from the app, and my pronunciation score. I saved the generated bug story along with the pronunciation scores. The AI-evaluated scores helped me measure progress objectively.

Apply in real life: After day 7, I used the practiced 3-minutes microservice summary in a sprint planning demo. On day 10 I presented to a stakeholder and noticed ~60% fewer filler words compared to my first recording, I timed it and compared counts. That confidence changed the tone of the meeting: fewer interruptions, clearer questions, faster buy-in.

Iterate weekly: Each Sunday I reviewed my saved progress, picked the weakest area (pronunciation of a key library name, or long-winding sentences), and built the next week’s prompts around it.

Bold outcome: After 30 days, my PR descriptions became shorter, async standups were clearer, and technical interviews felt like conversations instead of tests.

Pro tip:

Keep practicing each word until your overall speech reaches the maximum pronunciation score (ideally 100). Repeat this every day with a different generated story to improve your speaking skills and help your mouth stay familiar with English. You can even save your stories and share them with your friends.

Try it yourself

If you’re a developer who wants clearer design walkthroughs, less stalling in interviews, or smoother async updates, try the same 14–30 day routine I used. NativeSpeech gives instant pronunciation feedback, AI-evaluated scores, an interactive teacher, and a Chrome extension for quick browser practice, everything I used to make my daily 20-minute habit stick.

Challenge: Try 14 days of 15 minutes daily. Track filler words and app scores. Report back, I’d love to hear which dev scenario improved most for you.

Start here: https://nativespeech.app/