Feature tables are a bad way to choose a developer tool. Every row is a checkmark, the rows are chosen by whoever built the table, and none of them tell you how the thing feels on the third day.
Here are five questions that actually narrow the field. Work through them in order and most of the market eliminates itself.
1. Where is your code allowed to go?
Answer this first, because it is a constraint rather than a preference and it removes more options than anything else.
If you work somewhere with a policy about which infrastructure source code may touch, every hosted tool is out regardless of how good it is. That is not a judgement about those products. It is a contract.
- Anything is fine: the whole market is open.
- Approved vendors only: you need a tool that talks directly to a provider you have already cleared, with nothing in between.
- Nothing leaves the machine: you need a tool that can point at a local model. That is a very short list.
Local-first CLI tools such as Vexi and OpenCode cover the second and third cases, because the only network destination is the endpoint you configure. Vexi will take a raw endpoint URL, so a local Ollama or LM Studio server works the same way a cloud provider does.
2. Editor or terminal?
This is mostly temperament, and neither answer is more serious than the other.
If you spend your day in an editor and want AI in the same window with inline diffs and completions, you want an editor-based tool. Cursor and the various VS Code extensions do this well, and no terminal tool will match them at it.
If your day already runs through a shell, a terminal agent removes a context switch rather than adding a window. It also inherits your environment for free: your compiler, your test runner, your git remote, your credentials.
Do not overthink this. Try one of each for an afternoon.
3. How likely are you to change models?
Six months ago the answer for most people was "never". It is now a live question, because the price and quality ranking changes frequently and several providers offer free tiers good enough for daily work.
If you expect to stay on one model indefinitely, a single-provider tool is fine and often better, since it can be tuned specifically for that model. Claude Code is the clear example.
If you expect to move, you want provider independence, and you want it to be a config change rather than a migration. Vexi detects the provider from the key format across 13 providers, so switching is pasting a different key. That flexibility costs a little polish per provider. It is a genuine tradeoff, not a free win.
4. What happens when the session ends?
The failure people underestimate is not a bad suggestion. It is re-explaining the project every morning.
Ask what a tool retains between sessions, and importantly, whether you can read and correct it. Memory you cannot inspect is memory you cannot fix, and a confidently wrong stored belief is worse than none, because it produces plausible work built on a false premise.
Vexi's approach is a compressed set of decisions stored as a readable file in the project, and it prints which decision it used when one informs an answer. Whatever tool you choose, prefer inspectable memory over the invisible kind.
5. What is the exit cost?
The question nobody asks during evaluation and everybody asks eighteen months later.
Consider what you lose if you stop. A subscription tool takes its history with it. A proprietary tool can change pricing, be discontinued, or drop the feature you built a workflow around, and you have no recourse. An open-source tool can be forked if it is abandoned, and its local files stay readable regardless.
This is not an argument that open source is always better. Commercial tools are often more polished, and paying a company that is accountable to you is sometimes exactly right. It is an argument for knowing the answer before you are invested.
Putting it together
The five answers usually point somewhere obvious:
- Editor person, code can go anywhere, staying on one model: use an editor-based tool.
- Terminal person, committed to one provider, want maximum polish: use that provider's own agent.
- Terminal person, want provider freedom and code staying local: an open-source CLI agent. Vexi and OpenCode both qualify.
- Hard constraint that nothing leaves the machine: a tool that accepts a local endpoint, which is a much shorter list than the marketing suggests.
If the last two describe you, Vexi installs in one command, costs nothing, works with free-tier keys, and uninstalls cleanly if it does not suit you.
npm install -g vexi-cli
vexiAnd if one of the other answers describes you, use the tool that fits. A coding agent you fight with is worse than no coding agent at all.