Same Job, Opposite Bets: Cline vs OpenCode vs Pi

Type "fix the failing test" into any of these three tools and the same thing happens: an AI reads your files, edits code, runs the test, and fixes it. All three are open source. All three work with any model. And yet they could not be more different.

One is a batteries-included platform that runs in your terminal, your IDE, and a background daemon (a long-running process that keeps working after you close the window) — and can coordinate a whole team of agents. One is built like a proper web service — a single engine that a terminal, a desktop app, and a web UI all talk to over HTTP. And one is deliberately tiny — it ships four tools and dares you to build the rest yourself.

Same job. Opposite bets. This post compares Cline, OpenCode, and Pi head-to-head — their philosophies, their guts, and which bet is right for you.

New to coding agents? Read the next section, skim the head-to-head rounds, and jump to Which One Is Right for You? for the recommendation. The "Under the Hood" section goes deep on architecture — it's there if you want it, but you don't need it to choose.

First: What Even Is a Coding Agent?#

A chatbot replies once; you copy-paste. An agent acts in a loop: it calls a tool (read a file, run a command), sees the result, and decides the next move — repeating until the job is done.

You:   "Fix the failing test in auth.ts"
Agent: reads auth.ts             (acts)
       runs the test, sees fail  (acts + observes)
       edits the code            (acts)
       re-runs the test — passes (observes)
       "Fixed — the token check was inverted." (reports)

A few words we'll reuse: a tool call is one request from the model to run a tool. The context window is the model's limited short-term memory, measured in tokens. A provider is the company hosting the model (Anthropic, OpenAI, Google…). MCP (Model Context Protocol) is a standard plug for external tools. A subagent is a helper agent that another agent hands work to.

Here's the key idea: the model is the brain; the agent harness is everything around it — the loop, the tools, the safety, the memory, the UI. Cline, OpenCode, and Pi are three very different harnesses around the same kind of brain. The difference isn't what they do — it's their philosophy.

Meet the Contenders#

Cline — "The Batteries-Included Platform"#

Cline (Apache-2.0, TypeScript) ships as a CLI, a VS Code extension, a JetBrains plugin, a Kanban web board, and an embeddable SDK — all on one shared engine. It's human-in-the-loop by design (approval prompts, Plan/Act modes, checkpoints that undo any change) and goes big: a background Hub daemon shares live sessions across apps, plus agent teams, subagents, chat connectors (Slack/Telegram/…), scheduled/cron automation, and plugins, hooks, rules, skills, workflows, MCP.

• Interfaces: CLI, VS Code, JetBrains, Kanban, SDK
• License: Apache-2.0
• One-liner: "The one that does everything and runs everywhere"

OpenCode — "The Client/Server Engine"#

OpenCode (MIT, TypeScript on the Effect framework + Bun) is architected as one server with many front-ends: a terminal UI, a desktop app (beta), a web UI, IDE integration via ACP (Agent Client Protocol — a standard way for editors to talk to agents), and SDK consumers. It has a first-class permission system (allow/ask/deny), 38 language servers built in, and a durable "V2" session core where sessions survive crashes and context is assembled from cache-friendly, composable pieces.

• Interfaces: TUI, web, desktop (beta), editor (ACP), server, SDK
• License: MIT
• One-liner: "The one built like a real product — an engine with clients"

Pi — "The Minimal Core You Reshape"#

Pi (MIT, TypeScript) is a stack of small libraries — pi-ai (talk to any model), pi-agent-core (the loop), and pi-tui (the terminal UI) — under a thin pi CLI. Its core is radically minimal: four built-in tools (read/write/edit/bash) plus three optional read-only ones. No MCP, no subagents, no plan mode, no to-dos, no permission pop-ups, no background bash — on purpose. Everything "missing" is a short TypeScript extension you drop in (no build step), and the repo ships ~78 examples. Sessions are a branchable tree in one file (/tree, /fork, /clone).

• Interfaces: CLI (interactive / print / JSON / RPC), SDK
• License: MIT
• One-liner: "The one that hands you a scalpel and gets out of the way"

Head-to-Head Showdown#

Round 1: The Core Philosophy#

Takeaway: Cline optimizes for reuse across many surfaces; OpenCode for one engine, many clients, clean contracts; Pi for a small core you can understand and reshape.

Round 2: The Agent Loop & Tools#

Takeaway: Cline and OpenCode hand the model a big toolbox out of the box; Pi hands it a sharp minimal set and expects you to add the rest. Pi's parallel-tools-in-one-context is its built-in form of "do sub-tasks at once."

Round 3: Multi-Agent & Task Decomposition#

