We sent 67.9M tokens to Muse Spark 1.1. It cached all but 4 per request.

Meta's Muse Spark 1.1 showed up on OpenRouter on July 16. We handed it a Statement of Work the same day and let it build something end to end — not a benchmark prompt, a whole software project: spec, plan, pseudocode, code, review, tests, build, sprint review. One model in every agent role.

It burned through 67,923,486 input tokens getting there.

67,918,878 of them were served from cache.

That's a 99.9932% cache hit rate.

The part I can't explain

Here's where it gets strange. The uncached remainder isn't noise. It's 4,608 tokens across 1,152 requests — exactly 4 tokens per request.

Not "about 4." Our run telemetry breaks every request down by agent role and workflow step, which gives 115 separate buckets. I checked all of them:

Role / step	Input tokens	Cached	Delta	Requests	Delta ÷ req
orchestrator / determining_status	32,540	32,536	4	1	4.0
orchestrator / architecture	453,221	453,189	32	8	4.0
orchestrator / sprint_review_gate	3,023,667	3,023,579	88	22	4.0
health-check / code_implementation	34,984	34,972	12	3	4.0
develop / completion	915,234	915,158	76	19	4.0
sprint-plan / consolidation_review	1,966,978	1,966,862	116	29	4.0

All 115 buckets. Zero deviation. A one-request bucket and a 29-request bucket both land on exactly 4.0.

That is not what I'd expect a cache to look like from the outside. Each turn in an agent loop appends a different amount of new content — a tool result might be 40 tokens or 4,000. If the cache were matching a prefix and paying full price for the genuinely new suffix, the delta should wobble all over the place. It doesn't wobble at all.

So there are two readings, and from outside the API I genuinely can't distinguish them:

1. The cache is that granular. It matches to within 4 tokens of the end of every prompt, and the 4-token tail is some constant that always differs — a role marker, a turn boundary, something structural.
2. cached_tokens is derived, not measured. The provider reports prompt_tokens - 4 and the real physical behavior is something else entirely.

If someone from Meta or OpenRouter reads this and can say which, I'd love to know — genuinely, no gotcha. I'll update the post.

Here's what makes it more than trivia, though: the bill is computed from this number. Our cost reconciles to the cent against it — uncached tokens at the list input rate, the other 67.9M at the cache read rate, output on top. Whatever cached_tokens physically represents, it's what we're charged on. The economics are real even if the mechanism is opaque.

99.99% cached is not 99.99% cheaper

This is the part I'd want to flag for anyone budgeting an agent workload, because the intuition is a trap.

A cache read isn't free. On OpenRouter's posted rates, a Muse Spark cache read costs about 12% of a list input token. So a fully cached input bill doesn't go to zero — it goes to roughly an eighth.

And output never caches at all. Every token the model writes is billed at the full output rate, forever. In our run, output was under 1% of total tokens but a meaningful slice of the bill, because output pricing is several times the input rate.

Put together, caching absorbed about 85% of what this run would have cost with no caching at all. That's a huge number. It is also not 99.99%, and the gap between those two figures is entirely made of "reads cost something" and "output doesn't cache."

For reference, OpenRouter's own docs describe prompt caching as typically landing 60–80% cheaper than list price. 85% is at the top of that band, not off the chart.

Why an agent pipeline gets to be this cache-shaped

We didn't do anything clever to earn this. We did one boring thing consistently.

Every LLM request our orchestrator makes is split in two: a stable prefix and a volatile tail. The prefix — identity, directives, scoring philosophy, the anti-pattern catalog, the completion signal — is byte-identical on every single cycle. The tail — the fleet snapshot, per-agent activity, the inline rubric, prior feedback — is rebuilt every time.

The invariant is enforced by the function signature rather than by discipline: the prefix builder takes no per-cycle arguments at all. It can't accidentally interpolate a timestamp or an agent ID, because it isn't given any. Byte-identical by construction, not by code review.

That design predates this model. It was written because caching is the difference between an agent loop being viable and being a science project — a long-running loop re-sends its entire accumulated context on every turn, so the prefix gets paid for hundreds of times. Making it cacheable is the whole ballgame.

There's a compounding effect too: in a multi-turn loop, the volatile tail from turn N becomes part of the frozen history in turn N+1. Today's new content is tomorrow's cacheable prefix. Over 1,152 requests, almost everything ends up on the cached side of the line eventually.

A model that caches this aggressively turns that architectural decision into money. It's the closest thing to a free lunch I've seen in this stack.

What caching didn't do

It didn't make Muse Spark a better engineer, and I'd rather say that plainly than let a headline number carry an impression it hasn't earned.

The run scored 77.2/100 composite. It was genuinely strong where the model's own launch material claims strength — orchestration came in at 9.0/10, and it delegated 9 tasks with a 100% first-dispatch success rate and no re-delegations. Sprint review, also 9.0. Code review, 8.7.

It was rough elsewhere. Scout scored 4.5/10. Pseudocode, 5.8. Sprint planning, 6.9. Those are real weaknesses on a real scorecard, and no amount of cache efficiency touches them.

Cheap tokens make a mediocre plan cheaper. They don't make it a better plan.

The disclosure part

I work on Favur, so take the enthusiasm with the appropriate salt. Favur is an autonomous multi-agent software team — you hand it a Statement of Work and it plans, architects, codes, reviews, tests, and ships a repository. It's closed-source and currently invite-only; the repos it produces are open.

The scores above come from Favur Evals, our public benchmark: the same Statements of Work run through different models inside the same agentic pipeline, scored by a deterministic engine with no LLM judge. It's self-funded and not sponsored by any model vendor, including Meta. Which is worth saying out loud on a post that's this complimentary about a Meta model.

The full Muse Spark scorecard, including the parts that aren't flattering:
https://evals.favur.dev/runs/circles__meta-muse-spark-1.1-7.16.2026?utm_source=devto&utm_medium=social&utm_campaign=muse-cache

More about Favur itself: https://favur.dev/go/devto/muse-cache

And if you want the run-by-run version of this as we go, we post them at https://x.com/favurdev

If you've seen the 4-token thing on another model, or you know what it is, tell me. That's the part I actually want an answer to.