FuXi: a provider-agnostic terminal coding agent in one Go binary

What FuXi is for, and who it is actually aimed at

FuXi targets a specific annoyance: coding agents that lock you to one model vendor or one hosted service. The README describes it as "a fast, self-contained terminal AI coding agent" and positions it as "a provider-agnostic alternative to Claude Code: bring any OpenAI-compatible model and get an agentic Think, Act, Verify loop on top of it." The audience is developers who already pay for model access, want the agent to run against their real working tree, and prefer a terminal over an IDE panel.

The scope is deliberately broad. The README lists 50+ built-in tools in a single binary: file read, write and edit, shell through bash or PowerShell, ripgrep search, web fetch, LSP diagnostics, Jupyter, browser use, background tasks, and parallel sub-agents. That tool count is the interesting part of the pitch, because it means the agent can act on a repository rather than only discuss it. The counterweight is that a large tool surface also means a large permission surface, which is why the project pairs it with an AST safety classifier and audit logging.

One detail worth reading carefully: the README claims the loop and routing "let any OpenAPI-compatible model perform above its raw benchmark." That is a strong claim, and the project itself qualifies it later by saying it ships no published score on SWE-bench, Terminal-Bench, or the Aider polyglot benchmark. Treat the elevation claim as a hypothesis you can test on your own tasks, not as a settled result.

The Think, Act, Verify loop and cost-aware routing

The mechanism visible in the repository is a three-stage loop. Think produces a plan, Act executes tools against your filesystem and shell, Verify checks the result. The README points to docs/loop.png for the diagram and benchmark/REPORT.md for the methodology behind the head-to-head comparison. What the README text does not spell out is how the verifier decides a task is done, or what happens when verification fails repeatedly. That detail presumably lives in docs/usage.md, which is linked but not reproduced.

Routing is the second mechanism. FuXi accepts an OpenAI-compatible endpoint, Gemini, or Bedrock and Vertex, plus an OAuth sign-in path. Cost-aware routing plus automatic failover means the agent can move between providers when one errors or when a cheaper model is adequate for a step. This is the feature that justifies the "vehicle" metaphor in the README: the model is the engine, FuXi decides which engine to use.

Durability is handled at the session layer. Transcripts persist to disk, checkpoints allow resume, rollback, or fork, long conversations auto-compact to save tokens, and an idle "dreaming" process consolidates memory across sessions. The rollback behaviour is described in the README highlights but not walked through step by step, so confirm the exact command in docs/usage.md before you rely on it to undo an agent edit.

Safety runs before execution rather than after. Shell commands pass an AST safety classifier, and the project pairs that with fine-grained permissions and audit logging. An AST check is a meaningfully different approach from a regex denylist, because it can reason about a parsed command rather than matching strings. It is still a classifier, so it can be wrong in both directions, and the README does not publish false-positive or false-negative rates.

Installing FuXi and getting to a first real task

The README gives one-line installers for three platforms. On macOS and Linux the shell installer is the documented path, and the same command upgrades an existing install in place:

curl -fsSL https://fuxicode.com/install.sh | bash

On Windows the PowerShell equivalent is:

irm https://fuxicode.com/install.ps1 | iex

Both install to ~/.local/bin (~/.local/bin equivalent under %USERPROFILE% on Windows) and add that directory to your user PATH if it is missing. If you prefer to pin a version rather than take the latest, the README shows an argument form, for example ./bootstrap.sh 0.1.2.

After installing, verify the environment before running any agent task. The README documents two commands for this, and the second is the one that catches most setup mistakes:

fuxi --version
fuxi doctor

fuxi doctor checks config, API key, git, and ripgrep, so a clean run tells you the prerequisites the agent depends on are present. The README also mentions fuxi verify to confirm the provider connection, which is the check to run when doctor passes but model calls still fail.

With the environment clean, launch the TUI and start with a task you can score yourself:

fuxi

The README's own evaluation advice is to pick a failing test in one of your projects, have FuXi fix it, then extend the module and re-run the suite. Inside the TUI, /cost, /usage, /context, and /status expose what the session is spending and how much context remains. Uninstalling is a file removal plus an optional state directory: rm -f "$HOME/.local/bin/fuxi" and rm -rf "$HOME/.fuxi" on macOS or Linux.

Where FuXi is the wrong tool

