oh-my-opencode-slim: The AI coding assistant that stops pretending one model should do everything

A slim OpenCode plugin that turns LLMs into a staffed team. An orchestrator delegates, specialists execute, and a council argues before the human ever sees the result.

8 min read • View on GitHub • More from alvinunreal

A wide terminal war room with multiple panes active at once. One central console routes tasks outward while smaller panes show specialists working in parallel, with the human still controlling the main view. It explains the project’s core idea: AI coding as managed teamwork, not a single chat window. — The interface is not a chatbot. It is a control room for delegated work.

Key Takeaways

oh-my-opencode-slim treats coding help as an organization problem, with an orchestrator deciding when to keep work local and when to hand it off.
Its most distinctive move is the background war room, where the human stays in control while specialists run in parallel outside the main chat flow.
The council exists to slow confidence down on purpose, forcing disagreement and synthesis before a final answer reaches the user.
The “slim” philosophy is not minimalism for its own sake, but a way to save context and reduce token waste when tasks start to sprawl.

The best way to understand oh-my-opencode-slim is not as an AI coding plugin, but as an operating model. The repo takes a simple position: one model should not be expected to plan, research, debug, patch, and self-check equally well. Instead, it routes work across a small staff of specialists and keeps the human in the supervisory loop.

That shift matters because it changes the unit of work. The input is no longer a prompt. It is a task that can be triaged, delegated, argued over, and recombined. Once you see it that way, the project stops looking like a prompt wrapper and starts looking like an org chart with a terminal attached.

The new unit of work is not a prompt. It is a staffed task

Seven divine beings emerged from the dawn of code, each an immortal master of their craft await your command to forge order from chaos and build what was once thought impossible.

Project README, Repository documentation · alvinunreal/oh-my-opencode-slim README

The README leans hard into the Pantheon metaphor, and that is more than branding. The system is built around role separation: an orchestrator routes, specialists execute, and a council handles higher-stakes judgment. That is the core design choice that makes the repo feel different from a standard single-agent assistant.

The practical payoff is simple. Small changes can stay local. Larger, messier, or more uncertain tasks can fan out to the right worker without bloating the main context. In other words, the assistant stops trying to be a genius and starts acting like a manager.

Inside the orchestrator: a manager, not a maker

Selective delegation is the point. The orchestrator does not fan out everything, only the work that benefits from it.

// Orchestrator logic, simplified from the repo’s routing idea
if (task.isSmallSingleFileEdit && task.estimatedLines < 20) {
  return handleLocally(task);
}

if (task.isAmbiguous || task.touchesMultipleFiles) {
  return delegateTo("fixer", task);
}

if (task.needsCodebaseRecon || task.needsStructuralSearch) {
  return delegateTo("explorer", task);
}

if (task.needsHighConfidence || task.isStrategic) {
  return delegateToCouncil(task);
}

return handleLocally(task);

That kind of routing is the real product. The orchestrator is not trying to maximize its own output. It is deciding where cognition should happen. The repo’s value comes from making delegation a first-class primitive instead of an afterthought.

A close-up pipeline where a single task card enters a triage gate, then splits into specialist routes and a council branch before returning as one verified result. It explains how the system decides when to stay local, when to delegate, and when to demand consensus. — The key idea is selective fan-out, not automatic fan-out.

Why the council matters more than another agent

The council is the repo’s answer to a familiar failure mode: high confidence from a single model can be worse than modest confidence from several. Instead of trusting one pass, the system can force multiple models to respond, expose contradictions, and synthesize a resolution. That is not parallelism for its own sake. It is a deliberate way to slow down bad certainty.

Dimension	Single-agent workflow	oh-my-opencode-slim
Who decides next steps	One model improvises the whole path	The orchestrator routes work by task shape
Codebase understanding	Usually gathered inside one long context	Split between reconnaissance, fixing, and synthesis
Disagreement handling	Often invisible or absent	The council surfaces contradictions explicitly
Context efficiency	Context grows inside one conversation	Work can be offloaded to background specialists
Best fit	Small, straightforward prompts	Multi-step work, uncertain tasks, and parallel review

The comparison is really about governance. A single agent is convenient when the problem is tiny. A managed system is better when the problem is sprawling, ambiguous, or expensive to get wrong. The repo is betting that the second case is where serious coding tools are headed.

The specialists are constrained on purpose

The specialist roles matter because they are not interchangeable. Explorer is built for read-only codebase recon. Fixer is for execution, not research. Other roles, like Oracle or Consul, sit closer to reasoning and reflection than to patching code. The architecture depends on boundaries, not just capabilities.

Explorer: read-only, structural search, codebase awareness
Fixer: implementation, patching, no web research
Oracle: strategic reasoning
Consul: planning and reflection
Council: contradiction, synthesis, higher-confidence judgment

That separation reduces agent soup. If every worker can do everything, orchestration becomes noise. If each worker has a narrow job, the system can coordinate them with less ambiguity and fewer wasted tokens.

The hidden plumbing that keeps the whole system from spiraling

The less glamorous parts of the repo are what keep the glamorous parts usable. Hooks like patch application and JSON recovery protect against malformed outputs. Depth tracking prevents recursive subagents from spinning out of control. In a system like this, guardrails are not optional. They are the difference between managed delegation and a prompt labyrinth.

The implementation also reflects a practical engineering mindset. The codebase leans on TypeScript for orchestration, with a Rust companion component in the repo, and uses structural tools like ast-grep rather than plain text search where it matters. That is a strong signal that the project is built around code understanding, not just token generation.

Why slim is the point

The fork is not chasing maximal capability. It is trying to make orchestration cheaper to run and easier to keep in context. That is why the repo frames itself as slimmed and fine-tuned, with less token waste as part of the product story.

That choice is more important than it sounds. Once a system starts spawning background workers, councils, and specialist passes, overhead can eat the benefit fast. A slimmer control layer keeps the orchestration affordable enough to use in real work instead of only in demos.

Question	What a simple assistant optimizes for	What oh-my-opencode-slim optimizes for
Primary shape	Conversation	Coordination
Main risk	Weak answers	Wasted context and noisy delegation
Success metric	One good reply	The right worker on the right task
Interface feel	Chat-first	Terminal war room
Scaling pressure	More prompt length	More routing discipline

That is the real product argument. If AI coding is going to scale, it probably will not do so by making one model smarter in isolation. It will do it by making supervision, routing, and review cheaper.

What this changes about AI coding UX

The broader implication is straightforward. The best interface may not be a chat thread at all. It may be a manager’s dashboard, where the human assigns intent, watches specialists work, and intervenes when the system needs judgment.

That is why this repo stands out. It does not just add more agents. It proposes a different mental model for using them. The human is no longer the only worker in the room. The human becomes the editor, and the system becomes the staffed desk.

If that model keeps spreading, the winning tools will not be the ones that talk the most. They will be the ones that route best.