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: ~3,900 input + ~980 output
10.3 Ultrawork Mode
Among OMO’s most opinionated features, Ultrawork mode is probably the clearest statement of intent. It is triggered by user keywords such as ultrawork or ulw, with implementation living under src/hooks/keyword-detector/ultrawork/. Once activated, the agent is supposed to shift from ordinary conversational assistance into an aggressively autonomous execution pattern.
The best way to understand Ultrawork is not as a small prompt trick, but as a runtime philosophy. Its underlying belief is simple and radical: human intervention is a failure signal. If the human must repeatedly remind the agent to continue, inspect more carefully, verify results, or stop simplifying the task, then the system has failed at autonomy. Ultrawork tries to operationalize the opposite standard.
The injected instructions are intentionally severe. The agent is told not to begin implementation until it fully understands the request, has explored the codebase, resolved ambiguity, and formed a precise plan. It is explicitly instructed to use specialist agents such as Explore, Librarian, Oracle, and the plan agent. It is told that partial work, scope reduction, and “you can extend this later” behavior are unacceptable. In other words, Ultrawork is not mainly about speed. It is about reducing the classic assistant failure mode of stopping at eighty percent and then narrating excuses.
This is why the keyword trigger matters. By making ultrawork a lexical switch, OMO gives the user a way to opt into a more autonomous contract. That contract includes several expectations.
First, the system should explore before acting. Rather than patching the first plausible file, it should inspect architecture, conventions, edge cases, and neighboring implementations. Second, it should research best practices when external knowledge matters. Third, it should implement end to end, not just sketch. Fourth, it should verify through builds, tests, or observable evidence. Fifth, it should continue iterating when the first attempt fails.
Those steps—explore, research, implement, verify, continue—form the real Ultrawork loop.
The feature is especially important because it addresses a subtle weakness in many coding agents: they are too conversationally polite. They often optimize for sounding helpful rather than for finishing the job. Ultrawork flips that priority. In CS terms, it introduces a stronger liveness expectation. Liveness means the system should keep making forward progress toward completion. Ultrawork tries to enforce that by combining prompt pressure, planner invocation, delegation, and downstream continuation hooks.
It is also notable that Ultrawork is agent-sensitive. OMO’s keyword detector does not blindly inject the same instructions everywhere. Planner-family agents may be treated differently, and model-specific prompt variants exist, such as GPT-oriented or planner-oriented ultrawork messages. This is an important engineering detail. It shows OMO recognizes that autonomy patterns should be adapted to role, not sprayed uniformly across the system.
There is another reason Ultrawork matters: it changes the economics of context use. Instead of forcing the main agent to do all exploration inline, the mode encourages heavy use of background subagents. Explore agents can search the repository. Librarian agents can fetch documentation or examples. Oracle can review architecture. This reduces clutter in the primary reasoning stream and turns autonomy into orchestration rather than mere verbosity.
From a design standpoint, Ultrawork also makes a strong claim about user experience. Ordinary assistants ask for frequent confirmation because that is safe. OMO argues that, for many engineering tasks, this is not actually good UX. It interrupts flow, shifts burden back to the user, and encourages underpowered execution. Ultrawork therefore treats reduced interruption as a feature. The ideal is that the user provides intent once, then watches the system work.
Of course, this philosophy has trade-offs. Higher autonomy can increase token cost, runtime length, and the risk of overcommitted behavior if the task was misunderstood. OMO’s answer is not to reject autonomy, but to sandwich it between planning and verification. That is why Ultrawork pairs naturally with Prometheus, Atlas, Ralph Loop, and Todo Continuation. The keyword is only the trigger; the broader orchestration system is what makes it sustainable.
In this sense, Ultrawork is a small feature with large conceptual significance. It translates a slogan into an executable control mode. The slogan is that coding agents should behave less like chatbots and more like responsible workers. Whether or not one agrees with its intensity, OMO deserves credit for making that ambition explicit, configurable, and technically grounded.
Many future agent systems will likely include something similar, even if under different names. A mature coding agent probably needs a high-autonomy mode, a low-autonomy mode, and a way to move between them. OMO’s Ultrawork mode is one of the earliest serious attempts to formalize the high-autonomy end of that spectrum.