Orca Agent

The deciding trait is that you choose how much rope it gets. There are three modes, from suggesting edits, through an auto-edit that stays inside a sandbox, up to full access, and trust is granted per folder rather than once for everything. Starting in the timid mode and promoting a directory you care less about is a workflow that actually survives a real repository.

The rest is a competent terminal agent with a competent TUI, which describes several tools on this board. Pick it if the permission ladder is the thing you have been missing. Pick Aider if you would rather have the older, better-documented one.

Per-folder trust has no documented expiry. A directory you promoted during one easy afternoon stays promoted, and nothing in the row describes revoking it, reviewing what is currently trusted, or prompting again when the task changes. The permission model is only as good as your memory of it.

There is no git integration either, so the recovery path after a bad full-access run is whatever you set up yourself. What it gets right is cancellation: stopping a turn stops the subagent tree beneath it, which is more than most tools with subagents can claim when you press the key.

1. Subagent identity is runtime-owned rather than model-supplied: synchronous children, asynchronous children and workflow children all receive continuation ids from the runtime. That places the addressing scheme outside the text the model produces, which removes an entire class of hallucinated-reference failures. 2. The interface contracts are declared stable, so an external client can be written against them without tracking releases.

2. No evaluation is offered, and the design does not require one, since every claim here is about structure rather than capability. Structure of this kind usually outlives the model it was built for.

The economics here belong to DeepSeek. This is built native to one provider, the documented setup takes that provider's key, and nothing in the row names a second one, so the cost story and the availability story are both somebody else's decisions. That is a real bet, and it is currently the cheap side of the bet.

Moat: none, and 503 stars on a solo repository does not create one. Likely path: it either adds providers and becomes a generic terminal agent, or it stays the good DeepSeek client and lives or dies with that price list. Likely acquirer: nobody. Position: fine while the tokens are cheap.

The headless mode is what makes this discussable. orca exec runs in a script or a pipeline, sessions resume and fork, so a failed run can continue rather than start again, and that is the difference between a demo and a step I can put in front of a merge. Nothing per seat for sixty engineers either.

Everything else is missing. No identity provider, no audit export, no retention statement, and support is a repository with one maintainer's name on it. Onboarding is small: install, one key, one config. Approved with conditions: pipeline use only, with the key issued centrally rather than per developer.

MIT, and the extension surface is unusually complete for a terminal tool: project instructions, skills, plugins and custom tools all load from the project, and MCP contributes both tools and resources rather than tools alone. Resources is the part most clients skip, and it is the part that makes a server worth writing.

A single compiled binary is one artefact I can drop anywhere, which I like more than I expected to. What I cannot do is point it at my own endpoint; the model side is fixed and that is the wall in an otherwise open tool.