The licence is the first hard boundary. The README's badge reads Proprietary, and the repository's LICENSE file carries no standard SPDX identifier, which is why the licence shows as NOASSERTION. The README simultaneously says "no license cost for individuals, teams, or enterprises" and "Free forever." Free of charge and open source are different things, and a proprietary agent that edits your source tree and runs shell commands is a different risk profile from an MIT-licensed one. If your organisation requires an OSI-approved licence or a legal review before a tool touches production code, FuXi does not clear that bar as documented. Read LICENSE yourself; nothing here is legal advice.

The second boundary is evidence. The project states plainly that it ships without a published score on SWE-bench, Terminal-Bench, or the Aider polyglot benchmark, and it calls its own head-to-head comparison "a small, self-run task set, not a third-party benchmark." That candour is to the project's credit, but it means you cannot use the benchmark to decide. You have to run your own tasks, which costs time.

The third boundary is the classifier. An AST safety check on shell commands is a real constraint on autonomous work. If your workflow depends on unusual shell invocations, generated scripts, or commands the classifier cannot parse, you will hit blocks. The README documents the classifier's existence but not its rules, so the only way to learn its edges is to run fuxi doctor and then exercise your own commands.

Finally, if you want a managed service with a hosted backend and no local binary, FuXi is the wrong shape. It is terminal-first and self-contained by design.

FuXi against Claude Code and other terminal agents

The README names Claude Code directly as the comparison point, so the difference in approach is worth stating precisely. Claude Code is tied to Anthropic's models and its own client. FuXi is provider-agnostic: bring an OpenAI-compatible key, a Gemini key, or Bedrock and Vertex credentials, or sign in through FuXi OAuth. If your organisation has already negotiated pricing with a specific provider, or you want to switch models per task without switching tools, that difference is the whole argument.

The comparison cuts the other way too. A single-vendor agent can tune its prompts and tool schemas against one model family. FuXi has to work across many, and the README's answer to that is routing plus the Think, Act, Verify loop. Whether routing compensates for the lack of model-specific tuning is exactly what the project's own benchmark tries to measure, and the project admits that benchmark is self-run.

The README also carries a feature comparison table described as reflecting each product's publicly documented positioning as of mid-2026, with the caveat that details evolve quickly. That is a reasonable framing, but a positioning table is marketing-adjacent material, not a test result. The measured head-to-head image and benchmark/REPORT.md are the parts worth reading, including the stated limitations section.

One more differentiator worth noting: FuXi is a single static Go binary with no runtime dependencies, and it self-updates. fuxi update replaces the running binary after checksum verification. Agents distributed as Node or Python packages carry a runtime and a dependency tree; FuXi does not.

Maintenance, upgrades, and what the licence costs you

The repository is not archived, and the last push was on 2026-09-07, the same day as the 0.1.6 release. The three releases listed for the project span 2026-08-05 (0.1.1), 2026-08-06 (0.1.2), and 2026-09-07 (0.1.6), so the project is moving on a roughly monthly cadence with patch releases between. That is a young version line: 0.1.x means interfaces can still change.

Upgrade cost is low by design. The README says the install command doubles as the upgrade command and that running it again upgrades in place, and the binary self-updates through fuxi update with checksum verification before replacement. The practical cost is therefore not installation effort but revalidation: after an upgrade, re-run fuxi doctor and fuxi verify, because a 0.1.x bump can change config keys or provider handling. The CHANGELOG.md at the repository root is the place to check before upgrading a working setup.

On licence: the badge says Proprietary, the LICENSE file has no recognised SPDX identifier, and the README promises no licence cost for individuals, teams, or enterprises. Those statements can all be true at once, but they answer different questions. Zero cost is not the same as permissive terms, and the README does not summarise redistribution, modification, or commercial-use rights. If you plan to vendor FuXi into a product or ship it inside a corporate image, read LICENSE and get your own legal review. Nothing in the repository establishes those rights either way.

Editorial conclusion

Adopt FuXi if you want a provider-agnostic agent loop in a terminal and are willing to bring your own API key, accept a Proprietary licence, and evaluate it on your own failing tests rather than on published scores. Skip it if you need an OSI-approved licence, a managed cloud service, or third-party benchmark evidence before you commit. Verify three things first: the exact licence text in LICENSE, whether your provider is reachable through fuxi verify, and whether the AST safety classifier blocks the shell commands your workflow depends on.

Frequently asked questions

Official sources

1. fuxicodex/Fuxi on GitHub
2. Issues
3. Project website
4. README
5. Releases