FuXi: Terminal-Agent mit Provider-Routing und Go-Binary

Welches Problem FuXi löst und für wen es gebaut ist

Ein Sprachmodell beantwortet Fragen. Es liest keine Dateien, führt keine Tests aus und merkt nicht, wenn sein Patch die Suite zerlegt. FuXi setzt genau an dieser Lücke an: Der Agent liest Code, bearbeitet Dateien, führt Shell-Befehle aus und bedient Werkzeuge über eine TUI. Das README formuliert die Rollenverteilung als Satz: "The model is the engine. FuXi is the vehicle." Das Modell bleibt der Motor, FuXi übernimmt die Karosserie.

Die Zielgruppe ist eng umrissen. Wer im Terminal arbeitet, sein eigenes Modell oder seinen eigenen API-Schlüssel mitbringt und keinen Anbieterwechsel im Workflow will, ist der adressierte Fall. Das README nennt FuXi eine "provider-agnostic alternative to Claude Code". Wer dagegen eine grafische Oberfläche, tiefe IDE-Integration oder einen Anbieter mit Garantien sucht, gehört nicht dazu.

Bemerkenswert ist die Kostenfrage. Routing über mehrere Anbieter mit automatischem Failover ist kein Komfortmerkmal, sondern der eigentliche Grund, warum jemand einen Agenten mit eigenem Schlüssel betreibt. Ob das Routing in der Praxis günstiger ist, lässt sich aus dem Material nicht belegen. Es ist eine Designzusage, keine Messung.

Der Think-Act-Verify-Zyklus und was daran belegbar ist

Das README beschreibt die Kernschleife als Think, Act, Verify. Der Agent denkt also, handelt am realen Repository und prüft das Ergebnis, bevor er weitermacht. Die Architekturdiagramme liegen als docs/architecture.png, docs/loop.png und docs/routing.png im Repository, sind im Text aber nicht erläutert. Wer die Schleife im Detail verstehen will, muss die Bilder selbst ansehen. Eine schriftliche Spezifikation fehlt im vorliegenden Material.

Konkret greifbar wird die Mechanik an einer anderen Stelle: Shell-Befehle durchlaufen vor der Ausführung einen AST-Sicherheitsklassifikator. Das ist mehr als eine Erlaubnisliste. Ein Parser liest den Befehl und stuft ihn ein, bevor die Shell ihn sieht. Dazu kommen feingranulare Berechtigungen und Audit-Logging. Für autonome Läufe ist das der Unterschied zwischen einem Werkzeug, das man unbeaufsichtigt laufen lässt, und einem, das man permanent beobachtet.

Der zweite Mechanismus ist die Persistenz. Transkripte landen auf der Platte, Checkpoints erlauben Fortsetzen, Zurückrollen oder Abzweigen. Ein Leerlaufmodus, im README "dreaming" genannt, konsolidiert Erinnerungen über Sitzungen hinweg. Lange Unterhaltungen werden automatisch komprimiert, um Tokens zu sparen. Das sind vier verschiedene Speicherstufen, und das Material erklärt keine davon im Detail. Man kann daraus schließen, dass der Zustand nicht nur im RAM lebt, aber nicht, wie ein Rollback technisch aussieht.

Installation in drei Befehlen und zwei Prüfschritten

Der Installationsweg ist kurz und plattformabhängig dokumentiert. Unter macOS und Linux:

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

Unter Windows in PowerShell:

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

Für die CMD gibt es ein eigenes Skript, das nach %TEMP%\fuxi-install.cmd geladen und ausgeführt wird. Alle drei Wege installieren nach ~/.local/bin, unter Windows nach %USERPROFILE%\.local\bin, und ergänzen den Benutzer-PATH, falls nötig. Derselbe Befehl dient später als Upgrade, was die Wartung vereinfacht. Eine bestimmte Version lässt sich mit einem Argument festnageln, das README nennt ./bootstrap.sh 0.1.2 beziehungsweise ./bootstrap.ps1 0.1.2.

Nach der Installation folgen zwei Prüfungen. fuxi --version zeigt die Version. fuxi doctor prüft die Umgebung: Konfiguration, API-Schlüssel, git, ripgrep. fuxi verify bestätigt die Verbindung zum Anbieter. Wer einen Agenten ohne Fremdbenchmark bewertet, sollte diese beiden Befehle als erste Messlatte nehmen, weil sie Umgebungsfehler von Agentenfehlern trennen.

Das Entfernen ist ein Dateilöschen. rm -f "$HOME/.local/bin/fuxi" und optional rm -rf "$HOME/.fuxi" für Konfiguration und Zustand. Keine Paketdatenbank, kein Daemon, keine Registrierungseinträge. Das ist der Vorteil einer statischen Binary und gleichzeitig der Grund, warum es keinen zentralen Update-Mechanismus außer fuxi update gibt.

