Orca, Pi, and OpenCode: Open-Source Agentic Tools and the Changing Practice of Software Development
https://github.com/gwrxuk/shoal
Abstract
AI coding agents have moved software development from line-by-line autocompletion toward delegating whole tasks to language-model programs that read, edit, run and test code. This paper gives a detailed introduction to three open-source, MIT-licensed tools that represent distinct layers of this new stack. OpenCode is a full-featured coding agent with a client/server architecture, five built-in agents, thirteen built-in tools, a rule-based permission system, and integrations with editors, GitHub and 34 built-in language servers. Pi is a deliberately minimal agent harness: four tools, a system prompt under 1,000 tokens, tree-structured sessions, and an extension system through which the agent can rewrite its own tooling. Orca is an agent development environment (ADE) that runs many third-party agents, including OpenCode and Pi, in parallel, each in an isolated git worktree, with review, mobile supervision and a scriptable CLI. For each tool we describe origin, design philosophy, architecture and workflow, using primary sources and registry data retrieved on 23 September 2026. We then analyse how these tools change software development. We identify seven shifts: from authoring to specifying and reviewing; parallel exploration as a unit of work; context engineering as a developer skill; agents as programmable infrastructure; self-modifying tooling; decoupling from model vendors; and new security and governance duties. We relate these shifts to published empirical evidence, which is mixed. A controlled experiment found a 55.8% speed-up on a bounded task, while a randomized trial with experienced open-source developers found a 19% slowdown. We conclude that the tools change where developer effort goes more reliably than how much effort is needed, and we outline open research questions.
Keywords: AI coding agents; agent harness; agent development environment; software engineering practice; developer productivity; context engineering; git worktrees; open-source software
1. Introduction
Software development is undergoing its largest tooling change since the integrated development environment. The 2025 Stack Overflow Developer Survey found that 84% of respondents were using or planning to use AI tools, up from 76% a year earlier [42]. Google’s 2025 DORA research, based on nearly 5,000 technology professionals, reported AI adoption of 90% [43]. Adoption of autonomous agents is earlier: in the same Stack Overflow survey, 14.1% of respondents used AI agents daily and 37.9% did not plan to use them [42].
The first generation of AI assistance was autocompletion inside an editor. The current generation is the coding agent: a program that gives a large language model (LLM) tools to read files, edit code and run commands, then loops until a task is done. Research systems such as SWE-agent showed that the design of this agent-computer interface strongly affects results [41]. Benchmarks such as SWE-bench made real GitHub issues the standard test [40].
As agents matured, the tooling split into layers. One layer is the agent harness: the loop, tools, prompt and context management. A second layer supervises several agents at once, isolates their work and routes their output to human review. This paper introduces three open-source projects that together span these layers:
• OpenCode [23][24], a full-featured coding agent available as a terminal UI, desktop app, IDE integration and headless server.
• Pi [9][10], a minimal, self-extensible agent harness and TypeScript toolkit.
• Orca [1][2], an agent development environment that runs many CLI agents in parallel, each in its own git worktree.
We address four research questions:
• RQ1. What does each tool do, and how is it built?
• RQ2. How do the tools differ in design philosophy?
• RQ3. How do they compare on measurable, verifiable attributes?
• RQ4. How can tools of this kind change the practice of software development?
Our contributions are a detailed, sourced description of the three tools as of 23 September 2026 (Sections 3–5), a structured comparison (Section 6), and an analysis of their effect on software development grounded in published evidence (Section 7). Section 2 covers background and method. Section 8 discusses limitations and Section 9 concludes.
2. Background and Method
2.1 From autocompletion to agents
Early evidence on AI-assisted programming came from autocompletion tools. In a controlled experiment, developers with GitHub Copilot implemented an HTTP server in JavaScript 55.8% faster than a control group [38]. Autocompletion keeps the developer as the author of every line.
Agents change that relationship. SWE-bench evaluates whether a model can resolve real issues. It contains 2,294 task instances from 12 popular Python repositories, and at publication the best model resolved 1.96% of them [40]. SWE-agent introduced the term agent-computer interface (ACI). It argued that LLM agents are a new kind of user whose tools must be designed for them, and it reached 12.5% pass@1 on SWE-bench [41]. The three tools studied here are practical descendants of this idea. Each makes different choices about how rich the agent’s interface should be.
2.2 Enabling standards
The three tools build on a small set of open conventions. Table 1 summarizes them.
Table 1. Standards and conventions used by the tools.
2.3 Method
We used only primary sources: official repositories and source files, project websites and documentation, author blog posts, Y Combinator company pages, peer-reviewed or preprint research, and machine-readable registry APIs. We did not use third-party reviews or aggregator sites for any figure. Documentation was read in its source form in each repository where possible.
Quantitative repository data were retrieved on 23 September 2026 from these endpoints:
Table 2. Data sources for quantitative metrics.
The same queries were run for earendil-works/pi and anomalyco/opencode. The contributor count includes anonymous (email-only) committers, so it differs from the total shown on a GitHub repository page. Star and download counts change daily and should be read as a snapshot.
3. Orca: An Agent Development Environment
3.1 Origin
Orca is built by Stably AI, a San Francisco company in Y Combinator’s Winter 2022 batch, founded by Jinjing Liang (CEO) and Neil Parker [3]. Y Combinator describes it as an “MIT open source terminal-based agent orchestrator” and “an ADE built for engineers who run 10 to 100 coding agents at once” [3]. The repository was created on 17 March 2026. By 23 September 2026 it had 75,830 stars and its latest release was v1.4.207, published 22 September 2026 [1][48]. The README’s tagline is “The AI Orchestrator for 100x builders” [1].
3.2 Design philosophy
Orca’s central decision is not to build an agent. Its documentation says it “runs agents you already use — bring your own Claude, Codex, or OpenCode subscription” [2]. The README states that it works with “any CLI agent — if it runs in a terminal, it runs in Orca” [1]. It names 31 agents, including Claude Code, Codex, Cursor, GitHub Copilot, Antigravity, OpenCode, Pi, Goose, Cline and Qwen Code [1].
This makes Orca a supervisor. It assumes the developer’s bottleneck is no longer one agent’s ability but the human’s ability to run, watch and review many agents. The environment is organized around tasks, not files. In the documentation’s words, “Every task gets its own git worktree, its own agent terminal, and its own browser tab” [2].
3.3 Architecture
Orca is a desktop application built on Electron. Its package.json declares Electron 43.7.0, React 19, the Monaco editor (the editor component of VS Code), xterm.js for terminals and node-pty for pseudo-terminals [4]. It is published for macOS, Windows and Linux [2]. Each agent runs as an ordinary CLI process inside a terminal owned by Orca. Orca therefore does not need an integration API from each agent vendor; anything with a command-line interface can be hosted.
Execution need not be local. Agents can run “remotely — over SSH, on a self-hosted Orca server, or in an on-demand VM” [2], and a headless server can be started with orca serve [1]. The documentation stresses that Orca is “not a hosted VPS product” and runs on machines the user controls [2]. A separate relay in the repository pairs the mobile app with a desktop host [1].
3.4 The worktree lifecycle
A git worktree is a second working directory attached to the same repository, which lets a developer “check out more than one branch at a time” [44]. Orca makes the worktree the unit of agent isolation. Its documented lifecycle has five stages [5]:
1. Create. The developer names a task and chooses a start point. The “Branch from” control accepts the repository’s base ref, another local branch, a specific commit SHA or a remote branch [5]. Branch names are derived from the workspace name or from a linked GitHub PR or Linear/Jira issue [5]. The git fetch and git worktree add steps run in the background so the interface stays responsive [5].
2. Work. The chosen agent launches as the first tab of the new worktree [5].
3. Review. A diff view compares the worktree against its start point [5]. Developers can comment on individual diff lines and send the comments back to the agent [1].
4. Ship. Commit, push and open a pull request from inside Orca [5].
5. Archive or delete. “One click removes the worktree and branch” [5]. If a branch may still hold unmerged commits, Orca can offer a review step first [5].
New worktrees do not start empty of dependencies. Orca can share paths from the primary checkout (as a copy-on-write clone on macOS where possible, otherwise a symlink). It can symlink gitignored directories listed under worktree.sharedDirectories in orca.yaml, and it can copy files listed in a .worktreeinclude file [5]. The documentation summarizes the benefit: “parallel agents are safe — they never step on each other’s files” [5].
3.5 Supervising many agents
Orca adds several features aimed at supervision rather than authoring:
• Fan-out. One prompt can be sent to five agents, each in its own worktree, so the developer can “compare the results and merge the winner” [1].
• Usage tracking. Orca “reads local usage state for Claude Code, Codex, Gemini, OpenCode, Kimi Code, and MiniMax” and shows it in the status bar, warning at 80% of a rate limit. Developers can switch between configured accounts [8].
• Notifications. Orca signals when an agent finishes or needs attention, and threads can be marked unread [1].
• Mobile companion. An iOS and Android app pairs with the desktop using a one-time code, optionally through Orca Relay. From a phone, a developer can “see every worktree, its agent, and its current status (working / done / waiting on input)” and “send a short reply (continue, yes, free-text) when an agent is waiting on input” [7]. The desktop remains “the source of truth” [7].
3.6 The Orca CLI: agents driving the environment
The orca command is “the command-line interface for scripting a running Orca editor from any shell” [6]. Because agents also run shells, the CLI lets an agent drive Orca itself: create worktrees, read other terminals or control a browser. Table 3 lists the command groups. Agents can learn the CLI as a skill with npx skills add https://github.com/stablyai/orca — skill orca-cli [6].
Table 3. Orca CLI command groups [6].
Browser control follows “a snapshot-interact-re-snapshot loop”: orca snapshot — json returns element references such as @e1, which orca click and orca fill then act on [6]. This lets an agent check its own front-end changes in a real Chromium window.
3.7 Feature summary
Table 4. Principal features of Orca.
Orca is installed from onorca.dev/download, with Homebrew (brew install — cask stablyai/orca/orca), or from the AUR (stably-orca-bin) [1].
4. Pi: A Minimal, Self-Extensible Agent Harness
4.1 Origin
Pi was created by Mario Zechner (GitHub handle badlogic). The monorepo was created on 9 August 2025 as badlogic/pi-mono [9][13]. In a post dated 30 November 2025, Zechner explained why he built it [11]. Existing harnesses, he wrote, had become complex, changed behavior between releases and made it hard to see what entered the model’s context. He wanted a cleanly documented session format and a simple way to build alternative user interfaces [11].
Armin Ronacher described Pi on 31 January 2026 as the minimal agent inside OpenClaw [12]. On 8 April 2026, Zechner announced that he was joining Earendil, a company co-founded by Ronacher, and bringing Pi with him [13][14]. The repository moved to earendil-works/pi. Zechner stated that the core is “MIT, forever. Non-negotiable” and that he remains in charge of Pi decisions together with Earendil’s co-founders [13][14]. By 23 September 2026, the repository had 108,622 stars and its latest release was v0.87.1 [9][48].
4.2 Design philosophy
Pi is defined as much by what it omits as by what it includes. Its coding agent has four built-in tools: read, write, edit and bash [11][12]. Zechner reports that the system prompt and tool definitions together come to “below 1000 tokens” [11]. The rationale is that reading, writing, editing and running code cover most programming work, and that a small, stable prompt keeps the model’s behavior predictable and inspectable.
Pi deliberately leaves out several features common in other agents [11]:
• MCP. Zechner calls MCP servers “overkill for most use cases” because tool descriptions consume context. He prefers command-line tools with README files that the agent reads when needed.
• Built-in sub-agents. He argues that hidden sub-agents reduce observability. An agent can still start another Pi process explicitly through bash.
• Plan mode. Plans should be ordinary Markdown files that persist across sessions and can be shared.
• Permission prompts. Pi runs “YOLO by default.”
Anything left out can be added back by the user, or by the agent itself, as an extension.
4.3 The agent loop and context
Pi’s documentation describes the loop precisely [15]. A submitted message joins the active branch of the session. Pi builds a request from the system prompt, the active branch, the available tools and model settings, and sends it to the chosen provider. The provider streams back text and tool calls; Pi executes each tool call and records the results. That is one turn. If tool results or queued messages need another model request, another turn begins. Otherwise the run ends [15].
Pi separates two kinds of user interjection. Steering messages enter after the current assistant turn, while follow-up messages wait until the agent has finished its pending work [15]. The system prompt is assembled from base instructions and discovered context files such as AGENTS.md and CLAUDE.md [15][22]. Skill descriptions are always present, but a skill’s full instructions load only when the task needs them [15].
4.4 Sessions as trees
Most agents store a conversation as a list. Pi stores it as a tree. “Messages and events in a session form a tree. Each path through that tree is a branch” [15]. Sessions are saved as JSONL files in which each entry has an ID and a parent [15]. Table 5 shows the three branching operations.
Table 5. Pi session branching operations [16].
When a developer leaves a branch, Pi can summarize it and attach the summary to the new branch, so useful findings survive without the full transcript [16]. When context nears the model’s limit, Pi compacts automatically. Compaction triggers when context tokens exceed the context window minus a reserve, which defaults to 16,384 tokens [17]. It inserts a summary entry, but the original entries stay in the session file [15][17]. Sessions can be exported as HTML or JSONL, or shared through a viewer link [16].
4.5 Extensibility: extensions, skills, templates and packages
Pi’s main mechanism for growth is the extension. “Extensions are TypeScript modules that add executable behavior to Pi” [18]. They load through jiti, so they need no separate compilation step [18]. An extension exports a factory function that receives an ExtensionAPI object. Table 6 lists its main integration points.
Table 6. Main integration points of the Pi extension API [18].
Extensions receive lifecycle events from before_agent_start through model, message and tool events to agent_end, followed by agent_before_settle and agent_settled [18]. Typical uses listed in the documentation include adding a tool, protecting paths, confirming dangerous commands and displaying status [18]. Ronacher highlights two properties: extensions can persist state into sessions, and hot reloading lets the agent “write code, reload, test it and go in a loop until your extension actually is functional” [12]. In practice, a Pi user often asks Pi to build the feature it lacks.
Three lighter resource types complement extensions. Skills follow the Agent Skills specification: a directory with a SKILL.md file and optional scripts, references and assets [19]. Prompt templates expand reusable text in the editor, and themes set terminal colors [15]. Pi packages bundle all of these for distribution through npm or git, for example pi install npm:@example/pi-tools@1.0.0. A package can be tried for a single run with pi -e [20].
4.6 Interfaces, providers and the package family
Pi offers four interfaces that share the same agent and session mechanisms [15]:
• Interactive mode, the terminal UI.
• Print mode, which runs one prompt and writes the final answer.
• JSON mode, which streams agent events as JSONL.
• RPC mode, which accepts JSONL commands on standard input, plus an in-process TypeScript SDK.
Model access is multi-provider. The /login command connects a provider through OAuth or an API key [21]. The documentation lists 31 providers that need a single API-key environment variable, among them Anthropic, OpenAI, Google Gemini, GitHub Copilot, Mistral, Groq, xAI, OpenRouter and DeepSeek, plus cloud providers such as Amazon Bedrock and Google Vertex AI [21].
The monorepo publishes Pi as a family of npm packages (Table 7). Developers can build their own agents on pi-ai and pi-agent-core without using the Pi CLI.
Table 7. Packages in the Pi monorepo [9].
4.7 Security model and project practices
Pi is explicit about its security model. It “does not ask for approval before every tool call” and runs with the operating-system permissions of the account that started it [22]. The documentation warns that files, comments and command output “can steer the model through prompt injection” [22]. A project-trust step controls whether a folder may load its own settings, extensions and packages, but “it does not sandbox tool calls” [22]. For real isolation, the README recommends running Pi in Docker, in a policy-controlled sandbox, or with a micro-VM extension [9].
The project also applies strict supply-chain rules. Direct dependencies are pinned to exact versions, npm resolution avoids same-day releases (min-release-age=2), and the published CLI ships an npm-shrinkwrap.json [9]. Issues and pull requests from new contributors are closed automatically by default and reviewed daily by maintainers [9]. Zechner publishes his own Pi work sessions as an open dataset on Hugging Face and invites other users to share theirs [9].
Pi is installed with npm install -g — ignore-scripts @earendil-works/pi-coding-agent (Node.js 22.19 or newer) or curl -fsSL https://pi.dev/install.sh | sh [10]. Documentation is at pi.dev/docs/latest.
5. OpenCode: A Full-Featured, Provider-Agnostic Coding Agent
5.1 Origin
OpenCode is developed by Anomaly, the Toronto-based team behind the SST serverless framework. Y Combinator lists it in the Winter 2021 batch, with founders Jay V and Frank Wang [36]. The repository, now anomalyco/opencode, was created on 30 April 2025; the former sst/opencode path redirects there [23][48]. By 23 September 2026 it had 209,481 stars and its latest release was v1.18.32 [23][48]. The project’s website reports 16M monthly developers [24]; we could not verify this figure independently.
The name has a second, unrelated history. A Go-based terminal agent was also published as opencode-ai/opencode. That repository is archived, and its README says the project “has continued under the name Crush” with the Charm team [37]. This paper covers only the Anomaly project.
5.2 Design philosophy
Where Pi minimizes, OpenCode includes. Its aim is a complete, batteries-included agent that works well without customization, is not tied to one model vendor, and can be embedded anywhere. Common workflows such as planning, codebase exploration, dependency research and language-server feedback are built in as agents and tools. Safety is handled by a configurable permission system rather than left to the user’s sandbox.
5.3 Client/server architecture
OpenCode separates the agent from its interface. “When you run opencode it starts a TUI and a server. Where the TUI is the client that talks to the server” [26]. opencode serve starts a headless server, by default on 127.0.0.1:4096, which publishes an OpenAPI 3.1 specification at /doc [26]. The same server supports a desktop app (in beta), IDE integrations, a web interface and a JavaScript SDK [23][25].
Get Jung-Hua Liu’s stories in your inbox
Join Medium for free to get updates from this writer.
The codebase is TypeScript on the Bun runtime [23]. The workspace dependency catalog lists SolidJS and OpenTUI for interfaces, Hono for the HTTP server, the Vercel AI SDK (ai) for model access, Effect, and Drizzle ORM with SQLite [50]. Through the Agent Client Protocol, opencode acp runs OpenCode as a subprocess that talks JSON-RPC over standard input and output, so ACP-compatible editors such as Zed can host it [34].
5.4 Agents
OpenCode ships two primary agents and three subagents (Table 8). Primary agents are switched with the Tab key; subagents are called by a primary agent or mentioned with @ [27].
Table 8. Built-in OpenCode agents [27].
Developers can define their own agents with custom prompts, models and tool access [27].
5.5 Tools and permissions
OpenCode has 13 built-in tools (Table 9). “By default, all tools are enabled and don’t need permission to run” [28]. Behavior is then shaped by the permission configuration.
Table 9. Built-in OpenCode tools [28].
Each permission rule resolves to “allow”, “ask” or “deny”, can be set globally with *, and supports wildcards such as “mymcp_*”: “ask” for all tools from one MCP server [28][29]. The — auto flag approves any request that is not explicitly denied; explicit denials still apply [29].
5.6 Context: rules and language servers
OpenCode reads project instructions from an AGENTS.md file [30]. The /init command scans the repository, may ask a few targeted questions, and writes or updates AGENTS.md with build, lint and test commands, non-obvious architecture, and project conventions. The documentation recommends committing this file to git [30].
OpenCode integrates with Language Server Protocol servers “to use diagnostics as feedback for the agent” [31]. The documentation lists 34 built-in servers, covering languages from C/C++ (clangd) and Go (gopls) to Java (jdtls), Haskell, OCaml and Nix [31]. After an edit, compiler and linter diagnostics flow back to the model without a separate build step.
5.7 Extensibility and integrations
OpenCode extends in several ways:
• Custom tools and MCP servers add new model-callable operations [28].
• Plugins are JavaScript or TypeScript modules loaded from .opencode/plugins/, ~/.config/opencode/plugins/, or npm packages named in the configuration. They hook into events and can add custom tools [32].
• GitHub integration. After opencode github install, mentioning /opencode or /oc in an issue or pull-request comment runs OpenCode inside the repository’s GitHub Actions runner. It can triage an issue, or fix it on a new branch and open a pull request [33]. A GitLab integration also exists [25].
• Session sharing. /share creates a public link of the form opncd.ai/s/<share-id>. Sharing is manual by default and can be set to automatic or disabled [35].
OpenCode is provider-agnostic. Its website states support for “75+” LLM providers through Models.dev, including local models, and sign-in with GitHub Copilot and ChatGPT Plus/Pro accounts [24]. Anomaly also offers an optional curated model service, OpenCode Zen [24]. The website states that OpenCode “does not store any of your code or context data” [24].
OpenCode is installed with curl -fsSL https://opencode.ai/install | bash, npm i -g opencode-ai@latest, Homebrew, Scoop, Chocolatey, pacman, mise or Nix [23].
6. Comparative Analysis
The three tools occupy different layers. Orca orchestrates agents; OpenCode and Pi are agents that Orca can run. Table 10 compares their design and Table 11 gives repository and package metrics.
Table 10. Design comparison (sources in Sections 3–5).
Table 11. Repository and package metrics, retrieved 23 September 2026 [48][49].
Pi’s download figure excludes its pre-move package, @mariozechner/pi-coding-agent, which recorded a further 2,666,043 downloads in the same period [49]. npm counts include automated installs such as CI runs, so they measure distribution, not unique users.
Two contrasts stand out. First, OpenCode and Pi embody opposite answers to the agent-computer-interface question raised by SWE-agent [41]. OpenCode gives the model a rich, specialized interface (13 tools, five agents, language-server feedback). Pi gives it a minimal, general one and relies on the model to compose bash commands and write new tools when needed. Second, Orca shows that once agents share a common interface, the terminal, the competitive frontier moves up a layer to orchestration and review.
7. How These Tools Change Software Development
This section addresses RQ4. We identify seven shifts that the three tools make possible or reinforce. For each, we describe the mechanism in the tools and relate it to available evidence. Table 12 summarizes them.
Table 12. Seven shifts in software development practice.
7.1 From authoring code to specifying and reviewing it
With autocompletion, the developer still writes each line. With agents, the developer describes an outcome and judges the result. Orca’s lifecycle (create, work, review, ship) puts review at the centre of the developer’s work, and its line-level diff annotation turns review comments directly into agent instructions [1][5]. OpenCode’s Plan agent separates analysis from change, so a developer can agree on an approach before any file is edited [27].
The productivity effect of this shift is not settled. On a bounded, greenfield task, Copilot users finished 55.8% faster [38]. In contrast, METR’s randomized controlled trial with 16 experienced open-source developers working on 246 real tasks in their own mature repositories found that allowing early-2025 AI tools increased completion time by 19% [39]. The developers had expected a 24% reduction, and even afterwards they believed they had been 20% faster [39]. The gap between perceived and measured speed suggests that the new work of specifying, waiting and reviewing is easy to underestimate. Tools that make review faster and more structured, as Orca attempts, address exactly that cost.
7.2 Parallel exploration as a unit of work
Traditional development is largely serial: one developer, one branch, one attempt at a time. Worktree isolation removes the main technical obstacle to running several attempts at once. Orca’s documentation describes sending one prompt to five agents and merging the best result [1]. OpenCode’s General subagent is described as a way “to run multiple units of work in parallel” [27]. Pi’s session tree lets a single developer branch a conversation to explore an alternative without losing the original path [16].
This changes the economics of experimentation. When a second attempt costs compute rather than developer time, it becomes rational to try several designs and compare them. The limiting factor becomes the developer’s capacity to review, which is why Orca invests in notifications, status views and mobile supervision [7][8].
7.3 Context engineering becomes a developer skill
An agent knows only what is in its context window. All three tools therefore push developers to make project knowledge explicit and machine-readable. OpenCode’s /init writes an AGENTS.md file with build commands, architecture notes and conventions, and the documentation recommends committing it [30]. The AGENTS.md format reports use in over 60,000 open-source projects [47]. Skills package procedures that load only when needed; Pi and OpenCode support them, and Orca uses one to teach agents its CLI [6][19][28].
Pi makes context management especially visible. It shows context usage in the footer, compacts older history into summaries, and summarizes abandoned branches when the developer navigates the session tree [16][17]. Zechner’s case for a sub-1,000-token prompt is itself a context-engineering argument: every token of fixed instructions is a token unavailable for the task [11]. For developers, documentation shifts from a courtesy for new team members to an input that directly affects the quality of automated work.
7.4 Agents become programmable infrastructure
When an agent exposes an API, it can be embedded wherever code already runs. OpenCode’s headless server publishes an OpenAPI 3.1 specification [26]. Its GitHub integration runs the agent in GitHub Actions when someone comments /opencode on an issue, and can return a pull request [33]. Pi offers print, JSON and RPC modes and an in-process SDK, and its lower-level packages can be used to build different agents altogether [9][15]. The Orca CLI lets agents create worktrees, read other agents’ terminals and drive a browser [6].
The practical result is that agents join the software delivery pipeline. Issue triage, first-draft fixes, dependency research and front-end verification can be triggered by events rather than by a developer at a keyboard. DORA’s 2025 research describes AI as “a ‘mirror and a multiplier’”: it boosts efficiency in cohesive organizations and exposes weaknesses in fragmented ones [43]. Automated agents are likely to amplify whatever testing and review discipline a pipeline already has.
7.5 Self-modifying tooling
In Pi, the fastest way to get a missing feature is often to ask the agent to build it. Extensions are TypeScript files that load without compilation and hot-reload, so the agent can “write code, reload, test it and go in a loop until your extension actually is functional” [12][18]. OpenCode plugins and custom tools offer a similar path [32]. Development environments have long been customizable, but customization used to require the developer’s own time. When the agent writes the customization, each developer, or each project, can have tooling shaped to its exact workflow.
7.6 Decoupling from model vendors
All three tools separate the development workflow from any single model provider. OpenCode connects to more than 75 providers, including local models [24]. Pi’s pi-ai package offers one API across 31 API-key providers plus cloud platforms [21]. Orca goes a step further and treats entire agents as interchangeable. It hosts 31 named CLI agents and tracks rate limits across several of them [1][8]. Model choice therefore becomes an operational decision made per task on cost, speed or quality, rather than a platform commitment. It also reduces the risk that one vendor’s pricing or policy change halts a team’s work.
7.7 New security and governance duties
Agents that run shell commands turn prompt injection and supply-chain attacks into practical risks. Pi’s documentation is direct: it “does not ask for approval before every tool call,” files and command output can steer the model through prompt injection, and “watching the transcript, using project trust, and reviewing changes do not create a security boundary” [22]. OpenCode offers allow, ask and deny rules but enables all tools without approval by default [28][29]. Orca’s worktrees isolate agents’ files from each other, not from the host system [5].
Teams adopting these tools therefore take on new responsibilities: choosing sandboxes or containers, writing permission policies, reviewing third-party extensions and plugins, and treating agent output as untrusted input. Pi’s own supply-chain practices, such as pinned dependencies, delayed dependency adoption and shrinkwrapped releases [9], show the kind of discipline that agent-heavy development requires. Trust remains limited: in the 2025 Stack Overflow survey, 46% of developers distrusted the accuracy of AI output and 33% trusted it [42].
7.8 Synthesis
Taken together, the evidence suggests these tools change where developer effort goes more reliably than they reduce it. Effort moves from typing code to describing tasks, curating context, supervising parallel attempts, reviewing diffs and managing risk. Whether that yields a net gain depends on task type, codebase maturity and the quality of the surrounding engineering practice [39][43]. The three tools represent three bets on how to make the new work efficient: OpenCode on built-in capability, Pi on transparency and self-extension, and Orca on parallelism and review.
8. Discussion and Limitations
Layering, not competition. Orca is a supervisor, not an agent, and its value grows as agents like OpenCode and Pi improve. The main design contrast is between the two agents: rich built-in capability versus a minimal, inspectable core. The two approaches are likely to converge in some areas. Pi users can add plan modes and permission gates as extensions, and OpenCode users can restrict tools and rely on external sandboxes.
Governance. All three projects are MIT-licensed, but each has a company steward: Stably AI, Earendil and Anomaly. Zechner’s public commitment that Pi’s core stays MIT [13] is a statement of intent, not a legal guarantee for future code. Sustained open development depends on these companies’ business models.
Limitations. First, the projects release almost daily, so features and metrics will date quickly. Second, we did not run benchmarks, and no primary source reports comparable task-success figures for all three tools. Third, stars, downloads and self-reported user counts measure attention and distribution, not quality or productivity. Fourth, most feature descriptions come from the projects’ own documentation and were not independently tested. Fifth, the productivity studies cited in Section 7 evaluated other tools (GitHub Copilot and early-2025 frontier AI tools), so their results should not be read as measurements of these three tools.
Open research questions. Controlled studies are needed on (a) whether parallel multi-agent workflows improve outcomes or only shift the review burden, (b) how minimal and rich agent-computer interfaces compare on the same models and tasks, © how AGENTS.md and skills affect agent success rates, and (d) which permission and sandbox defaults balance safety against developer friction.
9. Conclusion
Orca, Pi and OpenCode are three open-source, MIT-licensed layers of the AI coding stack. OpenCode is the most widely adopted by GitHub stars (209,481) and offers the richest built-in feature set: five agents, 13 tools, 34 built-in language servers, a permission system and a documented server API. Pi shows that a four-tool, self-extending core with tree-structured sessions can reach comparable distribution (9.37 million npm downloads in 30 days). Orca, created only in March 2026, adds a worktree-based orchestration layer that lets one developer run and review many agents at once.
These tools change software development by moving developer effort from writing code toward specification, context curation, parallel supervision, review and risk management. The empirical evidence on net productivity is mixed and depends on context. Future work should evaluate these tools on shared benchmarks and study, in real teams, how developers divide work between themselves and orchestrated agents.
References
All URLs accessed 23 September 2026.
[1] Stably AI. Orca [source code repository and README]. GitHub. https://github.com/stablyai/orca
[2] Stably AI. What is Orca? Orca Docs. https://www.onorca.dev/docs
[3] Y Combinator. Stably AI (Orca). https://www.ycombinator.com/companies/stably-ai-orca
[4] Stably AI. Orca package.json. GitHub. https://github.com/stablyai/orca/blob/main/package.json
[5] Stably AI. Worktrees. Orca Docs. https://www.onorca.dev/docs/model/worktrees
[6] Stably AI. Orca CLI overview. Orca Docs. https://www.onorca.dev/docs/cli/overview
[7] Stably AI. Mobile companion. Orca Docs. https://www.onorca.dev/docs/mobile
[8] Stably AI. Usage tracking. Orca Docs. https://www.onorca.dev/docs/agents/usage-tracking
[9] Earendil. Pi Agent Harness [source code repository and README]. GitHub. https://github.com/earendil-works/pi
[10] Earendil. Pi coding agent README. GitHub. https://github.com/earendil-works/pi/tree/main/packages/coding-agent
[11] Zechner, M. (2025, November 30). What I learned building an opinionated and minimal coding agent. https://mariozechner.at/posts/2025-11-30-pi-coding-agent/
[12] Ronacher, A. (2026, January 31). Pi: The Minimal Agent Within OpenClaw. https://lucumr.pocoo.org/2026/1/31/pi/
[13] Zechner, M. (2026, April 8). I’ve sold out. https://mariozechner.at/posts/2026-04-08-ive-sold-out/
[14] Ronacher, A. (2026, April 8). Mario and Earendil. https://lucumr.pocoo.org/2026/4/8/mario-and-earendil/
[15] Earendil. How Pi Works. Pi documentation. https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/how-pi-works.md
[16] Earendil. Sessions and Context. Pi documentation. https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/sessions.md
[17] Earendil. Compaction Reference. Pi documentation. https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/compaction.md
[18] Earendil. Extensions. Pi documentation. https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/extensions.md
[19] Earendil. Skills. Pi documentation. https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/skills.md
[20] Earendil. Pi Packages. Pi documentation. https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/packages.md
[21] Earendil. Provider Authentication. Pi documentation. https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/providers.md
[22] Earendil. Security. Pi documentation. https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/security.md
[23] Anomaly. OpenCode [source code repository and README]. GitHub. https://github.com/anomalyco/opencode
[24] Anomaly. OpenCode: The open source AI coding agent [website]. https://opencode.ai/
[25] Anomaly. OpenCode Documentation. https://opencode.ai/docs
[26] Anomaly. Server. OpenCode Documentation. https://opencode.ai/docs/server/
[27] Anomaly. Agents. OpenCode Documentation. https://opencode.ai/docs/agents/
[28] Anomaly. Tools. OpenCode Documentation. https://opencode.ai/docs/tools/
[29] Anomaly. Permissions. OpenCode Documentation. https://opencode.ai/docs/permissions/
[30] Anomaly. Rules. OpenCode Documentation. https://opencode.ai/docs/rules/
[31] Anomaly. LSP Servers. OpenCode Documentation. https://opencode.ai/docs/lsp/
[32] Anomaly. Plugins. OpenCode Documentation. https://opencode.ai/docs/plugins/
[33] Anomaly. GitHub. OpenCode Documentation. https://opencode.ai/docs/github/
[34] Anomaly. ACP Support. OpenCode Documentation. https://opencode.ai/docs/acp/
[35] Anomaly. Share. OpenCode Documentation. https://opencode.ai/docs/share/
[36] Y Combinator. OpenCode. https://www.ycombinator.com/companies/opencode
[37] OpenCode AI. opencode-ai/opencode [archived repository]. GitHub. https://github.com/opencode-ai/opencode
[38] Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590. https://arxiv.org/abs/2302.06590
[39] Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. https://arxiv.org/abs/2507.09089
[40] Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., & Narasimhan, K. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024. arXiv:2310.06770. https://arxiv.org/abs/2310.06770
[41] Yang, J., Jimenez, C. E., Wettig, A., Lieret, K., Yao, S., Narasimhan, K., & Press, O. (2024). SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. arXiv:2405.15793. https://arxiv.org/abs/2405.15793
[42] Stack Overflow. (2025). 2025 Developer Survey: AI. https://survey.stackoverflow.co/2025/ai
[43] Google. (2025, September 23). How are developers using AI? Inside Google’s 2025 DORA report. https://blog.google/innovation-and-ai/technology/developers-tools/dora-report-2025/
[44] Git Project. git-worktree Documentation. https://git-scm.com/docs/git-worktree
[45] Model Context Protocol. Specification (2025–06–18). https://modelcontextprotocol.io/specification/2025-06-18
[46] Agent Client Protocol. Agent Client Protocol [website]. https://agentclientprotocol.com
[47] AGENTS.md. AGENTS.md [website]. https://agents.md/
[48] GitHub REST API. Repository, release and contributor endpoints for the three repositories, e.g. https://api.github.com/repos/anomalyco/opencode
[49] npm downloads API. e.g. https://api.npmjs.org/downloads/point/last-month/@earendil-works/pi-coding-agent
[50] Anomaly. OpenCode package.json. GitHub. https://github.com/anomalyco/opencode/blob/dev/package.json
