Open Source · KI-Tooling
pi-fusion: Wenn mehrere Modelle gemeinsam recherchieren
Die meisten KI-Antworten kommen aus genau einem Lauf: eine Frage, ein Modell, eine Antwort. Für schnelle Sachen reicht das. Bei einer Architekturentscheidung, einem Benchmark-Vergleich oder einer gründlichen Recherche ist es riskant: Ein einzelnes Modell hat blinde Flecken, und man sieht sie ihm nicht an. pi-fusion ist die Open-Source-Erweiterung, mit der ich diesen Abstand einbaue: dieselbe Frage geht in mehrere getrennte Kontexte, die Antworten werden verglichen, und erst danach entsteht die finale Antwort.
Was „pi" ist und was pi-fusion ergänzt
pi-fusion ist eine Erweiterung für pi – eine KI-Plattform mit Kommandozeilen- und TUI-Oberfläche, in der man mit Agenten arbeitet, Tools lädt und Erweiterungen installiert. Man kann sich pi als die Umgebung vorstellen, in der die Agenten laufen; pi-fusion bringt eine neue Fähigkeit mit, die sich in diese Umgebung einklinkt. Die README bringt es auf einen Satz:
„pi_fusion fans one prompt out to multiple isolated child agents, compares their answers with
a judge pass, then asks a synthesizer model to write the final answer."
Auf Deutsch: Eine Frage wird in mehrere voneinander isolierte Child-Agent-Runs geschickt. Die Antworten werden in einem Bewertungsdurchlauf verglichen, und am Ende schreibt ein eigenes Synthese-Modell die finale Antwort. Genau das ist mit „Fusion-style multi-model research panels" gemeint: ein Panel aus mehreren Modellen, die parallel an derselben Frage arbeiten und deren Ergebnisse anschließend zusammengeführt werden.
Die Idee hinter den Panels
Der Kern ist bewusst einfach. Statt einem Modell blind zu vertrauen, erzeugt man mehrere saubere Kontexte für dieselbe Frage. Nicht, weil dort plötzlich drei kleine Mitarbeiter sitzen. Der Wert liegt darin, dass die Antworten unabhängig voneinander entstehen. Drei Schritte laufen nacheinander ab:
Erstens das Panel: Die Frage wird auf mehrere Runs verteilt, jeder mit einem eigenen Modell und einer eigenen, isolierten Sitzung. Sie sehen die Antworten der anderen nicht und können sich dadurch auch nicht gegenseitig in dieselbe Richtung ziehen. Zweitens der Judge: Ein eigenes Modell vergleicht die Panel-Antworten und bewertet sie. Drittens die Synthese: Ein Synthese-Modell schreibt aus den geprüften Antworten die endgültige Antwort. Diese Trennung in Panel, Judge und Synthesizer macht das Ergebnis besser prüfbar als einen einzelnen Durchlauf.
Wie es technisch funktioniert
pi-fusion ist in TypeScript geschrieben und installiert sich als pi-Erweiterung. Es registriert ein Tool namens
pi_fusion sowie eine Reihe von Slash-Kommandos. Das Herzstück sind die Subagenten: Die
Erweiterung startet für jeden Panelisten einen eigenen Kind-Prozess, also einen getrennten Run mit eigenem
Kontext. Welcher „Runner" das übernimmt, richtet sich nach dem Modell-Slug – pi kann eigene Modelle laufen
lassen, aber genauso Claude Code für claude/...-Modelle, Codex für codex/... oder ein lokales Ollama-Modell. So lassen sich
Modelle aus völlig verschiedenen Quellen in ein und demselben Panel kombinieren.
Konfiguriert wird das über eine schlichte JSON-Datei – global unter ~/.pi/agent/fusion.json oder
projektlokal unter .pi/fusion.json. Die mitgelieferte config.json.example zeigt den
Aufbau, hier leicht gekürzt:
{
"panelModels": [
"google/gemini-3-flash-preview",
"moonshotai/kimi-k2.6",
"deepseek/deepseek-v4-pro"
],
"judgeModel": "anthropic/claude-opus-4-5",
"synthesizerModel": "anthropic/claude-opus-4-5",
"defaultPanelSize": 3,
"maxConcurrency": 4,
"confirmBeforeRun": true
}
Man sieht direkt das Prinzip: drei verschiedene Panel-Modelle, ein dedizierter Judge, ein dedizierter
Synthesizer, drei Panelisten als Standardgröße, höchstens vier parallel – und confirmBeforeRun,
das im TUI vor jedem Lauf nachfragt, bevor Kind-Prozesse gestartet werden. Wer Presets sauber als Profile
ablegen will, nutzt YAML-Dateien unter ~/.pi/agent/fusion-presets/; pi-fusion parst sie übrigens
ohne npm-Abhängigkeit, indem es schlicht den Ruby-Standardparser Psych aufruft.
Installieren und benutzen
Die Installation läuft direkt aus GitHub. Entweder dauerhaft installieren oder einmalig zum Ausprobieren laden:
pi install git:github.com/tjansn/pi-fusion@v0.1.0
# oder ohne Installation testen
pi -e git:github.com/tjansn/pi-fusion@v0.1.0
Danach stellt man seine Frage über das /fusion-Kommando. Mit einem benannten Preset sieht das so
aus:
/fusion deep-research What is currently the best benchmark
for evaluating agentic deep research systems?
Während es läuft, zeigt pi-fusion ein Live-Widget im TUI: das gewählte Preset, welcher Runner und welches
Modell hinter jedem Panelisten, Judge und Synthesizer steckt, den Status jeder Stufe
(pending, running, ok, error), Token, bekannte API-Kosten,
die verstrichene Zeit und das Verzeichnis, in dem die Artefakte landen. Man sieht also, wo der Lauf gerade
steht, statt nur auf eine fertige Antwort zu warten.
Warum mehrere Modelle besser recherchieren
Der Gewinn liegt in der Unabhängigkeit. Jedes Modell hat eigene Trainingsdaten, eigene Stärken und eigene systematische Fehler. Lässt man drei Modelle dieselbe Frage getrennt beantworten, fallen Übereinstimmungen und Widersprüche sofort auf: Wo alle drei dasselbe sagen, kann man sich ziemlich sicher sein; wo sie auseinandergehen, weiß man, dass genau dort genauer hinzusehen ist. Der Judge-Schritt macht diese Bewertung explizit, statt sie dem Leser zu überlassen. Genau deshalb lohnt sich der Aufwand bei „high-stakes"-Fragen – Architektur, Benchmarks, tiefe Recherche – und eben nicht bei jeder kleinen Auskunft.
Der ehrliche Haken
Das hat seinen Preis, ganz buchstäblich. Die README sagt es selbst deutlich: Fusion-Läufe können teuer sein.
Ein einziger /fusion-Aufruf startet mehrere Panel-Runs, einen Judge und einen Synthesizer. Man
bezahlt also nicht eine Antwort, sondern fünf oder mehr Modell-Durchläufe für dieselbe Frage. Dazu kommt die
Latenz: mehrere Runs und zwei nachgelagerte Stufen brauchen länger als ein einzelner Aufruf. Und die
Kind-Prozesse erben die Umgebung und die Auth des Aufrufenden, weshalb pi-fusion standardmäßig nur Lese- und
Web-Tools erlaubt und vor dem Start nachfragt. Kurz: ein Werkzeug für die Fragen, bei denen die richtige
Antwort mehr wert ist als die gesparten Token – nicht für den Alltag.
Wie das zu meiner Arbeit passt
Genau dieses Muster nutze ich in Kundenprojekten: nicht ein riesiger Agent, der alles gleichzeitig im Kontext hält, sondern getrennte Runs mit klarer Rolle, sauberem Kontext und Review-Schritt. Mal arbeiten sie parallel an getrennten Teilen, mal – wie hier – an derselben Frage, damit man nicht von einer einzelnen Modell-Meinung abhängt. pi-fusion ist dafür ein gutes Anschauungsbeispiel: unabhängige Perspektiven einholen, sie überprüfen lassen, dann sauber zusammenführen – und am Ende gibt ein Mensch frei. Wer den Code im Detail sehen will, findet alles offen auf github.com/tjansn/pi-fusion.