Agenten?

Ich werde den aktuellen Stand von Coding-Agents recherchieren, denn diese Landschaft bewegt sich schnell und wir sind jetzt mitten im Jahr 2026. Deine OpenAI-kompatible Multi-Model-Setup-Umgebung ist eine zentrale Einschränkung, also konzentriere ich mich auf Tools, die benutzerdefinierte Endpunkte unterstützen.
Ich hole mir Details aus ein paar der inhaltlich wichtigsten Vergleiche und bestätige den aktuellen Stand der Benchmarks.

Basierend auf aktueller Recherche (Mitte 2026) ist das die Landschaft – gefiltert genau für deine Situation, denn das ist der entscheidende Faktor: Du hast einen einzelnen OpenAI-kompatiblen Endpunkt mit vielen Modellen dahinter. Diese Einschränkung eliminiert oder priorisiert sehr viele ansonsten großartige Tools heraus und hebt die Bring-Your-Own-Model (BYOM)-Ansätze stark nach oben. 🚀

Zuerst die Kernrahmung: Agent = Modell + Harness 🧱

Die wichtigste Erkenntnis aus der aktuellen Recherche ist, dass das Gerüst (Harness) mindestens genauso wichtig ist wie das Modell. In einem Test im Februar 2026 lieferte dasselbe Modell (Opus 4.5), einmal durch drei verschiedene Agent-Frameworks geflogen, eine Differenz von 17 Problemen auf einer 731-Problemmenge – eine Lücke in der Größenordnung einer kompletten Modell-Generation. Daher ist deine Wahl des Harness nicht kosmetisch; sie bestimmt direkt die Ausgabequalität.

Da du die Modelle selbst bereitstellst, lautet die zentrale Frage im Kern: Welches Harness nutzt einen benutzerdefinierten OpenAI-kompatiblen Endpunkt mit mehreren Modellen am besten aus?

Das komplette Feld – nach Passform für dein Setup gruppiert

Tier A — Beste Passform für dich (native BYOM, Multi-Model, OpenAI-kompatibel) ✅

Diese Tools lassen dich auf ein Custom base_url zeigen, deinen Key einstecken und verschiedene Modelle verschiedenen Rollen zuweisen. Das ist exakt dein Use Case.

Tool	Formfaktor	Warum es zu dir passt
Cline	VS Code-Erweiterung	~5M Installationen; explizite Konfiguration für „OpenAI Compatible“ (Base URL + Key + Model-IDs). Plan/Act trennt Architect- und Coder-Rollen – perfekt, um Opus fürs Planen und Sonnet für die Umsetzung zuzuweisen. Keine Inferenz-„Markup“-Sonderwege.
Roo Code	VS Code-Erweiterung (Cline-Fork)	Ruf als am zuverlässigsten bei großen, mehrdateiigen Änderungen. Mehr Konfigurationshebel, eigene „modes“ (Rollen), die du an bestimmte Modelle bindest. Sehr stark für das „Big Project“-Problem, das du beschrieben hast.
Aider	CLI / git-nativ	Sehr stark bei Repo-Mapping, atomaren git-Commits, funktioniert mit jedem OpenAI-kompatiblen Modell. Integrierter „architect mode“, der ein starkes Reasoning-Modell fürs Planen nutzt und ein günstigeres Modell, um den Diff zu schreiben – genau das Multi-Model-Muster, das ich oben beschrieben habe, out of the box.
OpenHands (früher OpenDevin)	Self-hosted autonomer Agent	MIT-lizensiert, 100+ Backends, jede OpenAI-kompatible API. Läuft eine komplette CodeAct-Schleife (Code ausführen, Tests laufen lassen, browsen) in einem Docker-Sandbox. 72% auf SWE-bench Verified. Am autonomsten unter den BYOM-Optionen.
Kilo Code	VS Code-Erweiterung	Entwickelt sich schnell; Fokus auf enges Kontext-Handling und strukturierte Modes; dokumentiert Support für benutzerdefinierte OpenAI-kompatible Provider.

Tier B — Sehr gute Tools, aber holprig mit deinem Endpunkt

Claude Code — der aktuelle Leader bei Code-Qualität (Opus 4.7/4.8), mit Selbst-Verifikation (schreibt Tests, führt sie aus, behebt Fehler, bevor er zurückantwortet). Aber es ist auf Anthropic’s eigene API/Subscription gebaut; Routing über ein beliebiges OpenAI-kompatibles Gateway ist eher „Kampf“, kein Feature. ⚠️
OpenAI Codex CLI — aktuell #1 bei Terminal-Bench (GPT-5.5, 82,7%), stark für DevOps/Terminal-Workflows. An OpenAI-APIs/ChatGPT-Pläne gebunden; ein Custom-Base-URL-Override war historisch eine gewünschte, aber begrenzt unterstützte Funktion.
Cursor — das meistgeliebte AI-IDE-Tool, model-agnostisch innerhalb seiner eigenen unterstützten Modellliste (Opus 4.7, GPT-5.5, Gemini 3.1), aber es ist sein eigener Editor und akzeptiert keinen beliebigen Drittanbieter-Endpunkt sauber. Außerdem: nur VS Code-Fork.
GitHub Copilot — inzwischen Multi-Model und 2026 mit Base-URL-Override, aber primär auf Enterprise/Compliance-Defaults ausgelegt, plus Wechsel auf Usage-Credits als Billing-Modell. Weniger natürlich für reines Custom-Gateway-Setup.

