CLI agent limitations
Driving a subscription CLI is often cheaper than metered API calls, but a CLI harness is not the same as calling a model directly. These are the real trade-offs, stated plainly.
Who runs the tools
With an API-key provider, Koryphaios owns the agent loop: the model proposes a tool call, and Koryphaios executes it — so every action passes through Koryphaios's permission prompts and the critic gate.
With a CLI harness, the CLI is itself a full agent that runs its own tools (edit, shell, search) internally. Koryphaios can't intercept each of those internal tool calls, so its per-command permission gating and critic don't sit in front of them. What Koryphaios enforces instead is orchestration: it blocks the CLI from spawning its own uncontrolled sub-agents (so all delegation goes through Kory's manager → workers → critic), it can disable web search, and — when a CLI is shared with someone else — it confines the whole CLI in an OS sandbox. This is the single most important thing to understand about CLI models.
Trade-offs common to most CLI harnesses
- Reconstructed telemetry. Because the CLI runs tools itself, Koryphaios reconstructs the tool feed from the CLI's own logs/telemetry. It's faithful but can lag the live edit slightly, and detail varies by CLI.
- Session isolation. Koryphaios runs each CLI in a dedicated home/socket/session id so its automated runs never commingle with your own interactive terminal sessions.
- Timeouts. A stuck CLI turn is killed after a fixed timeout so it can't hang a session.
- Terms of service. A subscription token may only be used through the vendor's own CLI. Koryphaios respects this by shelling out to the logged-in CLI and never holding the token — but it also means you can't freely share that subscription with others.
Per-provider specifics
| CLI | Reasoning | Vision | Notable limitation |
|---|---|---|---|
| Claude Code | Effort as a thinking-token budget | Yes (model-dependent) | Reasoning text is redacted by Anthropic — you see a thinking indicator and token count, not the words. |
| Codex | Per-model levels | Model-dependent | New models can be hidden if the pinned client version is stale (the backend gates models by minimum client version). |
| Grok | Only when the model advertises it | None — text only | Text-only: image attachments are dropped. Web search runs inside the CLI (can only be turned off, not inspected). |
| Cursor | Yes (real streamed reasoning) | Model-dependent | Requires a Cursor subscription; no tool events beyond what the CLI reports. |
| Devin | Baked into the model tier — no separate effort flag | Model-dependent | Fixed model set; cloud-backed, so turns depend on Cognition's service. |
| Cline | none / low / medium / high / xhigh | Model-dependent | BYO-key inside Cline — Koryphaios never holds the key, and can't meter spend the CLI manages. |
| Antigravity | No effort control | Model-dependent | Reasoning is scraped from a trajectory database as it runs — a fragile stream vs. a clean API. |
Why the reasoning picker appears and disappears
The reasoning-effort control is driven by what each model actually reports. Some models expose named levels (low/medium/high), some take a raw token budget, and some expose nothing — so the picker shows up for models that support it and hides for those that don't. That's intentional: it reflects real capability rather than pretending every model can reason on demand.
When to prefer an API key instead
Reach for an API-key provider when you want Koryphaios to own every tool call (tightest permission control and critic coverage), when you need vision on a text-only CLI like Grok, or when you want exact token accounting. Reach for a CLI when you'd rather pay a flat subscription than per token, and you're comfortable letting the CLI run its own tool loop.