How to cut Claude Code costs by 2.5x (using Karpathy’s context engineering principles)

A full breakdown of how one open-source tool cuts your Claude Code session costs by 2.5x, without any changes to CLAUDE(.)md, prompts, or models (covered with a setup guide and why it is effective).

MCPMark V2 surfaced something counterintuitive.

Moving Claude from Sonnet 4.5 to Sonnet 4.6, the smarter model, pushed backend token usage through Supabase’s MCP server from 11.6M to 17.9M across the same 21 database tasks.

The model got smarter, but the backend token usage actually increased.

The reason is subtle, and it has nothing to do with the model.

Instead, it has to do with how the backend exposes info to the agent. When context is incomplete, a more capable model doesn’t just skip the gap.

Instead, it reasons harder about it, runs more discovery queries, and retries more often. So missing context gets more expensive as models improve, not less.

Let’s look at why a traditional backend makes the agent work harder, what backend context engineering should look like, and what the cost difference is on a real project.

Why Firebase makes the agent work harder

Firebase is a solid backend.

But it wasn’t built to be operated by a coding agent, and three of its assumptions turn into token costs when an agent takes over the workflow.

1) The tool surface and its docs inflate the context

The usual way to give a coding agent Firebase access is the official Firebase MCP server, built into firebase-tools. It ships more than 50 tools and activates the ones for your project automatically.

Connecting it loads that tool manifest into the agent’s context before any work starts, and the server also exposes documentation resources that get pulled into the session on its own.

The manifest grows with Firebase’s product surface, not with whatever you happen to be building, so even a small app that touches one or two services still carries definitions for Crashlytics, Remote Config, App Hosting, and the rest.

2) No single view of backend state

Firebase has no “show me the whole backend” call.

Instead, the state is spread across separate commands like

• firebase projects:list

• apps:list

• apps:sdkconfig

• firestore:databases:get

• firestore:indexes, and more.

Firestore makes this worse by being schemaless.

There’s no declared shape to read, so an agent infers a collection’s fields and types from sample documents rather than querying a schema.

It stitches info together from many partial calls, and that fragmented discovery pattern compounds, since each call returns only a slice, and some of it needs further commands to interpret.

3) Errors come back without a structured context

Firestore returns generic errors.

For instance, “PERMISSION_DENIED: Missing or insufficient permissions” is the same string whether the cause is a misconfigured security rule, a typo in a collection path, or a request that ran before the user was authenticated, and it never names which rule failed.

The same gap shows up in credential and configuration errors, where the message reports the symptom but not what the backend actually wanted.

An agent can’t localize the cause from the text, so it forms a hypothesis, tries a fix, re-runs, and gets the same string back. Each retry re-sends the growing conversation, which is where the token cost compounds.

These three bottlenecks, i.e., a heavy tool surface, fragmented state discovery, and opaque error retries, compound fast.

A model that reasons more thoroughly makes each exploration step more expensive, widening the gap as models improve.

What “backend context engineering” should look like

The fix isn’t switching to a worse model.

It’s giving the agent a structured backend context so it doesn’t have to explore and guess.

This is what Karpathy means by context engineering: “the delicate art and science of filling the context window with just the right information for the next step.”

He explicitly includes tools and state as part of that context. The natural instinct is to apply the idea to prompts and RAG retrieval.

But the backend is part of the context window too, and right now, it’s the most overlooked part in agentic coding.

To see what this looks like in practice, InsForge (open source, Apache 2.0) implements exactly this approach.

GitHub repo → https://github.com/InsForge/InsForge

The key architectural difference is how it delivers context to Claude Code.

Three layers work together, and each layer solves a different problem to reduce tokens:

• Skills for static knowledge.

• CLI for direct backend operations.

• MCP for live state inspection

1) Skills: static knowledge with zero round-trips

InsForge’s primary approach for knowledge is Skills. They load directly into the agent’s context at session start and use progressive disclosure.

So only metadata loads first (~70 to 150 tokens per skill) and full content loads only when a task matches.

Four skills cover the full stack, each scoped to a specific domain:

• insforge for frontend code that talks to the backend.

• insforge-cli for backend infrastructure management

• insforge-debug for structured error diagnosis across common failures like auth errors, slow queries, edge function failures, RLS denials, deployment issues, and performance degradation)

• insforge-integrations for third-party auth providers (Clerk, Auth0, WorkOS, Kinde, Stytch).

Install all four with one command:

2) CLI for direct execution

This provides the execution layer.

Every command supports –json for structured output, -y to skip confirmation prompts, and returns semantic exit codes so agents can detect auth failures, missing projects, or permission errors programmatically.

These are some example operations the agent actually runs:

The agent parses the JSON and handles errors based on exit codes.

3) MCP tools for live backend state

MCP stays useful for live state inspection through a get_backend_metadata tool that returns the full topology in roughly 500 tokens, with a hints field for agent-specific guidance.

The design choice is to use MCP for state that changes, not for documentation that doesn’t.

The model gateway sits inside all of this.

