Mace Innovations
Back to Insights
Deep Dive10 min read
Shawn Fultz
Shawn Fultz
Co-Founder, Mace Innovations
Connect

The Architecture That Took Us Out of the Loop

105 billion tokens at 95% cache efficiency — that's the number we usually lead with. The more interesting one is 500 of 504: our production releases last month that shipped without an engineer in the loop. The second number is downstream of the first, and this is how.

The Problem With AI-Assisted Development

AI coding tools have transformed how software gets built. But here's what most teams discover: the cost curve bends the wrong way exactly when the tool starts being useful.

An agent needs context to be any good — your codebase, your conventions, the decisions you made last month and the reasons behind them. The more context it has, the better it works. But most setups re-send that context with every request, so the better you make the agent, the more each request costs. That tradeoff is what keeps teams running one careful session at a time instead of ten.

Break that tradeoff and everything downstream changes.

Context as Infrastructure, Not Payload

The shift is to stop treating context as something you send and start treating it as something that lives there — written once, read hundreds of times. Anthropic will cache repeated content automatically, but only if the shape of what you send lets it. Three things make that work in practice:

  • A stable prefix. A cache hit needs the front of the request to be byte-identical to last time. So the things that rarely change — standards, architecture, domain rules — go first and stay put; only the task at the end varies. Reorder that prefix and you've thrown the cache away without changing a word of meaning.
  • Inheritance instead of repetition. Our rules are layered — org, then company, then project — and every agent picks up all three automatically from where it's working. One rule written once is inherited by every session in that tree, rather than pasted into fifty prompts that then drift apart.
  • Big contexts, deliberately. Counter-intuitively, a large resident context is the cheap option. A million tokens read from cache costs a fraction of a tenth of that recomputed — so the agent gets the whole picture instead of a keyhole, and we pay less for it.

None of this is exotic. It's the discipline of deciding what's permanent, putting it where it can be reused, and not disturbing it — applied relentlessly for two and a half years.

THE DIFFERENCE
❌ Typical AI Dev Setup
Send full context → Get response
Send full context → Get response
Send full context → Get response
...pay full price every time
✓ Our Setup
Send context once → Cached
Reuse from cache → Reuse
Reuse from cache → Reuse
...95% served from cache

Real Numbers, at Real Scale

Over the past twelve months we've processed over 105 billion tokens through Claude building real production software — the equivalent of tens of millions of pages of code and documentation. And we're accelerating: last month alone was 33.65 billion tokens, across 4,146 commits and 26 active projects — with dozens of AI agents building in parallel.

That's not a typo. Billions with a B. Code generation, refactoring, debugging, documentation, code review — at a scale that would be economically impossible without the context architecture above. Every figure on this page is pulled live from the GitHub and Anthropic APIs; we publish the working in a monthly report.

Nine times the volume, same cache rate

The claim of this page is that the architecture is what keeps iteration cheap. The test of that claim is whether it holds as volume grows. Since March, monthly token volume went from 3.6 billion to 33.65 billion — about 9× — and in every month we measured it, the cache hit rate stayed between 94% and 97%. If it had been a small-scale trick, it would have decayed as we added projects and agents. It didn't.

Tokens processed
Billions per month
0
20
40
3.6
4.3
7.4
11
16.4
22.9
33.65
Mar
Apr
May
Jun
Jul
Aug
Sep
Cache hit rate
% of input tokens served from cache
0
50
100
n/a
96.9
96
94.3
94
95.8
95.1
Mar
Apr
May
Jun
Jul
Aug
Sep

The right-hand chart is flat on purpose — that flatness is the result. March is n/a: we only have a rough estimate for it, not a measured rate, and we don't chart a guess.

One more September figure worth sitting with: the agents read about 33.5 billion tokens and wrote 100.7 million — roughly 330 tokens of context for every token of output, and the first month output crossed 100 million. Of the 33.5 billion read, 31.9 billion were cache reads; only 17.6 million were uncached input. Reading is the expensive-looking part of agentic work, and it is exactly the part the architecture makes cheap.

94.9%
Served from cache (trailing 12 months)
5.1%
New context sent (September: 4.9%)

Translation: for every 100 tokens of context the agents read, about 5 had to be computed fresh. The other 95 came from cache, at a fraction of the price. That ratio is the whole ballgame — it's what makes the next concurrent agent nearly free.