Tier C — Autonom/Nischenbereich

Devin 2.0 — vollständig gesandboxter Cloud-Engineer; stark bei klar abgegrenzten Aufgaben (Migrations, Test-Coverage), schwach bei mehrdeutigen. Nicht BYOM.
Augment Code — herausragende Repository-Kontext-Engine (indexiert das ganze Repo, bevor es startet), über MCP verfügbar, sodass du es neben einem anderen Generator nutzen könntest. Enterprise-Preise.

Meine Empfehlung für dich 🎯

Aufgrund deines OpenAI-kompatiblen Multi-Model-Gateways und deines Ziels von großen Projekten, die deutlich über einen einzelnen Prompt hinausgehen, würde ich ein layered BYOM-Setup bauen:

1. Primärer Treiber: Roo Code (oder Cline) 💪

Das ist dein Haupt-Workhorse. Gründe:

Native „OpenAI Compatible“-Provider — Gateway-URL/Key direkt einstecken.
Custom modes mit verschiedenen Modellen — das ist der Killer-Use-Case für dich. Konfigurieren:
- Architect/Plan mode → Opus (oder GPT-5.5) für Zersetzung und Design.
- Code mode → Claude Sonnet für den Großteil der Umsetzung (schnell, günstig, stark).
- Debug/Review mode → ein anderes starkes Modell als das Autor-Modell für Review über Modellgrenzen hinweg.
Zuverlässig bei Multi-File, Long-Horizon-Änderungen — genau das, was große Projekte brauchen.
Läuft in VS Code, damit du Diffs, Review und die Schleife eng integriert bekommst.

Cline nimmst du, wenn du eine etwas einfachere, polierte Erfahrung willst; Roo Code, wenn du maximal Kontrolle und Zuverlässigkeit bei großen Refactors willst (seine Haupt-Referenz).

2. Große Refactors / CLI-Puristen: Aider 🧰

Aider behältst du in deiner Toolbox für git-natives Refactoring im „commit-per-change“-Stil. Sein architect + editor zwei-Modell Modus passt perfekt zu deinem Multi-Model-Zugang: architect role auf Opus und editor role auf Sonnet. Ideal, wenn Korrektheit und saubere Historie wichtiger sind als IDE-Komfort.

3. „Fire-and-forget“-Autonomie: OpenHands (optional) 🔥

Wenn du gut spezifizierte Aufgaben abgeben willst, die komplett autonom laufen sollen (Code schreiben → Tests ausführen → in einer Sandbox iterieren), self-hostest du OpenHands gegen deinen Endpunkt. Am besten für den „lass es diese Komponente über Nacht durcharbeiten“-Use-Case.

Modell-Routing (über alle Tools hinweg) – zum Konfigurieren

Rolle	Modell	Begründung
Architect / planner	Opus (oder GPT-5.5)	Tiefste Reasoning-Tiefe; aktueller Leader bei Code-Qualität. Kostet sich beim Planen.
Implementer (bulk)	Claude Sonnet	Schnell, günstig, stark fürs Codieren — deine High-Volume-Rolle.
Terminal/DevOps Aufgaben	GPT-5.5	#1 bei Terminal-Bench (82,7%); am besten für Shell-/Pipeline-Work.
Reviewer / critic	ein anderes Modell als der Author	Cross-Model Review fängt geteilte Blindspots ab.

Zwei wichtige Caveats, die du aus der Recherche mitnehmen solltest 🔒

Benchmarks sind gerade wacklig. SWE-bench Verified wurde als kontaminiert gefunden (Feb 2026) – jedes Frontier-Modell konnte „Gold“-Antworten aus dem Gedächtnis reproduzieren. Daher: veröffentlichte Scores nur als richtungsweisend behandeln und 50–100 Aufgaben aus deinem eigenen Codebase durch dein Kandidaten-Setup laufen lassen, bevor du dich festlegst.
Security-Posture unterscheidet sich stark. BYOM-Tools wie Cline/Roo/Aider laufen mit lokalem Systemzugriff standardmäßig — sie können .env-Dateien lesen und Shell-Kommandos ausführen. Bei großen autonomen Projekten: eine explizite Human-Review-Gate definieren und Sandboxing in Betracht ziehen (genau deshalb ist die Docker-Isolation bei OpenHands attraktiv für „hands-off“ Runs).

Fazit: Starte mit Roo Code (oder Cline) als primären Agenten, konfiguriert mit per-mode Modellrouting über dein Gateway; ergänze Aider für git-native Refactors; optional OpenHands für autonomes, gesandboxtes Task-Ausführen. Dieses Trio maximiert den Nutzen deiner Multi-Model OpenAI-kompatiblen API und setzt direkt die benötigte Schleife um: plan → build → review — genau für Projekte, die zu groß für einen einzelnen Prompt sind. ✅🤖