It’s an OpenAI-compatible endpoint that routes across providers (OpenAI, Anthropic, Gemini, Grok), so text-embedding-3-small and gpt-4o are reachable through the same SDK with no separate key and no external wiring.

Firebase vs InsForge: Build DocuRAG with Claude Code

To make this concrete, I built the same DocuRAG app on both backends with Claude Code (Opus 4.8), holding the embedding model and the generation model constant so the backend was the only variable.

A user signs in with Google, uploads a PDF, the text is chunked and embedded (text-embedding-3-small, 1536-d), the vectors are stored and searched, and GPT-4o answers questions over the retrieved chunks, with per-user isolation.

This touches nearly every backend primitive at once: user auth, file storage, a documents table, vector embeddings, embedding generation, chat completion, a retrieval edge function, and RLS to isolate each user’s documents.

Here’s the setup for each backend:

1) Firebase

Firebase needs real pre-configuration before Claude Code can start, most of it by hand in the console:

• Create the project at console(.)firebase(.)google(.)com and register a web app for the client SDK config.

• Enable Firestore (Standard edition, nam5 region) and Cloud Storage, and add the Google sign-in provider under Authentication.

Then install the agent skills, add the MCP server, and authenticate the CLI:

Adding the MCP server loads its full tool manifest into the session, which is the first mechanism in action.

An OpenAI API key also has to be supplied separately, since Firebase AI Logic serves only Gemini and Imagen, not gpt-4o or text-embedding-3-small.

2) Insforge

• Create an Insforge account and create a new project (you can also self-host and run Insforge fully locally using Docker Compose).

• Install the four Agent Skills, then log in and link the CLI to the project:

This installs insforge (SDK patterns), insforge-cli (infrastructure commands), insforge-debug (failure diagnostics), and insforge-integrations (third-party auth providers), at roughly 714 tokens of metadata at session start.

The skills are narrowly scoped, so only the relevant one activates.

There’s no MCP server to add and no console clicking. Auth, storage, the vector store, and the model gateway are all provisioned by the agent through the CLI from a single prompt, with no separate OpenAI key.

The prompt was nearly identical across both runs, with one difference.

• Firebase:

• InsForge:

The one functional difference is the model wiring.

• Firebase routes generation and embeddings through “LLMs/embedding models via the OpenAI API,” two systems to wire, because Firebase has no gateway that serves GPT-4o.

• InsForge says “also for the model gateway,” one system.

I ran both sessions side by side and recorded the full build. Here’s the side-by-side video showing what happened from prompt to working app.

It also showcases the final output from both sessions, built on two different backends.

Before diving into the session-specific details, here’s what the numbers looked like after the final build:

• Firebase: 15.7M tokens, $12.95, 4 user messages

• InsForge: 6.3M tokens, $4.87, 1 user message, 0 error reports.

Now let’s look at what actually happened in each session.

To analyze both sessions objectively, I exported the full Claude Code session history from both runs (as JSONL files) and fed them to a separate Claude instance. The analysis below, including tool call counts, error sequences, and token breakdowns, comes from parsing those session logs.

Firebase (consumed 15.7M tokens with $12.95 cost)

The initial code build went smoothly.

• The agent loaded the firebase-firestore and firebase-auth-basics skills

• Then discovered the backend state through the Firebase MCP server (firebase_get_environment, firebase_list_projects) and the CLI.

• It found an existing docurag project that was set up in the dashboard.

It scaffolded the full Next.js app, wrote the Firestore security rules and a 1536-d vector index, wrote the API routes and the light-mode UI, and the production build passed after a few self-corrections, including a space-stripping bug it caught in its own chunking code.

Problem 1) Authentication had no headless path

The first thing I hit after the build was a missing config file.

The session left an .env.local.example template, but not the real .env.local, so the app had no Firebase config to boot with. The agent couldn’t fill it in on its own.

Those values come from a registered web app, and registering one and reading its config back only works from a logged-in CLI.

Problem 2) Retrieval returned the wrong authors

My first real query turned up a RAG bug. I asked for the authors of the paper I’d uploaded, and the app came back with the wrong names cited inside the paper, not its actual authors.

The obvious suspect was chunking, but the data said otherwise.

For “who are the authors?”, the five nearest chunks were all from the References and Acknowledgments, which are packed with cited names, because a list of authors embeds closer to a bibliography than to the word “authors.”

Chunk 0 never made the top five, so GPT-4o read the reference chunks and reported those names instead.

It fixed it by raising top-k and always folding the opening chunks back in, in document order.

Problem 3) Chat history didn’t survive a refresh

Then I noticed my previous questions disappeared after a page refresh.

The chat history was living in React state only, so a reload wiped it.

The agent moved each turn into Firestore (under users/{uid}/documents/{docId}/messages), added an endpoint to read it back, and loaded it when a document opens.

It checked the round-trip by writing a few turns, reading them back in order, and cleaning up.

Problem 4) Repeated file edits

One weird pattern stayed consistent during the whole session.

