OpenCode vs Pi: How Much Should a Harness Do?

Both run in your terminal. Both are open source and written in TypeScript. Both let you point at whichever model you like, including open ones.

They disagree about something more interesting than features: how much a harness should decide before you arrive.

OpenCode arrives furnished. Pi arrives with a system prompt famously under a thousand tokens and skills that load only when the moment calls for them.

The short answer

OpenCode suits you if the agent is a tool you use. You want diagnostics from your language server, Plan and Build modes, provider choice, and Model Context Protocol (MCP) support working on the first afternoon, and you would rather spend your attention on your codebase.

Pi suits you if the agent is a thing you tune. You want to know what is in the context window, you intend to shape the harness around how you work, and a small readable core is worth more to you than a broad feature set.

Both are credible. This is a question about your temperament and your problem, and the honest answer is that plenty of good engineers land on each side.

The small-prompt argument

Pi's defining choice is that its system prompt is tiny and its skills load lazily. Under a thousand tokens of standing instructions, with everything else injected when relevant.

That is a real engineering position rather than a minimalism aesthetic, and it rests on three claims worth taking seriously:

Context is the scarce resource. Every token of standing instruction is a token unavailable to your code, and it is present on every single turn. On a long agentic run that compounds.

Instructions compete with each other. A large system prompt covering many situations gives the model rules that do not apply to the current task. Loading a skill when it is relevant keeps the instruction set matched to the moment.

A small core is legible. You can read Pi's harness and hold it in your head, which means when it behaves strangely you can find out why.

The counter-argument is equally real: a furnished harness has already made hundreds of small decisions correctly, and reproducing them yourself costs weeks you might prefer to spend elsewhere.

Head-to-head

The feature that most often decides it

Language Server Protocol integration.

OpenCode reads diagnostics from your language server, so the model is corrected by your compiler rather than by its own opinion about whether the code compiles. On a large TypeScript or Go codebase this changes the quality of a session noticeably, because the agent's mistakes get caught by the toolchain before they reach you.

If your work is mostly in one strongly-typed language with a good language server, that single feature is a strong argument for OpenCode, and it is the thing you would have to build yourself on the other side.

If your work spans many languages, shell, config and infrastructure, where the language server does less for you, the argument weakens and Pi's smaller surface becomes more attractive.

Both protect the thing that matters most

Whichever way you lean, both keep the model choice yours.

OpenCode reaches 75+ providers through Models.dev, including local endpoints. Pi's unified model API does the same job with less ceremony. Either will happily run GLM-5.2 or a local checkpoint, which means the routing arrangement and its cost arithmetic survive the harness decision intact.

That is worth more over a year than any feature in the table above. A harness that locked you to one vendor would cost you the ability to put cheap models on routine work, and that is where the money is.

How to decide in an evening

Install both. Give each the same real task from your backlog, something with a few files in it, not a toy.

Then notice which frustration you had. Wanting a feature that was missing points at OpenCode. Wanting to know why the agent did something, and finding the answer buried, points at Pi.

For where these sit against libraries and personal agents, see runtime, harness, product. Next in the series: OpenClaw vs OpenCode.

Sources

• OpenCode
• Pi on GitHub