Open CLI or vendor CLI? The honest trade-off table
Sooner or later every team on a vendor coding CLI asks why they are paying when open alternatives exist, and every team on an open CLI asks why the same model feels smarter inside the vendor's tool. Both questions have one answer, and it is not in the feature lists.
What you are actually choosing is who owns the tuning loop between model and harness. Everything else is downstream of that.
What the vendor buys you
Claude Code, Codex, and Gemini CLI are not neutral shells around an API. The system prompts, tool definitions, edit formats, and retry behavior are co-developed with the models they serve, and the labs have every incentive to train the next model against the harness's own agentic traces. The uncomfortable truth follows: the same model, driven through a generic harness, often performs noticeably worse than in its home tool. Tool calls that parse on the first try, edits that apply cleanly, sane recovery when a command fails. That is tuning, not luck.
You are also buying support, docs, a security team, and same-day compatibility when a new model ships. Whether the price of all that is fair is a separate argument, one I have made already in my case against flat subscriptions.
What open buys you
- Model freedom. Point Aider, OpenCode, Goose, or Crush at any provider, any router, or a local server. When something better or cheaper ships, you switch the same afternoon.
- Auditability. You can read the tool definitions and permission logic before granting shell access. With a closed agent you are trusting a changelog.
- Price control. Your keys, your routing, a local tier for bulk work. No seat pricing, no plan ceiling you did not choose.
- No rug-pulls. Vendors reprice, deprecate, and pivot. A fork survives all of it: Qwen Code is an entire product built on that guarantee.
Notice that none of those four are about capability. Open CLIs rarely beat vendor ones head-to-head on raw agentic performance with the same frontier model; they win on the constraints around the work.
You are choosing who owns the tuning loop between model and harness — the vendor, or you.
The table
| Dimension | Vendor CLI | Open CLI |
|---|---|---|
| Harness-model fit | Co-tuned, strong | Generic, varies by model |
| Model choice | One family | Anything with an endpoint |
| Cost | Vendor-set plans | Your keys, your router, local tier |
| Auditability | Partial at best | Full source |
| Longevity | Roadmap risk | Forkable forever |
| Support | Product team | Community, uneven |
One row needs an asterisk: Gemini CLI sits in both columns (Apache-2.0, with a product team behind it), which is exactly why it became the harness other labs fork. The categories blur at the edges, and the blur is the most interesting part of the open CLI map.
The honest failure modes
Open CLIs fail by making you the integrator. Harness updates lag model releases, tool-call formats break on provider quirks, and when something goes wrong at 2 a.m. the support channel is a GitHub issue. Vendor CLIs fail by owning you: pricing changes you absorb, deprecations you re-plan around, and a privileged process on your machine whose behavior you cannot fully inspect.
My decision rule, consistent with the broader comparison: if your work leans on long autonomous chains where harness-model fit dominates outcomes, pay the vendor. The tuning is worth real money. If your binding constraints are cost, privacy, or not being repriced mid-quarter, go open and accept the integration tax with open eyes.
Most serious teams I know quietly land on both: a vendor CLI for the hard agentic work, an open CLI on cheap or local models for the bulk. That is reading the table correctly, not indecision, and it means refusing to pretend one column dominates the other everywhere.