How a Quick Sidequest Turned into the Most Powerful Claude Code Plugin I Have Ever Used
I’m halfway through a change in Claude Code and a thought shows up about a completely different problem. The date parser in another module is wrong. There’s a flaky test I keep meaning to look at. That config file should really be split. It happens to me maybe twenty times a day, and for a long time I had three ways to deal with it, all bad. I could say it out loud and derail the session into that instead. I could hold it in my head and lose it by the next tool call. Or I could tell Claude to write it down somewhere and work it later, which is the option that sounds sensible and doesn’t hold: as of mid-2026 “it loses TODOs” is one of the most-repeated complaints on Anthropic’s own tracker, and my experience matches.
Distracted brain, five projects open at once, and a coding agent that forgets the side thought as fast as I do. So I built the least ambitious tool imaginable to fix it. A list.
That list is now a plugin called Sidequest, it runs every piece of agent work I do across a dozen projects, and it’s the thing I’d keep if I had to give up everything else in my setup. This is the story of how a scratchpad grew into that, one boring step at a time.
Quick grounding for anyone new to this: Claude Code is Anthropic’s coding agent, it runs in a terminal, and you extend it with plugins you install from a marketplace (a git repo with a catalog file). Mine is called the Eigenwise Toolshed, everything in it is free and MIT-licensed, and Sidequest is the plugin at the center of it.
It Started as a List I Was Allowed to Ignore
The earliest request in the plugin’s own history, from the fourth of July, was me asking Claude to “turn all grievances that are not yet done into sidequests and remove those that are done.” The name is literal. A sidequest was a thing I’d noticed, wanted handled eventually, and did not want to think about right now.
The one rule from day one was that filing a sidequest is not a request to work it. Claude writes it down on a small local board and keeps going with what we were doing. That sounds like nothing. It turned out to be the whole design, because it meant the main session never got dragged off course, and everything that came later was built to protect that same property.
Version one was a local board, a plugin hook that made Claude file instead of derail, and a page where I could see the list. Nothing else.
Then the List Needed Someone to Work It
Once you have forty open tickets, the next question asks itself. Claude Code already had the pieces to answer it. It can spin up subagents, which are separate Claude sessions with their own fresh context, and Anthropic’s own docs describe them as the thing to use when a side task “would flood your main conversation.” It can give each subagent a different model. And it can put a subagent in its own git worktree, a separate working copy of the repo, so parallel workers can’t overwrite each other, and Claude Code enforces that boundary rather than trusting the model to behave.
So the board started handing tickets out. The way it works today: the main session picks a ticket and dispatches it. The worker gets a short note and a one-time key, uses the key to fetch its full briefing (the ticket, what it may touch, the comment thread, how to verify) into its own fresh context, does the work in its own worktree, and hands back a commit and a report. Review is a ticket too, and it’s pinned to that exact commit, so a reviewer can’t accidentally sign off on something else. Nothing lands on the main branch until I bring it in.
The main session holds the plan; the workers hold the code. That line is in the plugin’s own instructions and it’s the reason the thing scales. The main session is running the most expensive model with the scarcest resource in the whole setup, its own context window, and every file it reads to “just do this one quickly” is planning capacity it no longer has. The failure mode is always the same sentence, “I already have the context, I’ll just write it,” and that sentence is always true and always the trap. On a busy day the board moves a hundred-plus tickets through workers and the main session stays small enough to still be smart at the end of it.
The Kind of Work Chooses the Model
If you take one idea from this article, take this one. Everyone asks “which model should I use”, and I stopped asking it. You describe the kinds of work you actually do, once. Quick edits. Hard changes. Debugging. Reading code to answer a question. Reviewing someone else’s change. Each kind gets the model that fits it, how much thinking it should spend, and whether it’s allowed to write files at all. From then on you don’t choose per task. The kind of work chooses.
Sidequest ships with starter sets for coding, research, writing, and music, and every project I use it in has grown its own kinds on top: audio DSP work in a plugin I’m building, hand analysis in a poker bot, notation in a music project, note capture in the vault I write these articles from. My base coding set has been revised more than fifty times since July. It’s a living config, and that’s the point: model choice becomes something you refine, instead of a reflex you repeat every session.
The honest cost picture, as far as I can measure it, is that I land at roughly the same price per task as I did before, only with noticeably better output. It’s hard to compare exactly. But the reason is simple enough: the workers are cheaper, so the budget that used to go on one expensive model doing everything now buys more thinking on the tickets that need it and a proper review pass on the rest. Anthropic ran the same idea against their own benchmarks recently and reported an expensive planner with cheaper workers keeping about 96% of the top model’s performance for under half the cost. My numbers are one person’s setup, so read them that way, but they point the same direction.
A Twitter Post Put My ChatGPT Subscription on the Roster
The next step came from outside. I saw people getting the models from their ChatGPT subscription to answer inside Claude Code, and thought: what if that were a plugin, zero setup, that configured itself the first time you ran it. That became model-gateway, which I wrote about separately and won’t re-explain here. The short version for a newcomer: it’s a small local proxy that Claude Code talks to instead of talking to Anthropic directly. Requests for a GPT model go to OpenAI on your ChatGPT login, everything else passes straight through to Anthropic, and there are no API keys involved. The GPT models simply show up in Claude Code’s model picker next to Opus.
Sidequest reads the gateway’s list of available models, and when they’re there, the everyday coding kinds move to them while Claude keeps the hard calls, the planning, and the reviews. As of August 2026 most of my day-to-day coding runs on GPT models through a subscription I already paid for, and all of it from inside Claude Code. If the gateway is down, the board refuses to dispatch rather than quietly sending the ticket to Anthropic instead; you find out, you fix it, nothing gets billed by surprise.
I made a point of keeping the two plugins separate. You can run the board without the gateway and route everything to Claude models, and plenty of people should. The gateway is one more optional provider on the roster.
The cheaper tokens are also the least interesting part. A second model family disagreeing with the first one is what catches things. When the code was written by GPT and reviewed by Claude, or the other way around, you get a reviewer that doesn’t share the writer’s blind spots, and that’s worth more to me than the invoice.
Delegated Work Goes Through the Board, Direct Work Stays Direct
To be clear about what the board covers: when I ask for a one-line fix, or name the file I want changed, the main session just does it. Putting that through a ticket would be theater, and a waste of time and tokens. The board is for the work I’m handing off, and there the rule is enforced. A hook blocks the main session from spinning up an off-the-books worker and tells it to file a ticket instead. That sounds petty until you’ve watched a model rationalize its way around a rule it was given three lines earlier. Coding agents will take any loophole you leave, so the guardrails have to assume that and close the loopholes by name.
That’s also where the human sits. Nothing gets integrated into the main branch unless I do it. Every worker hands back a report I read. Review is its own ticket, pinned to a specific commit. It’s a lot of structure for a tool that started as a list, and it’s exactly the structure I’d want if I were running a small team of contractors who were very fast and occasionally very confident about the wrong thing, which is what this is.
The Honest Trade-Off
Anthropic’s own guidance on multi-agent setups is start with the simplest thing that works, and they’re right. Sequential work on one feature usually shouldn’t be split, and if your project is small enough that you can hold the whole thing in one session, you don’t need a board between you and your agent, and adding one will feel like ceremony because it will be.
Every plugin also costs you a bit of context on every turn, so a board has to earn its place on the turns where you didn’t want a board. And there’s a real failure mode where the board becomes the work: revising a ticket until a reviewer agent is happy, instead of shipping the thing. I’ve caught myself doing it.
Where it pays off is the situation I actually live in: several projects, a lot of medium-sized work in flight, a main session I want to keep sharp for hours, and a steady stream of “oh, by the way” that I don’t want to lose or act on right now.
Where to Get It
Add the marketplace, install the two user-level plugins, then run the setup in any project and it installs and configures the rest for you:
/plugin marketplace add Eigenwise/eigenwise-toolshed
/plugin install workbench@eigenwise-toolshed --scope user
/plugin install quartermaster@eigenwise-toolshed --scope userThen, inside a project, /quartermaster:setup (or just ask “set up a Claude workspace here”). Sidequest itself is installed per project, so each repo keeps its own board config. Read the docs first, really: this one sends your work to different models and runs it in worktrees, and you’ll want to know that before it happens.
The thing that made it the most powerful plugin I have is still the thing it did on day one. I get to say “oh, by the way” and keep going.
And if you’re at a company trying to get real value out of your AI stack, this is a big part of what I do: the boards, routing, and review loops that make Claude Code productive on your own codebase and your own model budget. If you’d want a hand getting it working, feel free to reach out.