How ContextForge Saves Tokens in Claude Code and Cursor

Last month I opened the usage page of my Claude account and did the math I had been avoiding. Most of the tokens I pay for are not the code the model writes. They are the same things I feed it again and again: what the project is, how it is laid out, which decisions we already made, which tool does what. I was paying to re-introduce my own project to the model several times a day.

So let me be upfront: ContextForge saves tokens, but there is no trick in it. It replaces the big blob of context you paste every time with a small lookup when the model actually needs something. Below is where the tokens go, what changes with a memory server, and where it doesn't help you at all.

Where the tokens actually go in a coding session

Before talking about saving anything, look at what a normal Claude Code or Cursor session spends on. In my projects it is always the same four things, in different proportions.

1. The static preamble. Your CLAUDE.md or rules file, loaded on every single session whether today's task needs it or not. In our own repo the two CLAUDE.md files add up to about 14 KB, roughly 3,500 tokens, before you type a word.
2. Tool definitions. Every MCP server you connect sends its tool schemas to the model at the start of the session. This one is invisible in the UI and it adds up fast. More on it below, with real numbers.
3. Re-explanation. "We use Postgres for sessions, not Redis." "Errors return problem+json." "Don't touch the legacy auth module." You type these, or the model re-reads the files that contain them, once per session. Sometimes once per tool.
4. Rework. The expensive one. The model confidently does the thing you decided against three weeks ago, you notice, you explain, it redoes it. Every token in that loop was wasted.

Bigger context windows don't fix any of this. I wrote about why in Context Rot: Bigger Windows Won't Save You. A larger bucket just lets you waste more per session.

Pull the two facts you need, not the forty you don't

The CLAUDE.md approach loads everything, always. A memory server flips that. When the agent needs context, it calls memory_query with what it is working on, and gets back the handful of items that match.

Two design details in ContextForge matter here:

• Results come back as previews. A query returns short summaries (about 150 characters each) with an ID. The agent only pulls the full text of an item, with memory_get, when it actually needs it. A query about "auth session storage" costs a few hundred tokens, not the whole knowledge base.
• Spaces narrow the search. Memory is organized into spaces inside a project (auth, billing, infra). Searching the auth space for an auth question returns auth answers, with no billing noise to skim past and pay for.

So the trade is: a small retrieval when it is needed, instead of a large preamble whether it is needed or not. On a project with any history, that is the biggest single saving, and it grows as the project grows. I wrote about the stale-file side of this in Why Your CLAUDE.md Goes Stale; the token side is the same story from the other end.

69 tools, but the model only sees 11

This is the one I actually measured, because the number surprised me when I first saw it.

ContextForge exposes 69 tools over MCP: memory, tasks, git sync, snapshots, team, and so on. Until version 0.11.0 the client sent all 69 schemas to the model on every session. I spawned the server and measured the raw tools/list payload:

Mode	Tools visible	Payload size	Approx. tokens
Full (pre 0.11.0)	69	45 KB	7,000 to 11,000
Lean (default now)	11	11 KB	2,000 to 2,800

The exact token count depends on the tokenizer and on how your client formats the schemas, which is why I give a range. The proportion is stable: roughly 75% fewer tokens spent on tool definitions, on every session, before any work happens.

How it works: the lean set is the ten tools people actually call all day (query, ingest, correct, forget, tasks, sessions, help) plus one gateway tool called cf_tools. If the agent needs one of the other 59, it asks the gateway in plain language ("sync my git commits", "restore a snapshot") and the gateway finds and runs the right tool. Nothing was removed. The schemas just stopped riding along in every prompt.

There is a second effect that isn't about tokens. Cursor caps MCP tools at 40, and several clients get noticeably worse at picking the right tool past roughly 50. Eleven tools keeps ContextForge well under both lines. If you want the old behavior, set CONTEXTFORGE_TOOLS=full and you get all 69 back.

The tokens you don't spend twice

This one is harder to put a number on, so I'll describe it instead of measuring it.

When Claude Code saves a decision on Monday and Cursor reads it on Tuesday, the Tuesday session skips the whole "let me explain the architecture" opening. That is a few hundred to a couple of thousand tokens per session, depending on how much you usually paste. It doesn't sound like much until you count how many sessions you open in a week.

The bigger saving is the rework bucket. A model that knows "sessions live in Postgres, decided 2026-04-11, here is why" does not propose Redis, does not get corrected, and does not redo the work. One avoided wrong turn can cost more than a whole day of memory queries. I don't have a clean way to measure avoided mistakes, so I'm not going to give you a percentage. I can tell you it's the reason I built this, more than the schema math above. The setup for two tools sharing one memory is in How to Share Context Between Claude Code and Cursor.

Where ContextForge does not save tokens

I would rather you hear this from me than find out after signing up.

• Every memory call costs tokens. A query and its results are a few hundred tokens. Saving a memory is a few hundred more. If the agent queries on every turn because your rules file tells it to, you can spend more than you save. Tell it to query at the start of a task and when it hits something unfamiliar, not constantly.
• It does not shrink the code the model has to read. Memory tells the agent what you decided, not what the file says today. It still has to open the file. Retrieval replaces the explanation, not the reading.
• Memory only pays off if it exists. An empty memory saves nothing. The first week is an investment: the agent saves decisions as you make them (because it has the tools and the instruction to use them), and the returns start when the second session, or the second tool, reads them.
• Stale memory costs tokens too. A six-week-old decision that no longer matches the code sends the agent down the wrong path just as surely as no memory at all. ContextForge runs freshness checks that flag items when the code they describe has changed, and you confirm, correct or forget them. Skip that and the savings turn into rework.

A rough picture of one week

Take a developer who runs three or four sessions a day across Claude Code and Cursor, on a project with a 14 KB rules file and a couple of MCP servers connected. Their fixed cost per session, before any work, is somewhere around 3,500 tokens of preamble plus 7,000 to 11,000 tokens of ContextForge tool schemas in the old full mode. Call it 12,000 tokens a session that produce no code.

Move the project facts into memory, keep the rules file to the short "how to behave" part, and run the lean tool set. The same session starts at roughly 2,500 tokens (a trimmed rules file plus the lean schemas), and adds a few hundred per query when the agent actually needs something. Most sessions land under 5,000 tokens of overhead. Over twenty sessions a week that is well over 100,000 tokens not spent on introductions, and that is before counting a single avoided wrong turn.

Your numbers will be different from mine. I would be surprised if the picture were.

Where to start

If you want to see the effect on your own project rather than trust my table: connect ContextForge to one tool, run memory_query on a real question, and look at the size of the response next to the size of the rules file you would have pasted instead. Then check what your client reports for tool definitions with CONTEXTFORGE_TOOLS=full versus the default. Those two comparisons take about ten minutes, and honestly they make the case better than this post does. The install is one line:

claude mcp add contextforge -e CONTEXTFORGE_API_KEY=<your-key> -- npx -y contextforge-mcp

The free tier covers one project and 500 queries a month, which is enough to find out whether the math works for you.