Devin support

[LouisDeconinck]

Any chance you might consider adding support for Devin CLI (I can implement if you want). The reason this is interesting is that they provide unlimited SWE-2 (KIMI K3 model) for just $20/month, which is the best value subscription out there at the moment.

[mvschwarz]

Thanks for the offer. Received; the team that owns runtime and harness support is looking at where a Devin CLI adapter would fit alongside the Pi adapter and the broader harness work, and will reply here with a real answer rather than a quick yes or no.

— dev-planner (OpenRig team)

[mvschwarz]

Thanks for offering to build it; that's the useful kind of offer. Here is where it would fit, honestly.

Today a harness is a runtime adapter inside the daemon: launch, resume, readiness, activity, identity and permission handling, each written per harness. The Pi adapter is the closest precedent, because Pi runs behind an OpenRig-owned runner rather than as a native TUI. We're thinking of moving most of that per-harness knowledge into a declarative preset (launch command, resume flag, ready prompt, process names, session-id capture, permission arguments, config location) and evaluating whether to drive harnesses over the Agent Client Protocol where they ship a server. Discussion #43 has the field list we'd start from.

So before a draft PR, the questions that decide the shape: does the Devin CLI run as a long-lived terminal session with a prompt, or one shot per task? Can it resume a session by id? How does it signal that a turn finished and it is idle? Does it expose an ACP server or a structured event stream? Where do its auth and config live? If you can answer those here, we can tell you whether it's a thin adapter or a preset entry, and whether ACP is the faster route.

One honest condition: a new runtime is a maintenance commitment, so an adapter lands with someone willing to keep it working as the Devin CLI changes. If that's you, we'd review a draft early rather than late.

— dev50-planner@v-openrig-build, on behalf of @mvschwarz · posted by dev-planner

[LouisDeconinck]

Devin both supports ACP and CLI. Would be really valuable if you could implement this.

[mvschwarz]

Thanks, @LouisDeconinck, and sorry for the slow reply. Knowing Devin has both ACP and a CLI answers one of our questions above. New agent types will come in through one shared way of adding them, being designed in Discussion #43, so that's where Devin would fit rather than as its own one-off adapter. A Devin adapter isn't scheduled on our side, so there's no date. Once that shared path exists, an adapter from someone who'll keep it working as Devin changes is welcome, and your offer from the start of this thread fits that.

[mvschwarz]

An update, @LouisDeconinck: the shared path we mentioned now exists. OpenRig 0.7.2 can run another coding agent as a community harness without any change to OpenRig's code: a small preset file plus a launcher script you maintain, labelled community-maintained and untested, with your name and the limits you declare. The invitation, with what works today and what doesn't yet, is on #43 (#43 (comment)), and the plug-in contract is in the docs on main (What a community harness gets). We haven't tried Devin's CLI this way. Your offer from the start of this thread fits it: a preset in your own repo is the quickest path, and if you post it on #43 we'll link it.

[mvschwarz]

An update, @LouisDeconinck: the community harness contract we said was on main is now in 0.7.3. We haven't tried Devin with it.

[lab1207]

No Devin adapter today — current runtimes are Claude Code, Codex, Pi, terminal, stub, plus the newer ones (Gemini, Grok, Hermes, Kimi, OMP, Cursor). But your offer to implement is exactly how new runtimes arrive here. Do this:

1. Copy the pi adapter's shape in packages/daemon/src/adapters/: a runner protocol (contract), a pane-hosted runner, and a runtime adapter (launch/readiness/delivery). The live precedent is issue Scope ask: OpenCode (opencode.ai) as a community runtime — adapter implemented and live-tested on a fork #517, where exactly this pattern brought OpenCode up on a fork (feat/opencode-runtime) — follow its file layout and discipline.
2. Open it as a scope proposal first (like Scope ask: OpenCode (opencode.ai) as a community runtime — adapter implemented and live-tested on a fork #517) before the full build, so the maintainer confirms the runtime fits the roadmap.

What the maintainer will look for, based on recent reviews: honest capability limits stated upfront (e.g. no resume → fresh launch stated, not faked), typed events for anything status depends on, and tests through the real store. The adapter seam (runtime-adapter.ts five-method contract) is the starting point.

[mvschwarz]

Thanks, @lab1207, for pointing to #517's pattern. One correction on the list of runtimes: OpenRig's runtimes are Claude Code, Codex, Pi, OMP, terminal and stub. Gemini, Kimi and Grok are models you can use inside the Pi or OMP runtimes, not runtimes of their own: Gemini and Grok through OMP, and Kimi through Pi or OMP. There's no Hermes or Cursor runtime. For adding a new runtime, our 6 October reply still holds: new ones will come in through one shared path, being designed in Discussion #43, rather than as one-off adapters.