Run this 3-task test before making OpenCode 2.0 your daily harness

OpenCode 2.0 centralizes its terminal, web, and desktop clients on one locally started background service. If you are weighing it as a daily harness, start where the pain lives: context that swells, sessions that die when you move machines, and long jobs that block the terminal. The upgrade path is a choice. OpenCode v1.19.0, released on October 11, stopped automatic installation of updates. So the decision is yours, and it should be tested before you move your work.

A harness comparison is less about model cleverness than about the wrapper keeping work alive. The wrapper decides what the model sees, what runs in the background, and what survives a restart. Those are the parts you can test without buying a new model or rewriting your workflow.

Build a fixed task that exposes the wrapper

The context test needs a fixed prompt, not a vague try-the-new-thing prompt. Pick a task that touches several MCP servers and a local file change. OpenCode 2.0 includes @opencode/codemode, which exposes MCP servers and OpenAPI endpoints as callable functions. Every MCP server is enabled for Code Mode by default in OpenCode 2.0. Anomaly's team states that Code Mode allows adding many MCP servers while keeping context bloat low. Your job is to check whether that claim survives your repo, your prompt, and your model.

Keep the task small enough that you can see the whole trace. OpenCode provides built-in worktree tools named worktree_create, worktree_list, and worktree_remove for use in Code Mode. Ask the agent to create a worktree, list it, and remove it. If the new version can call those tools cleanly, the old version's behavior becomes your baseline. If it cannot, you have already found a migration blocker.

Do not make the prompt clever. A clever prompt hides the harness. Context bloat shows up when the model has to choose a tool, wait for a result, and then use that result. The wrapper either keeps the tool schema out of the way or buries the answer under a wall of instructions.

Run the three checks before moving daily work

The checklist below is the whole test. Each item is a quick check, not a benchmark. Run it on the old harness first, then on the new one, using the same repo and the same prompt. Write down what you see, not what you hope to see.

• Diff the fixed multi-MCP prompt context in both versions and note the opening tool call, context size, and error.
• Open a second machine, start the /pair session if the harness exposes it, and confirm the first machine sees the same conversation.
• Hand a long command to a background subagent, close the terminal, and check whether the job survives and reports back.

The three checks map to the three failure modes: context, machine change, and long work. A win on context does not rescue a broken /pair session, and a clean /pair session does not rescue a background job that dies when the terminal closes. If the new version wins every check, it is worth a trial. If it loses a check, keep the old harness for that job.

Do not average the results. A harness can be excellent at context and terrible at background work. Your daily use is a mix, so the mix is the verdict. Weight the checks by your actual work: short edits favor the context test, long builds favor the background test, and frequent machine switching favors /pair.

Judge the result with a record, not a vibe

Record a few numbers: tool calls before a useful edit, visible context lines before the answer, and retries after a failure. You do not need a perfect metric. You need a number that lets you say the new version was faster, slower, or the same. If the number is close, prefer the harness that fails more quietly.

Also record the failure shape: clean errors, useful tool errors, and background jobs that say they are running are easier to live with than silent hangs, long blocks of structured output, and jobs that disappear when the terminal closes.

Do not let a win decide the switch. A harness that handles a demo well can still be a bad daily driver. The test is done when you can say which job still needs the old harness.