Open Source Should be Non-Negotiable in the Agentic CLI
Here's why.
The terminal is one of the most personal software interfaces for a developer. It’s where the dotfiles live, the aliases nobody else would understand, the muscle memory for whatever weird Git workflow you settled on five jobs ago. It’s also, increasingly, where the AI lives. Claude Code, Codex CLI, Antigravity CLI, Aider, OpenCode, Kilo CLI - the terminal has become one of the most interesting venues for AI coding agents in 2026, and it’s where a lot of real engineering work is now happening.
That makes the design choices behind these tools worth thinking about carefully, because the terminal is where developer workflows ossify. CLI agents end up wired into shell aliases, CI pipelines, pre-commit hooks, dotfiles, custom plugins, MCP servers, internal skill libraries, and the actual scripts your team runs to ship code. The surface area of a CLI migration can be much larger than swapping an IDE. That makes one design choice more important than any other: whether the agent is open source.
This isn’t a stylistic preference or a tribal allegiance. It’s a structural argument about what your workflow is exposed to when the vendor changes its mind.
What “open” actually has to mean
The word gets used loosely. There are four layers in a modern AI CLI, and a tool can be open at one and locked at the others.
The first is the source code of the agent itself - the harness that orchestrates tool calls, manages context, and talks to the model.
The second is the model choice.
The third is the inference endpoint that runs the model.
The fourth is the pricing structure around that endpoint.
A CLI that is open at all four layers is one where the worst thing a vendor can do to you is stop maintaining the tool. You can fork it, point it at a different model, hit a different endpoint, and keep going. A CLI that’s open at the harness layer but locked to a single proprietary endpoint looks open, but isn’t.
That distinction has stopped being academic.
Example: The Gemini CLI
The cleanest recent illustration is Gemini CLI. It launched in June 2025 under Apache 2.0 and by any reasonable measure was a successful open source project. Google’s own transition announcement cited over 100,000 GitHub stars, 6,000 merged pull requests, and hundreds of contributors as evidence of community traction.
On May 19, 2026, at Google I/O, Google announced that Gemini CLI is being transitioned to Antigravity CLI, and that for users on free, Google AI Pro, or Ultra tiers, Gemini CLI stops serving requests on June 18, 2026. Enterprise users on Gemini Code Assist Standard or Enterprise are exempted. The successor, Antigravity CLI, has not been published as open source as of writing, and an issue on the gemini-cli repo asking that question directly remains unanswered.
The reason this matters isn’t that Google did something uniquely wrong. They’re entitled to run their roadmap however they choose. It matters because it cleanly proves the four-layer point. Gemini CLI’s harness was open. Contributors could fork it, audit it, submit PRs. But the model and the inference endpoint were Google’s, and when Google decided to change the access terms, the open license on the harness gave the community almost nothing to work with. Google’s move effectively removed only the open-source part of the equation - not by switching the license, but by switching off the infrastructure that made the tool useful to anyone who wasn’t paying.
That’s the structural lesson. “Open source” at the harness layer is necessary but not sufficient. If the model choice and the endpoint are closed, the openness of the harness is decorative.
Why the CLI is where this hits hardest
A CLI agent gets woven through your shell config, your CI, your team’s runbook scripts, your custom skills, your MCP servers, your prompt patterns, and the small dotfile rituals that don’t show up in any documentation. When the vendor changes the terms - sunsets the tool, raises prices, drops a config flag your CI depends on, ships a closed successor with a thinner free tier - you don’t migrate a setting. You migrate a workflow.
This is where the trust numbers start mattering. Stack Overflow’s 2025 Developer Survey of 49,000+ respondents found that 84% of developers use or plan to use AI tools, up from 76% in 2024, but trust in AI accuracy fell to 29% from 40% in prior years.
Sonar’s State of Code 2026 survey of over 1,100 developers found that 61% agree AI often produces code that looks correct but isn’t reliable, and the same percentage say it takes a lot of effort to get good output. Adoption is climbing. Trust is falling. That’s the gap where lock-in does the most damage, because developers are increasingly dependent on tools they increasingly don’t believe.
When the tool is unreliable, the ability to see what it’s doing and swap what’s behind it stops being a nice-to-have. It becomes part of the engineering process.
Lock-in is the shadow story of 2026
The Pragmatic Engineer’s 2026 AI tooling survey of 906 software engineers found a pattern across responses: heavily subsidized enterprise plans that come with vendor lock-in, with multiple responses raising concerns about what happens when the subsidies run dry. Experienced engineering leaders in that survey recalled that cloud providers played the same game a decade ago - subsidizing for a few years, then raising prices once customers were fully locked in. The same playbook is being run on the AI coding tools your team is adopting right now.
This is the actual mechanic of lock-in in 2026. It isn’t a license agreement. It’s the fact that the agent is open source but the brain it talks to isn’t, and the pricing on the brain isn’t, and the endpoint serving the brain isn’t. Open at one layer, closed at three, marketed as open.
What this looks like in practice
The honest version of “open” in a CLI is simple. It is the ability to:
Read the source code of the agent that is touching your code.
Pick the model that runs the task, and switch it without rewriting your workflow.
Pay for usage at the rate that model providers set, with no markup in the middle.
Move your sessions, configs, skills, and MCP servers somewhere else if the vendor changes the terms.
Fork the project if the maintainer disappears, gets acquired, or pivots into a closed successor.
This is what Kilo CLI is built around. It’s part of the same agentic engineering platform that runs in VS Code and JetBrains, with the same Code, Ask, Debug, and Plan modes, and the same Kilo Gateway giving access to 500+ models at zero markup. The source is open. The model selection is open. The pricing is per-token at the provider’s cost. If a better model ships next week, you switch. If Kilo ships something you don’t like next month, the source is there and the config is yours.
The terminal has been a strong example of open infrastructure for thirty years. There’s no reason the AI layer on top of it has to break that pattern, and there’s no good reason for developers to accept tools that quietly do.
Open source in the agentic CLI isn’t a feature. It’s the floor.