Agenten?
Basierend auf der aktuellen Recherche (Mitte 2026) sieht die Landschaft so aus — speziell gefiltert für deine Situation, denn genau das ist entscheidend: Du hast einen einzelnen OpenAI-kompatiblen Endpunkt mit vielen Modellen dahinter. Diese Einschränkung schließt viele sonst sehr gute Tools aus oder stuft sie herunter und hebt die „Bring-your-own-model“-Tools (BYOM) nach oben. 🚀
Zuerst die wichtigste Einordnung: Agent = Modell + Gerüst
Die wichtigste Erkenntnis aus der aktuellen Recherche ist, dass das Gerüst genauso wichtig ist wie das Modell. In einem Test vom Februar 2026 erzielte dasselbe Modell (Opus 4.5), das über drei verschiedene Agenten-Frameworks lief, einen Unterschied von 17 Problemen in einem Datensatz mit 731 Problemen — ein Abstand so groß wie eine komplette Modellgeneration. Deine Wahl des Gerüsts ist also nicht nur Kosmetik, sondern bestimmt direkt die Qualität der Ergebnisse.
Da du die Modelle selbst bereitstellst, lautet deine eigentliche Entscheidung also: Welches Gerüst nutzt einen benutzerdefinierten OpenAI-kompatiblen Endpunkt mit mehreren Modellen am besten aus?
Das gesamte Feld, nach Eignung für dein Setup gruppiert
Stufe A — Beste Wahl für dich (native BYOM, Multi-Modell, OpenAI-kompatibel)
Diese Tools lassen dich auf eine benutzerdefinierte base_url zeigen, deinen Schlüssel eintragen und verschiedene Modelle verschiedenen Rollen zuweisen. Genau das ist dein Anwendungsfall.
| Tool | Formfaktor | Warum es zu dir passt |
|---|---|---|
| Cline | VS-Code-Erweiterung | Ca. 5 Mio. Installationen; explizite Konfiguration für „OpenAI Compatible“ (Basis-URL + Schlüssel + Modell-IDs). Der Plan-/Act-Modus trennt Architekt- und Coder-Rollen — perfekt, um Opus für die Planung und Sonnet für die Ausführung zuzuweisen. Kein Inferenz-Aufschlag. |
| Roo Code | VS-Code-Erweiterung (Cline-Fork) | Hat den Ruf, bei großen Änderungen über viele Dateien hinweg am zuverlässigsten zu sein. Mehr Konfigurationsmöglichkeiten, benutzerdefinierte „Modi“ (Rollen), die du an bestimmte Modelle binden kannst. Klassenbeste Lösung für das von dir beschriebene „große Projekt“-Problem. |
| Aider | CLI / Git-nativ | Ausgezeichnetes Repo-Mapping, atomare Git-Commits, funktioniert mit jedem OpenAI-kompatiblen Modell. Integrierter „Architect Mode“, der ein starkes Reasoning-Modell für die Planung und ein günstigeres Modell zum Schreiben des Diffs nutzt — also genau das Multi-Modell-Muster, das ich vorher beschrieben habe, sofort einsatzbereit. |
| OpenHands (früher OpenDevin) | Selbst gehosteter autonomer Agent | MIT-lizenziert, über 100 Backends, jede OpenAI-kompatible API. Führt einen vollständigen CodeAct-Zyklus aus (Code ausführen, Tests laufen lassen, browsen) in einer Docker-Sandbox. 72 % auf SWE-bench Verified. Die autonomste Option unter den BYOM-Tools. |
| Kilo Code | VS-Code-Erweiterung | Holt schnell auf; fokussiert auf enge Kontextkontrolle und strukturierte Modi; dokumentierte Unterstützung für benutzerdefinierte OpenAI-kompatible Provider. |
Stufe B — Hervorragende Tools, aber mit deinem Endpunkt etwas umständlich
- Claude Code — derzeit der Spitzenreiter bei der Codequalität (Opus 4.7/4.8), mit Selbstverifikation (schreibt Tests, führt sie aus, behebt Fehler vor der Antwort). Aber es ist auf die eigene API bzw. das eigene Abo von Anthropic ausgelegt; es über ein beliebiges OpenAI-kompatibles Gateway zu leiten, ist eher ein Kampf als eine Funktion.
- OpenAI Codex CLI — aktuell #1 auf Terminal-Bench (GPT-5.5, 82,7 %), sehr stark für DevOps- und Terminal-Workflows. An OpenAIs API bzw. ChatGPT-Pläne gebunden; eine benutzerdefinierte Base-URL war historisch eher eine gewünschte, aber eingeschränkte Funktion.
- Cursor — die beliebteste KI-IDE, modellagnostisch innerhalb ihrer eigenen unterstützten Liste (Opus 4.7, GPT-5.5, Gemini 3.1), aber sie akzeptiert nicht sauber einen beliebigen Drittanbieter-Endpunkt. Außerdem nur als VS-Code-Fork.
- GitHub Copilot — inzwischen Multi-Modell und 2026 mit Base-URL-Override, aber eher auf Enterprise-/Compliance-Standards ausgerichtet und mit einem Abrechnungsmodell auf Basis von Nutzungsguthaben unterwegs. Weniger natürlich für ein reines Custom-Gateway-Setup.
Stufe C — Autonom / Nische
- Devin 2.0 — vollständig isolierter Cloud-Ingenieur; stark bei klar abgegrenzten Aufgaben (Migrationen, Testabdeckung), schwächer bei mehrdeutigen Aufgaben. Kein BYOM.
- Augment Code — herausragende Repository-Kontext-Engine (indiziert das ganze Repo vor dem Start), über MCP nutzbar, sodass du die Indizierung zusammen mit einem anderen Generator verwenden könntest. Preislich eher Enterprise.
Meine Empfehlung für dich
Mit deinem OpenAI-kompatiblen Multi-Modell-Gateway und deinem Ziel von großen Projekten, die über einen einzelnen Prompt hinausgehen, würde ich einen mehrschichtigen BYOM-Stack aufsetzen:
1. Hauptwerkzeug: Roo Code (oder Cline)
Das ist dein wichtigstes Arbeitstool. Gründe:
- Nativer „OpenAI Compatible“-Provider — du kannst die URL und den Schlüssel deines Gateways direkt eintragen.
- Benutzerdefinierte Modi, die an verschiedene Modelle gebunden sind — das ist für dich die entscheidende Funktion. Konfiguriere:
- Architect/Plan-Modus → Opus (oder GPT-5.5) für Zerlegung und Design.
- Code-Modus → Claude Sonnet für den Großteil der Implementierung (schnell, günstig, stark).
- Debug/Review-Modus → ein anderes starkes Modell als der Autor, für modellübergreifendes Review.
- Zuverlässig bei Änderungen über viele Dateien und mit langem Horizont — genau das, was große Projekte brauchen.
- Läuft in VS Code, sodass du Diffs, Review und den Loop eng integriert hast.
Nimm Cline, wenn du eine etwas einfachere, rundere Erfahrung möchtest; nimm Roo Code, wenn du maximale Kontrolle und Zuverlässigkeit bei großen Refactorings willst (das ist sein Haupt-Ruf).
2. Schwere Refactorings / CLI-Fans: Aider
Behalte Aider für Git-native Refactorings mit Commit-pro-Änderung im Werkzeugkasten. Sein Architect + Editor-Zwei-Modell-Modus passt perfekt zu deinem Multi-Modell-Zugang: Richte die Architekten-Rolle auf Opus und die Editor-Rolle auf Sonnet aus. Ideal, wenn Korrektheit und eine saubere Historie wichtiger sind als IDE-Komfort.
3. Vollautonome Ausführung: OpenHands (optional)
Wenn du klar definierte Aufgaben komplett autonom laufen lassen willst (Code schreiben → Tests ausführen → iterieren in einer Sandbox), dann hoste OpenHands selbst gegen deinen Endpunkt. Am besten für den Anwendungsfall „Lass es über Nacht an diesem Modul arbeiten“. 🌙🤖
Modell-Routing, das du in allen Tools konfigurieren solltest
| Rolle | Modell | Begründung |
|---|---|---|
| Architekt / Planer | Opus (oder GPT-5.5) | Tiefstes Reasoning; derzeit führend bei der Codequalität. Die Kosten lohnen sich für die Planung. |
| Implementierer (Masse) | Claude Sonnet | Schnell, günstig, stark beim Coden — deine Rolle mit dem höchsten Volumen. |
| Terminal-/DevOps-Aufgaben | GPT-5.5 | #1 auf Terminal-Bench (82,7 %); am besten für Shell- und Pipeline-Arbeit. |
| Reviewer / Kritiker | Ein anderes Modell als der Autor | Modellübergreifendes Review erkennt gemeinsame blinde Flecken. |
Zwei wichtige Hinweise aus der Recherche
-
Benchmarks sind im Moment unsicher. SWE-bench Verified wurde als kontaminiert eingestuft (Februar 2026) — jedes Frontier-Modell konnte die Gold-Antworten aus dem Gedächtnis reproduzieren. Behandle veröffentlichte Werte daher nur als grobe Orientierung und lasse 50–100 Aufgaben aus deiner eigenen Codebasis durch dein Kandidaten-Setup laufen, bevor du dich festlegst.
-
Die Sicherheitslage unterscheidet sich deutlich. BYOM-Tools wie Cline/Roo/Aider laufen standardmäßig mit lokalem Systemzugriff — sie können
.env-Dateien lesen und Shell-Befehle ausführen. Für große autonome Projekte solltest du eine klare menschliche Review-Schranke definieren und über Sandboxing nachdenken (deshalb ist die Docker-Isolation von OpenHands für unbeaufsichtigte Läufe so attraktiv).
Kurz gesagt: Starte mit Roo Code (oder Cline) als deinem primären Agenten, konfiguriert mit modellbezogenem Routing pro Modus über dein Gateway; ergänze Aider für Git-native Refactorings; und setze optional OpenHands für autonome, isolierte Aufgabenausführung ein. Diese Kombination holt den größten Nutzen aus deiner OpenAI-kompatiblen Multi-Modell-API heraus und setzt direkt den Planen-→-Bauen-→-Reviewen-Loop um, den Projekte brauchen, die zu groß für einen einzelnen Prompt sind. ✅✨