96% Cache Reads: Nine Months of Running AI Agents Affordably

If you have used a coding agent on anything bigger than a quick script, you have felt this. The agent does real work. It writes the code, runs the tests, hits the API. Then it stops, hands you the result, and waits for you to re-explain the goal, the priorities, and the constraint that changed two days ago. Do that across a dozen projects and you are no longer the engineer. You are the memory and the coordinator for the whole operation, and that job gets harder every time the agents get faster.

The capability is not the constraint anymore. The agents can do the work. What breaks down is everything around the work: holding the right context, keeping the agent pointed at the goal across many steps, and trusting what comes back enough to build on it. Supply all of that by hand, one prompt at a time, and you become the part that does not scale.

Festival is what I built so the work stops depending on me to hold it together. It is not a wrapper around a model or a helper bolted onto a single repo, but a filesystem-first workspace and planning system: agents get persistent context, structured direction, and a verifiable record, so long-running work across many projects stays coherent on its own. This post is a field report on nine months of running my workload through it, taken from the logs.

What Festival is

Festival is a CLI toolsuite and workflow for humans and agents to collaborate and orchestrate work over the full lifecycle of the work itself. It contains several useful workflows and is expandable with custom workflows to track all of your work in one place. The most capable workflows is “festivals”, a complex long running goal creation framework where agents will plan out and execute hierarchical goals of any size or complexity based on template files you can customize as needed to ensure agents are following specific planning process, specific gates and following you or your teams specific process for doing and submitting work.

The first concept to learn is the campaign: a git-tracked workspace, where your plans, research, projects and context history live in one place. Projects can be added to the campaign as git submodules or linked to the campaign via symlinks. It persists between sessions and contains tools for keeping the campaign context clean with minimal context required to clean and organize the workspace.

The second important concept are festivals: a hierarchical plan for a high level goal with a standardized structure. You give an outcome, and the agent breaks it into phases, then sequences, then individual tasks, each with its own verification steps, all written to files in the campaign. The agent works the plan one task at a time and marks the task completed. This is a more dynamic and more scalable version of planning systems found in other agent harnesses. The easiest way to think about these are like jira epics, but they’re tracked on a kanban board because they’re executed at the speed of a jira task.

That is what separates it from generic agent orchestration. Context lives on disk and stays there, direction is a structure the agent can pick back up, and verification is the high level outcome you wanted to achieve. When I’m using festival, I’m not focusing on the actions of the work getting done, I’m focusing on the strategy to build the feedback pipelines required to ensure the work that is getting done is achieving the outcome. Like a true work loop. None of it depends on one long session staying alive, and none of it depends on the user to carry state from one step to the next. The design comes out of years of working out how hard problems actually get carried to completion, turned into tooling instead of advice.

What it looks like to use

The loop is small. You set up a campaign, customize it as needed while you work and add your projects. After that you work by describing what you want and handing it to the agent. The agent plans festivals around your idea: it generates the structure, breaks the goal into phases, sequences, and tasks, and writes the plan files itself. You do not fill those in. You read them, and when the plan looks right you have the agent run the fest next loop, where it pulls the next task, does the work, marks it done, and continues working through the fest next loop until the festival is complete. When you come back, the state is on disk: what is done, what was decided, what is next. You review a structured trail instead of reconstructing where the agent left off from a wall of scrollback.

Since agents are able to handle the majority of the work associated with planning, and 100\% of the execution of the plans, I’m able to scale up the work I can direct while the agent is working. I typically have 5-8 festivals being planned or executed at the same time and dozens of smaller workflows for smaller adjustments that don’t require a long running goal to achieve, like individual features, market research and parallel product development.

The rest of this post is about whether that design holds up when you lean on it hard over time to launch multiple complex system products and dozens of dev tools in parallel.

Does it hold up? Nine months of real use

I do not just build Festival. I run everything through it. The numbers here cover ~80\% of my working life over the period: fifteen campaign workspaces, from the Obedience Corp product to client projects, hackathon projects, and personal tooling, holding 138 repositories and hundreds of festivals. The data comes from local Claude Code, Codex, and Gemini usage logs, plus git history, between September 30, 2025 and June 25, 2026 on my primary dev machine. The other ~20\% of my usage for this time period was also performed in the festival system on a client device that I no longer have access to.

