Skip to main content
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
  1. That’s it — ChatCLI registers the provider automatically when the binary resolves (from PATH, or DEVIN_CLI_PATH):
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.

​
Models

The catalog mirrors what the enterprise CLI serves (29 models): the claude-* line (sonnet-5, opus 4.5–4.8, haiku), gpt-5.x including the 5.6 tiers (sol/terra/luna), gemini-3.x, glm-5.2, kimi-k2.x, deepseek-v4-pro, and Cognition’s own swe-1.5…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.
  • 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

VariablePurposeDefault
DEVIN_MODELDefault modelclaude-sonnet-4.6
DEVIN_CLI_PATHExplicit binary pathdevin from PATH
DEVIN_CLI_PERMISSION_MODE--permission-mode passed to the CLIauto
DEVIN_CLI_AGENT_CONFIGDeclarative agent-config file (hardened tool lockdown)—
DEVIN_CLI_TIMEOUTPer-turn ceiling10m
DEVIN_CLI_SANDBOXPass --sandbox (research preview)false
DEVIN_CLI_EXTRA_ARGSExtra 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