A harness designs the work around a model.
OpenCode, plugins, OmO, Pi, oh-my-pi, and Codex: not a ranking, but a study of runtime, handoff, and acceptance.
RESEARCH NOTE01
Separate the model from the harness.
Model capability and environment reach are different questions.
By harness I mean the layer around a model: files, editing, shell, LSP, browser, permissions, context, delegation, and reporting. The model is one component, not the workflow.
The same model can see different files, use different tools, run in parallel, and stop at different approval points depending on the harness. Comparing names alone hides the conditions that shape the result.
I first decide where the work must finish, then choose a model that fits.
- Context
- Supply relevant material
- Tools
- Read, edit, and run
- Policy
- Define reach and stops
02
Plugins connect the workbench to events.
An OpenCode plugin is an inspectable extension boundary, not a magic button.
OpenCode’s documentation places plugins in project or global .opencode/plugins directories and also supports packages. Hooks can observe permissions, tool execution, sessions, messages, and more.
I first ask AI to read the official documentation and turn the plugin events and limits into plain language. I then discuss the repeated work I actually want to solve and design which event it may enter, what context it can read, and when it must return to me for confirmation.
A plugin should hand one clear action to AI rather than open every capability. I start with a small prototype and keep checking the diff, permissions, output, shell arguments, and data boundary before deciding to keep it.
- 01
Load
Project, global, or package
- 02
Hook
Intervene at a named event
- 03
Review
Inspect diff, access, and output
03
OmO expands orchestration—and its cost.
More agents do not automatically mean better judgement.
oh-my-opencode, with the newer oh-my-openagent naming in its documentation, extends OpenCode with multiple agents, specialist roles, LSP/AST tools, and MCPs. That can suit work where planning, research, implementation, and review run together.
OmO is the work surface I mainly use for development when a task needs cross-file understanding, planning, implementation, and review to keep handing work forward. A small task does not need that much orchestration; when OmO’s handoff, settings, or run state becomes troublesome, I switch to Codex so the diff and acceptance return to one work surface.
The thicker the orchestration layer, the more context, model settings, hooks, permissions, and failure paths need attention. I treat OmO as a mode of work, not a default switch: test one small handoff first, then decide whether the team needs to grow.
| STEP | Gain | Cost | Stop |
|---|---|---|---|
| Parallel research, roles, and tools | Included | Not included | Not included |
| More context, access, and handoffs | Not included | Included | Not included |
| Know when to return to one agent | Not included | Not included | Included |
04
Pi brings the agent back to a composable terminal.
oh-my-pi turns an extensible core into an IDE-like agent surface.
I see OpenCode as the heavier workbench: its official plugin system can load project or global extensions and hook into events and tools, so context, agents, and rules can grow together. Pi keeps a minimal terminal coding harness and asks users to compose extensions, skills, and packages; oh-my-pi adds LSP, AST, browser, Python, subagents, an SDK, and RPC. The difference is where capability is provided and where the user has to assemble it.
DeepSeek Harness is a research subject for me. Its developer preview makes models, tools, sessions, sandboxes, loops, and UI replaceable through plugins. MiniMax Code takes another route: its official repository describes a terminal coding agent that brings project understanding, edits, tests, search, plugins, and multimodal tools into one CLI surface. I have not used either for daily development; this paragraph records the design differences I found in the official material.
In my own use, GPT-class models are easier to keep coherent inside their native harness, from project reading through tool calls, diffs, and acceptance. Cursor feels similar: Composer 2.5 and Grok 4.6/4.7 integrate better there, while outside Cursor I sometimes lose the thread between context and tools. That is simply my current experience.
Core
Agent loop and terminal work
Extensions
LSP, AST, browser, subagents
Ownership
Configuration, updates, compatibility
05
Codex connects briefing, editing, and acceptance.
The important question is whether the diff returns to a person.
Codex CLI’s value is not only the model. It puts reading a project, editing files, running commands, and approvals on one work surface, which makes it easier to return each change to a diff and a test.
I do not treat OpenCode, Codex, and Pi as a replacement ranking. They differ in how context is handed over, tools are connected, permissions stop, and results return.
Before sending, publishing, or deploying, the harness should stop for a human decision instead of silently running to the end.
- Diff
- What changed
- Checks
- How it was checked
- Boundary
- What remains out
06
OpenCode and Codex are my daily drivers.
Other harnesses are for learning the differences.
OpenCode and Codex are the tools I rely on for daily development. OpenCode is my main surface for reading across files, planning, implementation, and review; Codex keeps diffs, commands, tests, and acceptance close to the same project.
I try Pi, DeepSeek Harness, and MiniMax Code to understand how each connects a model, preserves context, calls tools, and handles permissions. They are exploratory comparisons, not replacements for the tools I use every day.
There is also a practical Google constraint: third-party software cannot simply reuse Gemini CLI OAuth subscription credentials as a relay service. For a third-party coding environment, the supported routes are an AI Studio API key or Vertex AI.
- Daily
- OpenCode and Codex
- Study
- Pi, DeepSeek Harness, MiniMax Code
- Access
- Official APIs and permission boundaries