What nine months of organized work looks like

Start with the raw output. Here is my GitHub activity for the year:

14,965 contributions in the trailing year, across hundreds of repos.

That is also the problem in one image. It is a huge amount of work across a huge number of projects and without festival I couldn’t manage this volume of real work product, explain it or answer questions about it. It would be noise to not only everyone that trys to explain it from the outside looking in, but even to myself. But with festival, I can manage it and I can find an answer to a tiny detail in one project if needed extremely quickly, often faster than an agent can hallucinate a response. It keeps all of this organized so I never have to hold it in my head, and so the work can be shown instead of narrated.

Here is the same body of work as a graph, with every piece linked to the campaign workspace it belongs to:

This is a timeline of that same work, with every campaign workspace linked to its projects, scrubbed across the nine months. Every project node is real work that benefited myself or someone else, and every node hangs off the campaign workspace it lives in and every plan within the workspace links to the project it was associated with. Each plan within the workspace is linked to the project and the commits where the plan was executed, so finding the real “why” an agent did something 3 months ago, instead of relying on a prediction of what a good answer might be I can quickly and easily get up to speed on the real context of the agent action 3 months ago, and provide a real answer to the question instead of a possibly hallucinated answer.

I can also compress the information of hundreds of projects, thousands of features and billions of tokens into a story of what happened that requires a tiny fraction of the context to communicate to both humans and agents.

The overhead stayed flat as the work grew

This is where the design pays off. Over the nine months the agents processed 26.5 billion tokens across 153 active days of work.

The number that matters is that: 95.8% of those tokens were cache reads priced ~0.1x standard input pricing. When an agent takes a step, it re-reads the context it needs. A cache read is context the system has already loaded and held onto, rather than rebuilding it from scratch. A high cache-read share means the agents spent their budget reusing stable, already-established context instead of regenerating it every step.

Why care? Because the usual failure mode on large, long running projects is the reverse. As a codebase grows, agents burn more and more of every request just re-deriving what the project even is, and the cost of each change creeps upward. Here that share stayed high for nine straight months and climbed as the work grew, finishing above 97%.

That reuse is a direct result of the architecture. The context the agents reuse is the campaign sitting on disk: the same project files, the same plans, the same recorded decisions, waiting where the last session left them, easily discoverable by both me as the user and agents. Caching rewards an exact, stable prefix, so reuse only stays high when the context an agent re-sends does not churn between steps. Because the campaign is canonical and grows by appending rather than being rewritten, the agent replays a near-identical prefix step after step instead of a reshuffled one, which is what the cache pays back. The usual killers of reuse, re-pasting context, reordering it, regenerating a status blob every day, never happen here. There is a fixed thing to reuse instead of a context to rebuild every time, so new work plugs into a stable base rather than needing to reconstruct state.

Try it, and star it

If you’d like to quickly start getting similar benefits and scale up your workflow install festival, setup a campaign, link or add your projects and start launching agent sessions at the root of your campaign.

Star the repo so other people building with agents can find it. One click on the Star button helps more than you would think: github.com/Obedience-Corp/festival

Install it:

# npm
npm install -g @obedience-corp/festival

# or, on macOS
brew install --cask Obedience-Corp/tap/festival

Create a workspace and your first plan:

camp create my-campaign
camp switch my-campaign

Then launch an agent from the campaign root and ask the agent to create a festival for a large goal.

After the festival is created tell the agent to begin running the fest next loop from inside the festival.

Watch it with the fest watch command and chat with the agent until the festival is fully planned and you are satisfied with the plan.

Then tell the agent to promote it to active and begin the fest next loop to execute the festival

Links

• Festival: fest.build
• Quickstart and docs: docs.fest.build/getting-started/quickstart
• Source, star it: github.com/Obedience-Corp/festival
• Obedience Corp: obediencecorp.com