This is where the philosophies really split.

Takeaway: need coordinated multi-agent work with persistence? Cline. Need clean, isolated, permission-contained delegation? OpenCode. Prefer to compose it yourself (or just run agents in tmux panes)? Pi.

Round 4: Safety & Permissions#

An agent that can run rm -rf and edit files needs a safety story — and one of these is deliberately unsafe by default.

Takeaway: Cline has the most guard-rails-out-of-the-box; OpenCode has the most principled, configurable policy engine; Pi is the most powerful and the most dangerous. But note: all three ultimately run on your machine — none is a true sandbox. Pi is just the most explicit about it, arguing that a half-sandbox living inside the app would feel like a boundary while still leaning on your shell and credentials — so real isolation must come from the OS.

Round 5: Models & Provider Freedom#

Takeaway: all three are strongly multi-provider. Cline has the biggest generated catalog; OpenCode's on-demand npm install is the most future-proof; Pi's mid-chat model switching and serializable sessions are the slickest for experimentation.

Round 6: Context Management#

Every long task eventually overflows the context window (the model's limited short-term memory). The fix is compaction — summarizing the old part of the conversation so it still fits. Each tool does it a little differently.

Takeaway: OpenCode's cache-friendly Context Sources are the most advanced (and save real money on long sessions); Cline's separated sidecar is a clean safety design; Pi's tree means compaction is never truly destructive.

Round 7: Extensibility#

Takeaway: Cline and OpenCode give you structured, well-typed extension systems; Pi gives you raw, immediate extensibility (write TypeScript, it runs). If your workflow needs something none of them ship, Pi is the fastest to bend.

Round 8: Interfaces & How You Run It#

Takeaway: want an IDE plus a Kanban board of agents? Cline. Want a server other tools attach to? OpenCode. Want a scriptable terminal tool and an embeddable engine? Pi.

Scoreboard#

Under the Hood: How Each System Is Designed#

This section is for the curious — it's the "how is it actually built inside" tour, and it gets more technical than the rest. If you just want a recommendation, skip to Which One Is Right for You?. Still here? Each design teaches a real system-design pattern you can reuse.

Cline — The Stateless-Loop + Stateful-Host Stack#

Cline is a one-directional dependency stack (shared → llms → agents → core → apps) where a stateless run loop is wrapped by a stateful manager. One RuntimeHost interface lets a task run locally, in a background hub daemon, or against a remote server — unchanged.

Key design decisions:

• Stateless loop + stateful host — The hard part of "run one turn" is a pure loop; everything durable lives above it. That's why the same loop runs in-process, in the hub, or remotely.
• One execution boundary (RuntimeHost) — LocalRuntimeHost / HubRuntimeHost / RemoteRuntimeHost; the top-level object never branches on "local or remote."
• The Hub daemon — A background process (like tmux for agents) that owns live sessions and shares them over WebSockets; apps attach/detach without killing the work. Secured with a per-process auth token and "build-identity fencing" so two installed versions don't fight.
• Generated provider catalog — Adding a model shouldn't touch the loop; the catalog is code-generated from models.dev.
• Lazy persistence — A brand-new session lives only in memory until its first completed turn, so there's no empty-session clutter.

OpenCode — The One-Contract, Many-Clients Server#

OpenCode authors its HTTP API once as an Effect contract, binds it to handlers, serves it over a Node HTTP server, and consumes it via code-generated SDK clients. A TUI, a web app, a desktop app, and editors are all just clients of the same engine.

Key design decisions:

• Strict dependency direction — schema → core/protocol → server → binary; clients may depend only on schema+protocol, never core/server.
• Contract-first + codegen — One API definition; Promise and Effect clients are auto-generated and a guard forbids hand-editing them, so they never drift.
• Permission engine as a core service — allow/ask/deny, glob, last-match-wins, per-agent rulesets, persistent "always" grants.
• V2 durable session runtime — Prompts are admitted to a durable inbox before running; a serialized "Session Drain" promotes input at safe boundaries; System Context is composable Context Sources with a baseline reused for provider prefix caching.
• Embedded mode — sdk-next runs the whole server's router in memory — real API behavior, no network.

Pi — The Minimal Core With Everything as an Extension Point#

Pi is a stack of independently useful libraries where the product creates exactly one agent, stores conversations as a branchable tree, and exposes rich extension points instead of baking features in.

Key design decisions:

• Minimal core, extension-first — Features other tools hard-code (subagents, plan mode, to-dos, MCP, permission pop-ups) are deliberately out; each is an example extension instead. The core stays small and understandable.
• Serializable everything — The conversation and model descriptor are plain JSON → save/resume by JSON.stringify, and switch models mid-chat (pi-ai rewrites messages for the new provider).
• Sessions as a tree in one JSONL file — Every entry has id/parentId; /tree, /fork, /clone are just tree operations. Compaction is lossy for context but lossless for history.
• Pluggable tool operations — A tool accepts an *Operations interface, so read/bash can run locally, over SSH, or in a sandbox without rewriting the tool.
• Trust guards loading, not running — and there's no sandbox by design; isolation is the OS's job. Supply-chain hardening (exact-pinned deps, release-age delay, --ignore-scripts installs) is built in.

Architecture Comparison#

What All Three Have in Common#

Despite opposite philosophies, all three converge on the same underlying patterns — worth understanding if you build for the AI era:

1. The agent loop is universal — Send conversation → model asks for tools → run tools → feed results back → repeat. Understand one and you understand all three.
2. Provider-agnostic by design — None locks you to a vendor; all support BYO-key across many providers, so you optimize for cost, quality, and privacy.
3. The context window is the enemy, and compaction is the answer — Every one summarizes old history to keep long tasks alive, and every one keeps the full original recoverable. Compaction is lossy for the model, lossless on disk.
4. Instruction files are the standard — All three read AGENTS.md / CLAUDE.md-style project instructions — a genuine cross-tool convention now.
5. Skills = load-on-demand expertise — All three implement SKILL.md-style progressive disclosure: the model sees only names + descriptions until a task matches, then loads the body.
6. Tool output must be bounded — All three cap tool output (truncate / spill-to-file / 50 KB) so one noisy command can't blow the context window.
7. They run on your machine with your permissions — None is a hosted, indexed cloud service, and none is a true sandbox. The safety differences are about defaults and gates, not magic isolation.

Honest Limitations#

Before you install one, here's what each won't do.

Shared by all three: they need a model (cost, latency, credentials) and can be wrong; none is a sandbox (auto-approve/yolo/skip-permissions modes remove the human gate); compaction is lossy in-context; and prompt injection — a malicious instruction hidden in a repo — is a real, largely unpreventable risk.

Which One Is Right for You?#

"I want a full-featured agent in my editor, with safety rails and room to grow into teams of agents"#

Cline. Approval + Plan/Act + checkpoints on day one, VS Code/JetBrains/CLI/Kanban surfaces, and when you outgrow one agent, persistent agent teams and connectors are right there.

npm install -g cline
cline auth
cline "Explain what this project does"

"I want to build tooling on top of a coding agent — a web UI, an editor plugin, a bot — all against one clean API"#

OpenCode. It's literally designed as a server with generated SDK clients and a documented HTTP contract; the permission engine and 38 LSPs make it a serious foundation.

curl -fsSL https://opencode.ai/install | bash
opencode          # interactive TUI
opencode serve    # headless server for clients to attach to

"I want a sharp, minimal, provider-flexible terminal agent I can mold to my exact workflow without forking anything"#

Pi. Four tools, ~78 example extensions, no-build-step TypeScript, mid-chat model switching, and a branchable session tree. You add only what you need.

npm install -g --ignore-scripts @earendil-works/pi-coding-agent
export ANTHROPIC_API_KEY=sk-ant-...
pi

"Safety and control matter most"#

OpenCode for a configurable policy (allow/ask/deny per agent), or Cline for the most guard-rails-by-default (approval + shadow-git undo). Pi only if you run it in a container/VM — it has no built-in gate.

"License matters for commercial work"#

All three are permissive: OpenCode and Pi are MIT, Cline is Apache-2.0 — plus Cline offers usage-billing and a subscription if you'd rather not manage keys.

Decision Flowchart#

Final Verdict#

There's no universal winner — the right choice is about which bet fits how you work.

Pick Cline if you want the most batteries-included experience: approvals and undo out of the box, your IDE and terminal and a Kanban board all covered, and room to grow into agent teams and scheduled automations. It feels like a complete product on day one.

Pick OpenCode if you think like an engineer building on a platform: one clean HTTP engine that a TUI, a web app, and your editor all attach to, a real permission policy, 38 language servers, and a genuinely clever crash-durable, cache-friendly context design.

Pick Pi if you want a scalpel, not a Swiss Army knife: a tiny, fast, provider-flexible terminal agent you reshape with a few lines of TypeScript, with the best model-switching and the cleanest session model. Just remember — you are the sandbox, so run it in a container for anything risky.

The beautiful part? They're all open source and all model-agnostic. The wrong choice isn't "which of these" — it's not trying any of them while you keep copy-pasting from a chat window.