[Feature]: Add Devin CLI support

[Derpedyea]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

I want to use Devin CLI in T3 code. Devin has ACP support so I believe it should be possible to connect it like how grok cli was done.

Proposed solution

Add a Devin provider through Devin CLI's built in ACP.

Why this matters

Anyone with a Devin subscription would be able to use T3 code. While Devin isn't known for having the best harness for people searching for good promos they often do have those. An example of this is the current ongoing free GLM promotion which I have verified is running in the CLI too.

Smallest useful scope

The smallest scope is just Devin CLI support. This does not need Devin cloud features whatsoever.

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

References:

• https://docs.devin.ai/cli#windows
• https://docs.devin.ai/cli/reference/commands#devin-acp

Contribution

• I would be open to helping implement this.

[Derpedyea]

I am working on a PR with aid of codex to add the provider and I have tested it. I hope this can be added somewhat in the future.

[tylerham]

In a podcast this week, Theo mentioned he's considering adding Devin support to t3code.

[TimPietrusky]

@Derpedyea any help needed over here? would love to have this as well

[Derpedyea]

@TimPietrusky I've stopped working on it as the pr was stale and I didn't want to continue maintaining it.

[aaronhawkey]

Anyone working on this currently?

[rafael-franca]

Anyone working on this currently?

I'm working on this!

[rafael-franca]

@juliusmarminge I have finished the implementation in #6235. Can you review, please?

[rami-alloush]

I understand this was the main PR and it just got closed #7567
Which other PR is being integrated and #7567 is considered duplicate?

[LouisDeconinck]

A quick overview of the current state of Devin CLI support in T3 Code.

Devin is not currently supported on main, but there has already been substantial work toward it:

• [Feature]: Add Devin CLI support #3636
  Proposed integrating Devin through its built-in ACP support.

• [Feature]: Add Devin CLI as a supported coding agent provider #3942
  A second request for first-class Devin support.

• Add Devin CLI provider #6235
  Implemented a full Devin provider: ACP integration, authentication, model selection, usage tracking, settings/UI, mobile support and docs. Closed without merge.

• feat(acp): add Devin model families and workspace skills for v2 #11850
  Extended the newer orchestration-v2 architecture with live model discovery, reasoning variants, Fusion pairing and workspace skills. It references this discussion directly and reports a successful live run with GPT-6 Astra + SWE-2 High. Closed without merge.

So this is not a greenfield integration. Most of the technical surface has already been explored.

Why Devin CLI is worth supporting

Devin CLI exposes a broad model catalog through ACP, including OpenAI, Anthropic, Google, open-weight models and Cognition’s SWE-2 family.

The standout right now is SWE-2: Devin is currently offering unlimited SWE-2 usage for $20/month, making it exceptional value for high-volume coding work.

Devin also brings Fusion, which pairs a frontier model with a cheaper sidekick agent and delegates work between them to reduce cost while retaining strong performance.

The SWE-2 offer is promotional, but even without it, Devin CLI remains compelling because it combines ACP, a large model catalog, Fusion and an existing body of T3 Code integration work.

What I would like to see

I would like Devin CLI to become a first-class T3 Code provider.

The most sensible implementation shape seems to be:

1. Use the existing Orchestrator v2 ACP Registry path, rather than introducing another bespoke provider architecture.
2. Let Devin CLI own authentication, sessions, approvals, MCP tools and subagents through ACP.
3. Keep Devin-specific behavior at the adapter boundary:
   • live account-specific model discovery;
   • reasoning / Fast / context variants;
   • Fusion lead + sidekick selection;
   • workspace skills;
   • account/environment handling.
4. Start with the smallest useful upstreamable scope: run Devin sessions and select models reliably. Usage tracking, richer Fusion UI and other provider-specific polish can follow incrementally.

This is broadly the direction already demonstrated in #11850, and seems much cleaner than reviving the larger bespoke provider implementation from #6235.

The main question therefore seems less about whether Devin can work with T3 Code, and more about whether maintainers are open to upstreaming a focused v2/ACP implementation and what minimum scope they would want for the first PR.

[LouisDeconinck]

Following up on my comment above: I opened a focused implementation at #13645

One adjustment to the plan I sketched: the Orchestrator v2 / ACP Registry path I suggested is no longer present on main, so this PR implements Devin on the current provider-instance architecture instead, the same shape Cursor and Grok use today. That turned out to be the smaller diff anyway: provider-specific behavior stays in the Devin driver/provider/adapter, and the only shared change is making authMethodId optional in AcpSessionRuntime so a provider whose CLI already holds credentials (devin auth login) can skip the ACP authenticate round trip. Cursor, Grok and Antigravity behavior is unchanged.

Scope of this first PR, kept deliberately small:

• devin acp as the transport; no new orchestration paths
• installed / version / authenticated status via the local CLI, with devin auth login as the login story
• live model discovery from the account's ACP session catalog (95 models on my account, including SWE-2 and Fusion entries), nothing hard-coded
• sessions, streaming, tool calls, cancellation, resume, permission/mode mapping, and text generation through the existing contracts
• Fusion works today through the normal model picker; a dedicated lead/sidekick UI is left as a follow-up rather than porting the large Fusion work from feat(acp): add Devin model families and workspace skills for v2 #11850

Verified end-to-end against the real CLI (v3000.11.3): provider status, live model catalog, SWE-2 selected, one streamed turn. Screenshots and the full validation list are in the PR.

Devin Cloud stays explicitly out of scope. Happy to trim further if maintainers want an even smaller first slice.