Six months ago, you had Claude Code. Maybe Cursor if you wanted the IDE. That was the AI-assisted-coding stack.

Today, on a fresh laptop set up for serious work, you’ll install Claude Code (Anthropic’s official CLI), Codex (OpenAI’s), Grok CLI (xAI’s), Droid (Factory’s), OpenCode (the community-driven one), plus an open-source aider here and a Gemini CLI there. Each one is genuinely good at something the others aren’t. None of them is “the winner” yet — and nobody we’ve talked to thinks one will be.

So now your ~/.local/bin has six CLIs in it. Your ~/ has five top-level dotdirectories (~/.claude, ~/.codex, ~/.grok, ~/.droid, ~/.opencode) each acting as if it owns your machine. Your bashrc has a dozen aliases. Your account dashboards at Anthropic, OpenAI, xAI, and OpenRouter all show charges and you don’t know which project caused which.

This is the stack now. It’s not going away. And it needs an orchestration layer the way the JavaScript ecosystem needed npm.

What “one CLI per model” optimised for

The first wave of coding agents — and their wrappers — was right to ship as individual CLIs. They were optimised for the things they needed to prove:

  1. Standalone usefulness. A coding agent has to work without any other tool installed. If you can’t npm install -g claude && claude and have a useful conversation in 60 seconds, nobody will adopt it.
  2. Provider lock-in resistance. Each lab wanted their CLI to be the durable bit of the relationship. Anthropic doesn’t want Claude Code to look like a thin wrapper around OpenAI’s API.
  3. First-party feature velocity. Build a feature in your own CLI without coordinating with anyone. The pace was the point.

Those were the right priorities for 2024–2025. The CLIs got good. Tool calling got good. The agent loop got good.

But each one optimised for being the only CLI on the machine. None optimised for being one of five.

The signs the stack has changed

A few things shifted while we were watching individual CLIs get better:

Frontier model quality converged enough that no one model dominates every task. Claude Sonnet is best at long-context refactors. GPT-5 is best at certain reasoning tasks. Grok is fast and cheap for prototyping. Gemini is good at vision and at integrating with Google services. Nobody we know runs only one.

Provider keys multiplied. You have a personal Anthropic account and a work one. You also have OpenAI, OpenRouter, MiniMax, and probably a self-hosted gateway. Each agent CLI assumes one key per environment variable; managing five accounts on one machine is real work.

Cost became visible enough to matter. When the first lab raised prices, people started caring. Per-project cost visibility — “what did this engineering team spend on Claude in May?” — is now a normal request from FinOps. The CLIs don’t surface it.

Compliance teams started asking about agents. A coding agent that can write code can also write git push --force to main. Sandboxing, audit logs, and per-team policy aren’t optional for any organisation big enough to have a compliance team.

Multi-project work got harder, not easier. The more agents you use, the more profile state lives in your HOME directory, and the more those profile states get in each other’s way. We’ve all watched a project leak its Anthropic key into the wrong account via a stale env var.

The npm pattern

There’s a really clean analogue from a decade ago.

Around 2013, the JavaScript ecosystem looked like this: each library had its own install script. Each project depended on a different version of jQuery. Globally-installed packages collided with project-installed ones. People had bashrc tricks for switching node versions. The ecosystem was useful and growing — and there was no shared substrate.

Then npm matured. Not as a feature, but as a layer: a thing that owns the dependency graph for one project, and gets out of the way of everything else. nvm, yarn, pnpm, and now Bun built on that pattern. The model — a thin manifest plus a tool that respects per-project state — became how the ecosystem coordinated itself.

The AI coding agent ecosystem is at the same inflection point. Not because the agents need to share anything between each other (they don’t), but because the developer using them needs a way to manage the state of running them.

That layer is what Ringlet is. Profiles are the manifest. The CLI is the tool. The agent CLIs themselves don’t change.

What an orchestrator gives you that a wrapper doesn’t

People have been writing personal shell scripts to do parts of this for a while. Aliases, direnv rules, per-project .envrc files. They work, for a definition of “work.” Here’s what they don’t give you:

  • A canonical name for a context. “Run the Claude Code I use for client A’s repo, with their key, against their preferred provider” is a thing you can hand to a teammate’s setup script if it has a name. As a bashrc alias, it doesn’t.
  • Cost accounting that survives the alias. Token tracking has to read the actual events the provider streams back. A wrapper script doesn’t intercept stdout at the right layer.
  • Sandboxing. A bashrc alias still runs the agent as you. A real orchestrator can wrap the exec in bwrap or sandbox-exec so the agent can’t rm -rf outside the workspace it’s supposed to touch.
  • Remote sessions. Running an agent on a dev box and accessing the PTY from your laptop is not a one-line shell script. It needs a daemon, a token, and a WebSocket.
  • A web UI for people who want one. Some teammates want a dashboard. The CLI-only crowd can ignore it; the dashboard crowd shouldn’t have to fork.

These are the features a layer gives you that a script doesn’t. They’re what we built Ringlet to provide.

What an orchestrator doesn’t give you

It also doesn’t:

  • Replace the agent. Claude Code is still Claude Code. Codex is still Codex.
  • Replace the provider. You still bring an Anthropic / OpenAI / wherever key.
  • Replace the gateway. If you use LiteLLM or OpenRouter as your routing layer, great — Ringlet sits above them and points the agent at them.
  • Replace the editor. Ringlet doesn’t have opinions about Neovim vs Cursor.

The “agent stack in 2026” is more layers, not fewer. Ringlet is the one that owns the agent CLI’s environment.

What this looks like in 18 months

Predicting the agent ecosystem at any horizon longer than three months is hubris, but here’s the rough shape we think 2027 looks like:

  • Five to eight major coding agent CLIs, none dominant. Anthropic, OpenAI, xAI, Google, plus two or three credible open-source ones (Factory’s Droid is the front-runner, OpenCode is gaining).
  • Three to four major model providers in active use per developer. Anthropic + OpenAI is the floor; many developers will also use MiniMax or a self-hosted gateway.
  • Per-project credentials as the norm. The era of “one Anthropic key in your env” ends when teams start running multi-tenant projects with separate billing.
  • Audit and cost as table stakes. Compliance teams will require both. The agents themselves won’t ship this; the orchestration layer will.
  • A clear separation between the agent layer, the provider layer, and the orchestration layer. Each can ship independently.

That’s where we think Ringlet is. The agent layer is the agent vendors’ job. The provider layer is the model labs’ job. The orchestration layer is open-source’s job — like npm was, like git was, like Linux was.

Try it

If any of that resonates, the install takes a minute. Start with two profiles on the same agent (work and personal Anthropic accounts, say) and see if the friction-you-didn’t-realise-was-friction disappears.

If it doesn’t, file an issue. We’d rather not be one of five competing orchestrators in 2027. The pattern is the point — and we’ll happily borrow the better bits from whoever does it best.