This is the workspace I run every other project out of. By spring it had a problem I could measure: 131 skills, most of them never called, each dragging a 50 to 100 line preamble into context before I typed a single prompt.
That is token death by a thousand cuts. Underneath the skills sat 19.46 GB of duplicate and orphaned project state, the kind of mess where you cannot tell which copy of a thing actually runs. My vault graph, the thing that is supposed to carry facts from one session into the next, had disconnected from the sessions themselves, so the AI just was not remembering what I had told it the day before. And the two AI lanes I lean on, Claude and Codex, worked completely blind to each other. Neither could see what the other had just shipped, so they stepped on each other and repeated work. The whole thing had drifted into the trap where code works for a week and then quietly breaks.
The part that embarrasses me a little is how I got here. I was watching YouTube, Instagram, and Twitter, and any time a skill or a repo sounded interesting I downloaded it. The AI had no real understanding of how to call half of what I had installed, and I was expected to remember every single slash command by heart, which was impossible at the rate I was collecting them. Hundreds of skills, most grabbed on a whim, most never touched again.
So I stopped patching and rebuilt it as a meta-project: a locked, deliberate effort to trade vague autonomy and scale for ruthless right-sizing, cost discipline, and continuity. The rest of this post is what came out the other side.
Delegation, not memorization.
My whole philosophy behind using AI is delegation. I do not want to be the person who has to type out the exact skill every time. I would rather hand over an idea, structured or not, and have the AI process it, delegate to sub agents, and pull whichever skills it actually needs from its own understanding of what I am asking for. That is not something you get out of the box. It takes real coordination to make happen without me stepping in every time.
Mechanic and wrench, the whole shop.
Instead of a hundred and thirty disjointed skills that all have to be called by name, I built what I call the mechanic and wrench delegation process.
The Audi in the shop.
Think of it like running a mechanic shop that works on every kind of car. An Audi comes in one day and it needs one very specific wrench to get a wheel off. Do you, the shop owner, want to be the one who goes and finds that wrench and hands it to the mechanic? Or do you want the mechanic to already know which wrench the job calls for?
That is how I use AI now. If I have a front-end project, I do not want to run a slash command for some GitHub repo I downloaded that picks fonts for me. I want the AI to know it needs to go talk to a mechanic, a skill that carries a whole set of underlying tools I call wrenches, and those wrenches can point to more skills of their own. It becomes a tree of decisions, but I am only ever calling one thing by hand: the mechanic. The mechanic calls the rest.
This is what took the token bill down. Instead of roughly a hundred and thirty skills, I now run about twenty deliberate surfaces, and the AI only branches as deep into a mechanic's wrenches as the job actually needs. Compartmentalizing it this way, delegating instead of memorizing, has meant far better results with far less of my own attention spent on each project.
The owner of the whole chain, and the narrow specialist.
Apex: I delegate to the delegator.
The shop-owner example works if you want to be the one poking at mechanics and wrenches. I do not. I want to own the whole chain, which means trusting one thing to coordinate the entire shop for me on every part I am not willing to run myself. That is the Apex. It takes one prompt and runs an entire project start to finish, coordinating whichever mechanics and wrenches the job needs. I delegate to the Apex the same way I delegate to a mechanic. I just delegate more.
Keepers: one narrow lane, worked well.
A keeper is the other end of the same idea: a small, standalone agent for one specific implementation. You call an Apex for a whole project. You call a keeper when there is a bug to fix. A keeper does not go recruit a chain of mechanics and wrenches. It stays in its own lane and does that one thing well.
Agent-agnostic, on purpose.
A real AI engineer does not marry one model. They use Claude, Codex, Gemini, whichever one actually plays to its strength for the task in front of them. That is what the routing table is for: pointers that tell the AI which model to hand a task to instead of defaulting to whatever it is already running as.
Claude does the big-picture thinking. Fable takes the thirty-thousand-foot view: it builds the architecture, writes the design plans, and drafts the prompts the rest of the chain will run on. Opus is the small-project coordinator underneath it. Sonnet is the actual coding workhorse, because it is far less token-hungry and it is plenty good at the kind of straightforward coding work Opus hands it.
Codex gets the same respect. It is an extremely capable, rule-based engineer, more specific and arguably safer with the code it writes than Claude is, so day-to-day coding often goes there instead. And for image generation, Gemini is the pick, because it arguably makes better images than either of the other two.
There is a cost reason for all of this too. If you are on the hundred-dollar Max plan, having Claude do a hundred percent of the work burns through your usage limits fast. Splitting the work across lanes buys headroom. And it buys resilience: the routing table carries fallbacks, so if Fable or Opus is down, the work moves automatically to the next best lane instead of stalling out waiting on one model.
Claude and Codex finally see each other work.
The two lanes used to work completely blind. Neither could see what the other had just shipped, so I would get duplicate work and files stepping on each other.
Every Claude action, an edit, a write, a shell command, gets appended as one line to a shared log file in the project, through a hook that fires automatically. It rotates itself once it fills up, so it never grows unbounded. Codex writes its own record when a session finishes, whether that is an interactive session or a longer goal run, and flags it unrelayed until I actually hear about the outcome. At the start of every one of my turns, a hook surfaces anything new Codex just did, so I reconcile before I touch a file Codex was just in.
There is a formal lane for direct requests too. Codex can drop a request file naming a skill it needs me to run, I do the work, and I write back a response with exactly which files I touched. Only then does Codex pick back up in that area. Any tool I name in a handoff gets checked for parity on the Codex side, so the two lanes stay genuinely one-to-one instead of one of them silently missing a capability. Hard locks stop both lanes from editing the same file at once. And none of it polls in the background: every hop only happens because a real turn happened.
Nothing learned in a session gets left on the floor.
Ending a session runs a handoff ritual. Whatever was worth keeping gets pulled out into the vault: status, decisions, errors and how I fixed them, open loops, one fact to one home. That ritual also writes a handoff file and a next-session prompt I can paste straight in.
Starting a new session, a resume skill reads that pasted handoff, figures out which project it belongs to, loads that project's full vault context, and reports back ready. I do not have to reconstruct where I left off, because the session already knows.
Session start also auto-injects a small, stable boot block plus whatever volatile state the vault is holding, so every session wakes up already knowing the active project and where it stands. That is the actual fix for the AI not remembering things between sessions: the vault graph is wired back into real sessions instead of drifting away from them.
The workspace does not need me to remember it anymore. It remembers itself, and it tells the next session what happened.
