Model: openai/gpt-5.4
Generated: 2026-04-01
Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead
Chapter: 10 — Oh-My-OpenCode’s Innovations
Token Usage: ~4,300 input + ~1,060 output
10.6 41-Hook Five-Tier System
OMO’s hook system is one of the clearest examples of how far a plugin architecture can be pushed. Internally, OMO organizes 41 hooks into five tiers:
- Session — 19 hooks
- Tool-Guard — 9 hooks
- Transform — 4 hooks
- Continuation — 7 hooks
- Skill — 2 hooks
These groupings are visible in files such as create-session-hooks.ts, create-tool-guard-hooks.ts, create-transform-hooks.ts, create-continuation-hooks.ts, and create-skill-hooks.ts.
Why does this matter? Because OMO is not merely adding more tools or more prompts. It is programming behavior across the agent lifecycle. A hook is essentially an interception point: code that runs when a certain event or phase occurs. OMO uses OpenCode’s limited plugin hook surface and multiplexes many internal behaviors onto it.
The word multiplex deserves explanation because it is not always familiar outside systems or networking contexts. In CS, multiplexing means carrying multiple logical channels over a smaller number of physical channels. OMO does something analogous. OpenCode exposes only a handful of major plugin hook points, but OMO routes dozens of internal policies through them. Many logical behaviors share the same host entry point.
The Session tier contains behaviors tied to runtime state and lifecycle, such as context-window monitoring, session recovery, think mode, Ralph Loop, delegate-task retry, start-work support, notepad injection, and preemptive compaction. This tier is about shaping the overall rhythm of a session.
The Tool-Guard tier governs tool usage. This is where OMO can block bad patterns, inject rules, preserve safety constraints, or clean up tool outputs. Important examples include comment-checker, rules-injector, write-existing-file-guard, hashline-read-enhancer, and the task-todowrite disabler. Tool-guards matter because the tool boundary is where an LLM’s intentions touch the external world.
The Transform tier handles message transformation before the model sees context. Here live pieces such as the keyword detector, context injection, Claude Code hook compatibility, and the thinking-block validator. This tier is especially powerful because it can alter the model’s effective prompt without changing the core host runtime.
The Continuation tier includes the systems that keep work alive across interruptions and incomplete runs: stop-continuation guard, compaction context injector, compaction todo preserver, todo continuation enforcer, unstable-agent babysitter, background notification, and Atlas integration. This tier is a major reason OMO feels more persistent and more supervisory than ordinary agents.
The Skill tier is smaller but strategically important. It includes category-skill reminders and auto-slash-command behavior, helping skills become active participants in runtime guidance rather than static assets.
Several hooks illustrate OMO’s design maturity particularly well.
comment-checker exists to prevent generic AI-generated comments from polluting code. This is an unusual but insightful safeguard. It recognizes that low-value comments are a common output artifact of LLM coding and treats them as a quality issue worth intercepting systematically.
rules-injector helps bring repository-specific rules into the working context automatically. That makes the agent more likely to honor local conventions without the user re-explaining them every time.
think-mode manages reasoning posture and token budget. In practical terms, it helps the system dynamically decide whether to act in a shallow or deeper thinking style. This is an important pattern because agent quality is not only about which model is used, but also about how much reasoning budget is allocated at the right moment.
Another key point is configurability. Hooks can be enabled or disabled through configuration. That matters because a 41-hook system would be unbearable if it were rigid. OMO instead treats the hook inventory as a configurable policy graph. Teams can adopt the full orchestration posture or dial parts of it down.
The bigger lesson is architectural. Many agent builders focus first on model choice and only later on behavioral control. OMO shows the reverse path: once a host exposes enough lifecycle hooks, a plugin can become an entire policy engine. That policy engine can control quality, safety, continuity, prompt assembly, and UX far more precisely than prompt text alone.
This is also why OMO feels much more like an operating layer than a thin extension. The 41-hook system is effectively its nervous system. It watches, transforms, retries, guards, reminds, and preserves. Without it, OMO would still have interesting agents. With it, OMO becomes a true orchestration runtime.