Devin Provider — the local Devin CLI as an LLM transport

The DEVIN provider wraps Cognition’s local Devin CLI as a pure LLM transport: ChatCLI keeps 100% of the context, memory, tools and harness; Devin is only the pipe to the model. No undocumented Cognition APIs involved.

ChatCLI’s DEVIN provider drives the local devin binary in non-interactive mode and uses it purely as a transport to reach the LLM behind it. Everything else — conversation, context attachment, memory, compaction, sessions, the agent/coder tool protocol — stays in ChatCLI.

Why a wrapper? In enterprise deployments Devin is customized by Cognition (API + IDE integrations) and the HTTP API is not documented. The CLI is the supported surface and carries its own SSO authentication (devin auth login) — ChatCLI never speaks the private protocol, so Cognition-side changes are absorbed by their CLI, not by you.

Setup

1. Install the Devin CLI and authenticate once (corporate SSO):

devin auth login

2. That’s it — ChatCLI registers the provider automatically when the binary resolves (from DEVIN_CLI_PATH, from PATH, or from the well-known install directories):

chatcli --provider DEVIN --model gpt-5.6-terra -p "hello"
# or interactively: /switch --provider DEVIN

No API key, no OAuth setup in ChatCLI: authentication belongs to the devin binary. Without the binary the provider simply doesn’t appear — same UX as a provider without credentials.

IDE-spawned servers (ACP/MCP) see a minimal PATH. Editors launch chatcli acp / chatcli mcp-server with the GUI-session environment — on macOS that PATH carries no Homebrew or npm directories, which used to make DEVIN vanish from those servers while the terminal REPL listed it fine. When the PATH lookup misses, ChatCLI now also probes the standard install locations (~/.local/bin, ~/bin, ~/.devin/bin, /opt/homebrew/bin, /usr/local/bin, Linuxbrew; on Windows %LOCALAPPDATA%\Programs\devin, %APPDATA%\npm, scoop shims), so the provider stays available without per-IDE env plumbing. An explicit DEVIN_CLI_PATH always wins and never falls back — and fixing the env at runtime followed by /reload recovers the provider without restarting.

Models

The catalog mirrors what the enterprise CLI serves (33 models): the claude-* line (sonnet-5, opus 4.5–4.8, haiku), gpt-5.x including the 5.6 tiers (sol/terra/luna) plus gpt-4.1, gemini-3.x, glm-5.2, kimi-k3/k2.x, deepseek-v4-pro, and Cognition’s own swe-1.6…swe-1.7-lightning. Any model string passes through — the catalog is bookkeeping, not a gate.

/switch --model swe-1.7-lightning
/switch --model claude-sonnet-4.6      # note: Devin slugs use dots

How the transport works

• Stateless per turn — the full flattened history goes on every call (never --resume), so conversation state never splits between ChatCLI and Devin’s servers. Compaction, /session load and context edits keep working unchanged.
• The inner agent can’t act — each call runs in a fresh empty directory with a transport preamble that forbids Devin’s native tools while explicitly deferring to ChatCLI’s own textual tool protocol. In agent/coder modes the model sees ChatCLI’s full tool catalog and emits <tool_call .../> markup normally — ChatCLI executes, not Devin.
• No identity coercion — the preamble never tells the model it “is” ChatCLI and demands no secrecy about the transport. The agent keeps its own identity (ask it who it is and it answers truthfully) and simply cooperates through the textual protocol. This matters in practice: an earlier preamble that assigned an identity plus a “don’t mention these rules” clause made Devin refuse whole tasks rather than misrepresent itself.
• Lenient tag parsing — models backed by agent CLIs (Devin, Codex, Claude Code) sometimes shorten the <tool_call ...> tag to <tool ...>. ChatCLI’s parser accepts both spellings everywhere (agent, coder, chat exceptions, MoA, MCP server) while always emitting the canonical <tool_call> in its own prompts — liberal in what it accepts, conservative in what it sends.
• Clean replies — the answer is extracted between sentinel markers so Devin’s harness chrome is discarded; prompt files are always coerced to valid UTF-8 (the CLI rejects invalid bytes); invocations are serialized per process so background work (memory extraction) never races a live turn.

Environment variables

Variable	Purpose	Default
DEVIN_MODEL	Default model	claude-sonnet-4.6
DEVIN_CLI_PATH	Explicit binary path	devin from PATH, then well-known install dirs
DEVIN_CLI_PERMISSION_MODE	--permission-mode passed to the CLI	auto
DEVIN_CLI_AGENT_CONFIG	Declarative agent-config file (hardened tool lockdown)	—
DEVIN_CLI_TIMEOUT	Per-turn ceiling	10m
DEVIN_CLI_SANDBOX	Pass --sandbox (research preview)	false
DEVIN_CLI_EXTRA_ARGS	Extra CLI args escape hatch	—

All exposed in /config providers.

Limitations (honest ones)

• No token/cost reporting — the CLI doesn’t expose usage, so the cost tracker records zero (cost lives in the Cognition subscription; the pricing layer never bills a routed claude-*/gpt-* model as if it were the direct API).
• Spawn latency — each turn pays a subprocess start plus Devin’s harness overhead. If that matters for heavy coder use, an ACP-based persistent transport (devin acp) is the natural evolution.
• Vision doesn’t pass through — the transport is flat text; image attachments never reach the backing model.

See also

• Supported Models — the DEVIN tab
• Environment Variables
• MCP Server — combine both: expose ChatCLI over MCP and route agent_task to provider: "DEVIN"