The Engine Behind Fabric

Here's the part that matters at scale: cache efficiency isn't just cheaper—it's what makes running many agents at once economically possible. When 95% of every context is served from cache, the marginal cost of one more concurrent session stays low. That's the economics that let us run a matrix of Claude Code agents in parallel—dozens building, testing, and shipping at the same time.

So we productized it. That matrix is now Fabric: Neo runs the agent matrix for dev teams; Jerry uses the same foundation to build and ship production software for businesses that don't have a dev team. Same context architecture, now a product anyone can use.

What That Efficiency Actually Buys

For most of the last two years the answer was “more throughput” — more agents, more commits, more shipped per engineer. True, and not the interesting part.

The interesting part is what happens to the correction loop. When a build, a test run, a review pass and a retry are all nearly free, an agent can afford to be wrong on the first attempt and fix itself before anyone looks. Expensive iteration forces a human checkpoint — you review because each retry costs real money. Drive that cost to almost nothing and the agent absorbs the retries itself, and the checkpoint stops earning its place.

That's not a hypothesis. Here is what it looked like in September 2026:

500
releases shipped by the agent
4
shipped by a human

504 production releases across every Mace repository in one month. All but four went out with no engineer merging or deploying — measured from commit authorship, not estimated. Two years ago the same architecture produced faster typing. Now it produces software that ships itself.

Autonomy Is a Rails Problem, Not a Model Problem

An agent that ships unattended is only as good as what catches it when it's wrong. The architecture above makes autonomy affordable; it doesn't make it safe. Most of our engineering last month went into the boring half of that sentence:

  • A real preview before production. Every change lands on a live environment first. Nothing reaches production that nobody could have looked at.
  • Build and tests as a gate, not a report. A red build is the agent's problem to solve, and it doesn't get to hand the work over until it's green.
  • Automated review that loops back. Findings return to the agent and get fixed, rather than queuing for a person.
  • An append-only transcript. Every prompt, command, response and tool call recorded per user and per project, secrets redacted. When someone asks what the AI did and when, that's a query, not an investigation.
  • Escalation that's honest. When something genuinely needs a human, the agent says so plainly instead of failing quietly. A silent failure costs more than a loud one.

None of that is glamorous and all of it is load-bearing. That ratio is a measure of those rails holding, not of a model being clever.

What Compounds on Top

The same “write it once, reuse it everywhere” discipline that applies to context applies to everything else an agent needs. Two examples that carry real weight in production:

Integrations. Eleven vendor systems — origination, pricing, credit, title, HELOC, voice, messaging — sit behind one platform layer. The client keeps their own vendor relationships and hands over an API key once; the key is stored server-side and used on their behalf, so it never lands in a repository, an environment file, or a build log. The agent doesn't re-learn an API per project, and there is no credential in the workspace for it to mishandle.

Interface. The screens that are the same for every business — tables, dashboards, pipelines, forms — come from a shared component registry the agent installs from, then brands. Nobody's paying an agent to reinvent a data table. The build time goes into the part that's actually specific to the customer.

This is what Fabric is built on. Not developers who happen to use AI tools — an architecture where context, credentials and interface are all infrastructure, so the agent's whole budget goes to the problem in front of it.

What This Means If You Build On It

→
Proven at 105 billion tokens. Not a benchmark or a pilot — two and a half years of production software for paying clients.
→
It ships, not just writes. 500 of last month's 504 releases went to production without an engineer in the loop.
→
The integrations are already there. Eleven vendor systems behind one key — and your project never holds a vendor credential.
→
No vibe coding. Builds gate, tests gate, review loops back, and every session is on the record. Software that works, not experiments that might.

Build the Same Way

The architecture took two and a half years to get right. Using it takes a conversation. Whether you want Jerry to build and ship your software for you, or Neo's matrix of agents for your own team, we'll show you live against your stack.

Come with a problem. Leave with software.

Fabric is the platform behind every number on this page. Bring the thing your business actually needs and we'll build a piece of it live, against your own systems, while you watch.

Book a demoExplore Fabric →

Every statistic on this site is real. Development figures are pulled live from the GitHub API; token & cache numbers from the Anthropic Admin Usage API. Nothing fabricated.