Selbstverwaltung, MCP und der Preis der Erweiterbarkeit

FuXi aktualisiert sich selbst. Ein Hintergrundprozess prüft die Version, fuxi update ersetzt die laufende Binary, und vorher wird eine Checksumme verifiziert. Dass ein Agent die eigene Binärdatei überschreibt, ist ein bewusster Kompromiss: Bequem, aber es bedeutet auch, dass die Version, die ihr gestern geprüft habt, morgen nicht mehr dieselbe sein muss. In Umgebungen mit reproduzierbaren Builds ist das ein Problem, das man mit einem gepinnten Installationsargument entschärfen kann.

Als MCP-Client bindet FuXi externe Werkzeuge an. Dazu kommen Hooks, Skills, Plugins und Slash-Befehle, laut README alle hot-reloadable. Das ist die Erweiterungsschicht, und sie ist zugleich die größte Angriffsfläche. Ein hot-reloadbares Plugin, das Shell-Befehle absetzt, umgeht möglicherweise die Pfade, die der AST-Klassifikator absichert. Das Material sagt dazu nichts. Wer Plugins einsetzt, sollte diese Frage selbst beantworten, bevor er den Agenten unbeaufsichtigt laufen lässt.

Die Anbieterliste umfasst OpenAI-kompatible Endpunkte, Gemini sowie Bedrock und Vertex. Zusätzlich gibt es einen OAuth-Login. Damit ist die Aussage "bring your own key" nicht nur Marketing, sondern deckt mehrere Authentifizierungswege ab. Ob das Routing Anbieter nach Preis, Latenz oder Fehlerrate priorisiert, bleibt offen. Das README nennt es "cost-aware" und "intelligent", ohne die Entscheidungsregel zu nennen.

Was die Benchmarkzahlen nicht hergeben

FuXi veröffentlicht keinen Score auf SWE-bench, Terminal-Bench oder dem Aider-Polyglot-Benchmark. Das README sagt das selbst und begründet es mit einer Vorliebe für reproduzierbare, selbst überprüfbare Evaluation. Stattdessen gibt es einen selbst gefahrenen Vergleich gegen Claude Code, dokumentiert in benchmark/REPORT.md, über 15 Mikro-Dimensionen und 4 Großprojekt-Dimensionen, mit pytest und Coverage als Scorer.

Das README nennt die Grenze dieses Vergleichs ausdrücklich: ein kleiner, selbst gefahrener Aufgabensatz, kein Fremdbenchmark, und gemessen wird die Agentenschleife, nicht die Rohleistung des Modells. Genau so sollte man die Zahlen lesen. Ein Vergleich, bei dem beide Systeme durch ihre eigenen nativen Clients gesteuert werden, misst das Gespann aus Modell, Client und Schleife. Welcher Anteil auf FuXi entfällt, lässt sich daraus nicht ableiten.

Die Aussage, der Agent hebe "any OpenAPI-compatible model" über seinen Rohbenchmark, stammt aus dem README und ist eine Behauptung des Projekts. Die verlinkte Grafik docs/elevation.png liegt vor, die zugrunde liegende Messung ist im vorliegenden Material nicht ausgewertet. Wer die Zahl braucht, muss benchmark/REPORT.md selbst lesen und die Umgebungsversionen prüfen.

Die Lizenzangabe ist der harte Blocker

Die Lizenz ist als NOASSERTION gemeldet, das heißt, die automatische Erkennung konnte sie nicht einordnen. Das README zeigt ein Badge mit der Aufschrift "Proprietary", verlinkt auf die Datei LICENSE, und behauptet im selben Dokument "Free forever" sowie "no license cost for individuals, teams, or enterprises". Diese beiden Aussagen stehen nebeneinander und widersprechen sich nicht zwangsläufig, aber sie klären nichts. Kostenfreiheit ist nicht dasselbe wie eine Open-Source-Lizenz.

Für die Adoption ist das der wichtigste offene Punkt. Wer den Agenten in einem Unternehmen einsetzt, in dem eingehende Software rechtlich geprüft wird, braucht die tatsächlichen Bedingungen: Weitergaberechte, Haftungsausschlüsse, ob eine kommerzielle Nutzung erlaubt ist, ob Änderungen offengelegt werden müssen. Das README und die Repository-Metadaten beantworten keine dieser Fragen. Ich gebe hier keine Rechtsberatung, sondern nur den Hinweis, dass die LICENSE-Datei vor jedem produktiven Einsatz gelesen werden muss.

