Every year brings a fresh wave of coding-agent CLIs, each one certain it's about to become the default. We stopped trying to guess which one that would be. Influxx's answer to the fastest-moving, least-settled corner of developer tooling is to support essentially all of it — more than 30 named agent CLIs today, from the tools every developer already knows to ones most haven't tried yet — under one standing rule: if it runs in a terminal, it runs in Influxx. That rule is expensive to keep. We keep it anyway.
A Market That Refuses to Settle
Look at the last two years of coding-agent releases and the thing that stands out isn't which CLI won. It's that nothing has consolidated. Established players keep shipping major updates, well-capitalized challengers keep launching, and small teams keep open-sourcing agents that do one workflow well enough to build a following. Nobody has a monopoly on developer trust, and nothing about the current pace suggests that's about to change.
Influxx's supported roster reflects that reality rather than fighting it. Today it includes:
- The names most developers already run: Claude Code, Codex, Grok, Cursor, GitHub Copilot, and OpenCode.
- The fast-growing challengers: Amp, Droid, Cline, Goose, Devin, Auggie, Kiro, Kimi, and Continue.
- Specialists and newer entrants: MiMo Code, OpenClaude, Antigravity, Pi and oh-my-pi, Hermes Agent, Autohand Code, Charm's Crush, Codebuff, Command Code, Kilocode, Mistral Vibe, Qwen Code, and Rovo Dev.
- Whatever comes next: a general "any CLI agent" path, for the ones that aren't on the named list yet — because there's always one that isn't.
That last line matters more than it might read at first. A roster is a snapshot; the market underneath it isn't holding still long enough for any snapshot to stay accurate for very long.
Why Not Just Bet on the Agent That Wins?
The obvious counter-argument is that all of this is unnecessary work. Pick the best agent, integrate deeply with just that one CLI, build one polished experience around it, and let the rest of the market sort itself out. Plenty of tools in this space have made exactly that bet.
We think that's the riskier move, not the safer one. Coding-agent CLIs are a young, heavily funded, intensely competitive category, and nothing in how it has evolved suggests it's converging toward one interface or one winning vendor. Betting a product's future on a single CLI becoming the default is betting on a specific horse in a race that keeps adding horses.
"We stopped waiting for this market to settle down. It might never settle down, and if we'd built Influxx as though one agent were about to become everyone's default, we'd be rebuilding it the day that assumption broke. We'd rather be the place developers land no matter which agent they're running this week, or which one they switch to next month."
— Wes Calder, Co-founder & CEO at ETAPX
Treating Fragmentation as a Feature, Not a Phase
That framing changes what Influxx is actually optimizing for. We're not trying to build the best possible experience around one agent's particular strengths — we're building the cockpit those strengths sit inside: one sidebar, one tab strip, notes and agents living together, regardless of which CLI is doing the work in any given tab. A developer running Claude Code on one project and switching to Cursor's CLI on the next isn't switching tools. They're switching tabs.
What "Supporting" an Agent Actually Means
Adding an agent to Influxx isn't a matter of pointing at an executable and hoping for the best. Underneath the cockpit sits a universal agent registry, and every supported CLI is its own entry in it — a specific, deliberate description of how that tool behaves, because no two of them behave the same way.
Four Questions Every Adapter Has to Answer
For each agent, that registry entry has to answer the same four questions, on that agent's own terms:
- Is it even installed? Detection logic that can tell whether a given CLI is present on this machine before Influxx tries to launch it.
- How does it start? The exact launch sequence — binary, working directory, environment — needed to bring the agent up cleanly inside its own isolated git worktree.
- What does "running" look like? A process fingerprint Influxx can recognize later, so it can tell a live session apart from one that has already exited.
- How does it take its first instruction? This is the one that varies the most from agent to agent. Some take an initial prompt as a plain argument at launch. Some need it passed behind a dedicated flag instead. Some won't accept it at start-up at all — Influxx has to wait for the process to come up, then type the prompt into the running session the way a person would. A few need their own interactive-mode handling entirely, because they don't expose a clean non-interactive path in the first place.
Then there's onboarding. Several agent CLIs greet a new folder with a dialog of their own — some version of "do you trust this directory?" is the most common shape — and left alone, that dialog just sits there waiting for a keypress, blocking automation before the agent ever gets to work. Influxx has to recognize each one's particular flavor of first-run friction and clear it, agent by agent, before a session can start unattended.
"There's no shortcut for the prompt-handoff problem. We looked for one early on — some clever middle layer that would normalize 'give this agent its first instruction' into a single call. It doesn't exist, because the vendors never agreed it needed to. So we write the difference down for each one, individually, and move on to the next agent."
— Amara Okafor, Head of Developer Experience at ETAPX
The Maintenance Bill We Chose to Carry
None of this is a one-time cost. The registry isn't an abstraction we built once and then left alone — it's a living surface that grows every time a new agent CLI shows up with enough traction to matter, and the pace of new entrants hasn't slowed since we started tracking it. Each addition means a new adapter, verified against that CLI's actual behavior, with its own quirks handled on their own terms instead of forced into a shape that fits the others.
That's a genuine trade-off, not a footnote. Every hour spent writing and testing an adapter for the next agent is an hour not spent somewhere else, and there's no version of this roster that gets to "done." We accept that bill on purpose, because the other option — telling a developer we don't support their agent and to check back later — is the one cost we're not willing to pass on to them.
Beyond Launching: Knowing What an Agent Is Actually Doing
Launching an agent is, relatively speaking, the easier half of this problem. The harder half is what happens after: Influxx's cockpit shows a live status for each running agent — working, idle, waiting on you — so a developer running four or five agents across four or five worktrees isn't stuck clicking into every tab just to find out which one finished and which one is stuck. Building that status layer meant reaching into each CLI's own extensibility system and installing lifecycle hooks that report back when an agent starts a turn, finishes one, or needs input.
The catch is that "each CLI's own extensibility system" isn't one thing to integrate with. It's more than a dozen different things, because no two agent vendors built their plugin architecture the same way:
- Some read a JSON hook configuration that Influxx generates and writes in place, following that CLI's documented schema.
- Some expect a YAML plugin, registered through whatever plugin-loading convention that CLI uses.
- Some require an entire small plugin file, written directly into that CLI's own plugin directory, in whatever format that particular tool expects.
- One offers no library support for its configuration format at all, which means Influxx can't just generate a fresh file. It has to open the developer's existing config, find the specific section it owns, edit only that section, and leave everything else the developer already wrote completely untouched.
That last case is the clearest illustration of the whole bet: there was no shared abstraction available to reach for, so we wrote the one-off integration for that one vendor, and moved on to the next.
"I run Claude Code against the backend service and Cursor's CLI against the frontend repo, in worktrees sitting right next to each other in the same window. I've never had to explain to Influxx which one I'm using on which tab — it just shows me both, with both statuses, and I switch agents faster than I switch browser tabs."
— Liam Voss, platform engineer at a logistics startup and Influxx user
Frequently Asked Questions
Does Influxx push a default or recommended agent?
No. The cockpit — sidebar, tab strip, notes, worktrees — is the constant; the agent inside any given tab is your choice. Our positioning has always been bring your own CLI, or use managed chat when you want credits. Neither path is treated as the "real" one.
What happens if I want to use an agent that isn't on the named list?
Influxx includes a general "any CLI agent" path built specifically for that case. It won't have a purpose-built adapter with all the detection and status niceties a named entry gets, but if it runs in a terminal, you can bring it into a tab and run it inside its own worktree like anything else.
Does every supported agent show the same live status detail?
Every agent you launch gets its own tab and its own isolated worktree. For the CLIs where we've built the full lifecycle-hook integration — more than a dozen so far — Influxx also shows live state pulled directly from that agent's own extensibility system: working, idle, or waiting on you.
How does Influxx get past an agent's own onboarding prompts?
Several CLIs show a first-run dialog of their own, often some version of "do you trust this folder?" We handle each one specifically, so a fresh agent session doesn't stall on a prompt that only a human was expected to see.
Doesn't supporting this many CLIs mean a lowest-common-denominator experience?
It's the opposite, by design. Because each adapter is written against a specific agent's actual behavior instead of a flattened abstraction, an agent's own strengths and quirks come through rather than getting sanded down to fit a generic mold.
Can I run different agents side by side on the same codebase?
Yes — that's the core layout. Each agent runs in its own isolated git worktree, in its own tab, in the same sidebar. You can have Claude Code and Codex working on different parts of the same repository at the same time without either one stepping on the other's changes.
The bet underneath all of this is simple: the agent a developer prefers today probably isn't the one they'll prefer in a year, and we'd rather build for that certainty than against it. Every adapter, every plugin shim, every onboarding workaround is the price of a cockpit that doesn't ask anyone to pick a side. We keep paying it because the alternative is choosing a horse in a race that keeps adding horses.
