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 actual workload through it, taken from the logs.

What Festival is

Festival is a free cli toolsuite (npm install -g @obedience-corp/festival, or brew install --cask Obedience-Corp/tap/festival) that you and Claude Code, Codex, openclaw or any agent that can run shell commands can use. There are 2 main concepts to learn in order to use it.

The first concept is the campaign: a git-tracked context workspace for a specific domain, functionally it's a monorepo with your projects added as git submodules(camp project add) or symlinks (camp project link), where the code, the context, the research, and the history live in one place. It persists between sessions and you can easily switch between campaign workspaces located on any of your drives or anywhere in your file system with the csw (camp switch) command. An agent that opens a campaign can easily and quickly find all relevant context instead of a blank prompt and a paste of yesterday’s notes. Nothing has to be reconstructed because it lives on disk, status is tracked based on implied intent, completed work is archived in the dungeon by end status (completed, someday, archive).

The second is the festival: markdown and yaml based agent orchestration. You start with a goal, and the agent breaks it into phases, sequences, and tasks, with multiple levels of gates, all written to files in the repo. The agent works the plan one task at a time and commits as it goes, so progress shows up as real changes in git with ids linking the project actions to the plans that the actions were based on. Release v0.2.13 of festival added hooks, where you can configure a hook to be triggered once the plan advances to a particular point. I use this to trigger a background kimi-k2.6 judge agents to take the place of myself as a human reviewer.

Festival plans are useful for situations where you have a massive amount of work that needs to be done, when you need high level tracing of agent actions to plans, or when you need something done a specific way and you don't want to babysit the agents to get them to follow your specific strategy.

For high risk plans, reviewing and iterating on the festival plan before execution is important and it can speed up development process by letting you think through and see what the agents would do and what the outcome will look like through the plan structure before the agents touch your code. Once the plan is correct you ask the agents to ensure it's properly linked to it's working directories (projects or project worktrees) and tell a fresh session to execute the fest next loop from inside the working directory. Keeping the plans away from the agents working directory prevents agents from altering the plans during execution. This method has reliably gotten me the final outcome I was looking for on first run more than 99% of the time, but it a lot of work to review the plans.

Earlier this year I added a dynamic planning feature to the system which is currently the default festival. Just ask an agent to create a festival and point them to specs or just describe what it's for, they will create it then you tell the agent to run the fest next loop inside the festival and this will walk the agent through the planning process. There are a few human review points in this, and you can bypass them if you want by telling the agents to use their own judgement and not bother you until the festival is fully planned out, this is what I do most of the time because it gets me 90% of the plan I want in 1/6 the human effort and iterating on the plan after it's scaffolded/initially planned out is less effort. v0.2.13 also added hooks, so now I have a judge hook I use that can do the human approval inspection for me which can help correct more mistakes in the plan before I need to look at them.

What it looks like to use

After setting up campaign workspaces and adding projects to them, you start off by running csw (camp switch) to jump to your workspace from anywhere on your machine. You can use camp list to see and navigate to any of your campaigns. Once in a campaign run cwi (camp workitem) to view all your workitems, festivals, custom workflows, etc... This helps you quickly recall what you were focused on last time you were working in the campaign.

As you customize your campaigns, add custom workflows and the context builds up as you use it, each workspace ends up effectively becoming a department of agents. You can organize them into orgs and have the agents working inside them transfer files between campaigns as needed.

The structure helps every agent running inside the campaign behave consistently. If your plan runs out of usage you can pick up right where you left off when your limit resets, or even pick up with another provider immediately and keep going. Working this way will expand the scope of what you're able to do and let you tackle large scale ambiguous problems, often in parallel to the work you know you need to do.

Does it hold up? Nine months of real use

Festival has been my main way of interacting with my computer since June 2025. I recently found that I had enough data to prove the anecdotal experience I've had of extreme cost effective token usage. The numbers here cover my whole working life over the past 9 months: fifteen campaign workspaces, from the Obedience Corp product to a AAA FPS game backend, OTC trade desk platform, multi-agent chat app, and personal tooling, holding 138 repositories. They come from local agent logs and git history between September 30, 2025 and June 25, 2026.

What nine months of organized work looks like

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

That is 14,965 contributions in the trailing year, 706 of them pull requests, spread across a lot of different projects. Most of it is in private repositories, so the public count alone, about 5,000, badly understates it.

That is also the problem in one image. It is a huge amount of work across a huge number of projects, and if I tried to explain why each one exists and how it connects to the rest, it would take forever and lose you a third of the way through. Removing exactly that cost is the point of Festival. 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 node is real work, and every node hangs off the campaign workspace it lives in. The root fans out into fifteen separate workspaces, each into its repositories, and the slider walks the whole thing forward month by month. By June it covers 138 repositories and 256 festivals.

The point is not the node count. It is that none of it had to be explained to make sense. Each branch is a structured plan with its decisions and tasks recorded in files, every contribution sitting under the workspace and the intent that produced it. That is what makes running this much, across this many fronts, survivable for one person.

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 not the total, it is this: 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 had 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 a long project 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 plan, the same recorded decisions, waiting where the last session left them. 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 forcing one to be reconstructed.

Update

Since writing this post I've used 12B additional tokens, cache reuse is up to 97% as of 7/28/2026

Try it

If the problem at the top of this post is familiar, the fastest way to get it is to install festival, create a campaign and link your project/projects to it.

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

Newspaper

Building Persistent Context for Coding Agents