Firebase gave up its state and its failures a piece at a time, through CLI probes, terse error messages, and even its own SDK source, so the agent kept learning things only after it had already written the code.

The credential is the clearest case that highlights this in my run.

The agent committed a setup that looked right, and only a test run and a read of firebase-admin internals showed it was wrong.

These types of patterns significantly increased the token usage.

Every time new information landed after the code was written, the agent reopened the file and re-sent the growing conversation to the model.

Set the generic RAG fixes aside, and most of the re-editing was the agent reworking code to match what the backend revealed only after the fact.

In total, 25 files were edited after they had been written already during the session:

Not all of Firebase’s were the backend’s doing.

The generic RAG tuning and a couple of build fixes are in the list too. But the heaviest cluster is structural with the API routes alone were reopened ten times, as the credential wiring, the persistence retrofit, and each round of fixes landed back in the same handlers.

These are the final session stats:

• 141 tool calls (51 bash commands, 46 writes, 25 edits)

• 2 MCP tool calls

• 15.7M tokens

• $12.95

InsForge (consumed 6.3M tokens with $4.87 cost)

The InsForge session reached the same working app from the single build prompt with no error reports.

Its first action was npx @ insforge/cli metadata –json, which returned the configured auth providers, existing tables, storage buckets, and available models in one structured response.

The agent had the full picture before it wrote any code.

Schema went through migrations, creating documents, document_chunks, and chat_messages tables, all under row-level security so each user sees only their own data.

pgvector wasn’t available on the cloud tier in this run, so the agent stored embeddings as a double precision[] column and ran exact cosine similarity in a SQL function (match_document_chunks), with the SDK passing and returning plain number arrays.

A private documents bucket with path-scoped RLS handled file storage.

Auth was Google OAuth through the SSR flow, with redirect URLs allowlisted by the CLI.

Regarding the model gateway, the metadata response already listed text-embedding-3-small and gpt-4o, so the agent called both through the InsForge SDK with no separate key and no cross-service integration.

The end-to-end RAG test passed on the first run.

Two of the things that broke on Firebase never came up here. The chat_messages table was provisioned as part of the standard schema, so chat history persisted across refreshes by default.

And because the gateway is part of the backend, the embedding and completion calls needed no separate credentials or integration.

Moreover, these are the only file edits in the entire InsForge run.

Both of these files are config (insforge.toml, package.json), and none touch application code.

Every route, library, and component was written once and never reopened.

That explains why the run stayed cheap.

The agent’s first move was a metadata –json call that returned the whole backend state at once, so it wrote against a complete picture instead of discovering it in pieces.

Once it committed a file, the assumptions behind it held, and nothing arrived later to invalidate them. No late information meant no reopen, and no reopen meant the conversation was never re-sent to rework code already written.

Final session stats:

• 1 user message (the build prompt, no follow-ups)

• 102 tool calls (28 bash commands, 29 writes, 3 edits)

• 0 MCP tool calls

• 6.3M tokens

• $4.87

Session summary comparison

I asked Claude to generate a side-by-side summary, and here’s what it produced:

The two runs made a similar number of tool calls (141 against 102) and the same number of CLI calls (13 each), yet Firebase cost 2.5x the tokens to reach the same app.

The difference is in the rows that count rework and friction, like the human interventions, the re-edits, and the MCP manifest one backend loaded and the other didn’t.

This comparison highlights a problem that goes beyond Firebase.

Nearly every backend was built for human developers who read dashboards, interpret vague errors, and track state across services in their heads.

When an agent takes over that workflow, those assumptions become token costs.

The agent can’t open a dashboard, can’t tell where an error came from when the logs don’t say, and pays for every wrong guess because each retry re-sends the whole conversation.

The bulk of the Firebase overhead actually came from the auth and credential discovery loop, the 25 edits, and the 51 bash commands spent reconstructing what the backend wouldn’t expose.

The edit count shows the same thing at the file level.

On the flip side, InsForge wrote its application code once and never went back, with both of its edits landing on config files rather than app logic.

Firebase re-edited already-written code 25 times, the API routes alone ten times, as each fix sent the agent back into files it had already written.

InsForge started from the opposite assumption.

State came back as structured metadata, the CLI gave programmatic control with clear success and failure signals, skills encoded the correct patterns so the agent wasn’t discovering them by trial and error, and the model gateway kept embeddings and completion inside the same backend.

That’s what removed the auth bridge, the cross-service wiring, and the persistence retrofit from the InsForge run.

InsForge is fully open source under Apache 2.0 and self-hostable via Docker.

The code, the CLI, and the skills are all on its GitHub repo.

You can find it here: https://github.com/InsForge/InsForge

(don’t forget to star it ⭐️)

👉 Over to you: which part of your agent’s backend workflow burns the most tokens, auth setup, state discovery, or error retries?

Thanks for reading!

That’s a wrap!

If you enjoyed this article:

Find me → @_avichawla

Every day, I share tutorials and insights on DS, ML, LLMs, and RAGs.