Erschwerend kommt die Versionierung hinzu. Die letzten Releases sind 0.1.6 vom 7. September 2026, 0.1.2 vom 6. August 2026 und 0.1.1 vom 5. August 2026. Das ist eine 0.x-Reihe mit kurzen Abständen. Schnelle Releases in einer frühen Version bedeuten bewegliche Schnittstellen. Konfigurationsschlüssel, Plugin-Format und Slash-Befehle können sich zwischen 0.1.2 und 0.1.6 geändert haben. Ein Upgrade ist hier kein Routinevorgang.

Wann ein anderer Ansatz die bessere Wahl ist

Der naheliegende Vergleich ist Claude Code, und das README zieht ihn selbst. Der Unterschied liegt nicht in der Funktion, sondern in der Bindung. Claude Code arbeitet mit einem Anbieter und dessen Modellen. FuXi arbeitet mit jedem OpenAI-kompatiblen Endpunkt und schaltet bei Ausfällen um. Wer bereits im Anthropic-Ökosystem ist und die Modellqualität nicht wechseln will, gewinnt durch FuXi wenig. Wer ohnehin mehrere Anbieter parallel betreibt, gewinnt die Routing-Schicht.

Ein zweiter Unterschied ist das Verteilungsmodell. FuXi ist eine statische Go-Binary ohne Laufzeitabhängigkeiten. Das ist auf Servern und in Containern relevant, wo eine Python- oder Node-Laufzeit ein zusätzlicher Wartungspunkt ist. Der Preis dafür steht im Repository selbst: Die Sprache der Metadaten ist Python, die Sprache im README ist Go, und die Topics führen beide. Das deutet auf ein Repository mit gemischtem Inhalt hin, nicht auf ein reines Go-Projekt. Wer die Codebasis bewerten will, muss diesen Widerspruch zuerst auflösen.

Für Aufgaben mit hohem Risiko ist FuXi das falsche Werkzeug. Ein Agent, der Dateien schreibt und Shell-Befehle ausführt, gehört nicht unbeaufsichtigt auf ein Produktionssystem, solange der AST-Klassifikator und die Berechtigungsstufen nicht unabhängig geprüft sind. Der Sicherheitsabschnitt liegt unter security-privacy/README.md und war im vorliegenden Material nicht enthalten. Ohne diese Lektüre ist jede Aussage über die Sicherheitseigenschaften eine Vermutung.

Wartungskosten und was vor dem Einsatz zu klären ist

Die laufenden Kosten sind gering, solange man die Binary aktuell hält. fuxi update erledigt das, inklusive Checksummenprüfung. Der Aufwand liegt woanders: bei der Konfiguration. Wer Routing über mehrere Anbieter nutzt, muss Schlüssel verwalten, Failover-Verhalten testen und die Kosten pro Anbieter im Blick behalten. Die TUI liefert dafür /cost, /usage, /context und /status. Diese vier Befehle sind die Messinstrumente, die das Projekt mitliefert, und sie sind der einzige Weg, den Verbrauch ohne externe Tools zu beobachten.

Der Upgrade-Aufwand ist in einer 0.x-Reihe nicht trivial. Zwischen 0.1.1 und 0.1.6 liegen rund fünf Wochen und mehrere Releases. Hot-reloadbare Plugins und Hooks können von Formatänderungen betroffen sein. Ein gepinntes Installationsargument schützt vor Überraschungen, kostet aber die automatischen Fehlerkorrekturen.

Vor dem ersten produktiven Einsatz würde ich drei Dinge prüfen. Erstens die LICENSE-Datei, weil die Metadaten NOASSERTION melden und das README "Proprietary" anzeigt. Zweitens fuxi doctor und fuxi verify auf der Zielmaschine, um Umgebungsprobleme von Agentenproblemen zu trennen. Drittens benchmark/REPORT.md, inklusive der dort genannten bekannten Einschränkungen, bevor man die Ergebnisse als Entscheidungsgrundlage verwendet. Wer diese drei Punkte abgearbeitet hat, weiß, ob FuXi in die eigene Umgebung passt. Wer sie überspringt, adoptiert eine 0.1.6 mit unklarer Lizenz auf Basis eines selbst gefahrenen Vergleichs.

Redaktionelles Fazit

Wer einen providerunabhängigen Terminal-Agenten sucht, sein Modell selbst mitbringen will und mit einer unklaren Lizenz leben kann, findet in FuXi einen kompakten Kandidaten: eine Binary, keine Runtime, MCP-Client, eigenes Berechtigungsmodell. Wer eine belastbare Fremdbewertung, klare Lizenzbedingungen oder eine reife 1.x-Version braucht, sollte warten. Prüft zuerst die LICENSE-Datei im Repository, dann fuxi doctor und fuxi verify, und verlangt für jede Aufgabe, die ihr vergleicht, eine identische Baseline und denselben Scorer.

Offizielle Quellen

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