Werkzeuge
·
5 MIN
Coding-Agent wählen: Claude Code, Codex, Cursor, Antigravity oder Opencode
Den Coding-Agenten entscheidet die Datenlage, nicht das Benchmark. Verlässt euer Code das Haus oder nicht?
LOCATION
Deutschland
SERIES
AI Tooling & Dev Harnesses
AUTHOR
Aashwin Shrivastava
PUBLISHED
Welcher Coding-Agent der richtige ist, entscheidet die Datenlage und euer bestehender Stack, nicht der oberste Platz in einem SWE-Bench-Ranking. Die Unterschiede zwischen den Spitzenmodellen liegen für die meiste reale B2B-Arbeit im Rauschen.
Claude Code, Codex, Cursor, Antigravity und Opencode lösen dieselbe Aufgabe auf sehr unterschiedliche Weise. Die eine Frage, die das Feld teilt, ist einfach: muss euer Code das Haus verlassen dürfen? Wer das mit Ja beantworten kann, wählt nach Stack. Wer es nicht kann, hat genau eine ernsthafte Option. Dieser Text ordnet die fünf entlang dieser Frage und endet mit der Entscheidung, die ich einem deutschen Team empfehle.
01.
Fünf Werkzeuge, eine erste Frage
Die fünf sitzen auf verschiedenen Ebenen, und der Formfaktor sagt schon viel über den Einsatz.
Claude Code ist ein Terminal-Agent von Anthropic: stark bei Mehrdatei-Änderungen, großem Kontext und einer agentischen Schleife im Terminal.
Codex von OpenAI gibt es als CLI, Cloud-Sandbox und IDE-Integration aus einem gemeinsamen Nutzungsfenster.
Cursor ist die KI-IDE mit Agenten- und Hintergrund-Agenten-Modus und freier Modellwahl.
Antigravity ist Googles agentenzentrierte IDE, seit dem 20.11.2025 verfügbar, mit einer Manager-Oberfläche zum Starten und Beobachten paralleler Agenten (Google).
Opencode ist ein quelloffener Terminal-Agent unter MIT-Lizenz, modellunabhängig über viele Anbieter und selbst gehostete Endpunkte (opencode.ai).
Wie diese Werkzeuge sich in einen Stack einfügen, von der API bis zur CLI, haben wir in API, MCP oder CLI ausgelegt. Hier geht es um die Auswahl, und die beginnt mit der Datenlage.
02.
Verlässt euer Code das Haus?
Diese eine Frage sortiert das Feld schneller als jede Funktionsliste, weil sie über Compliance und Vertraulichkeit entscheidet, bevor irgendein Feature zählt.
Vier der fünf senden Code in eine fremde Cloud. Claude Code, Codex, Cursor und Antigravity laufen gegen gehostete Modelle in den USA. Das ist nicht per se ein Ausschluss: für viele Projekte ist das in Ordnung, und im Enterprise-Tarif lassen sich Zero-Data-Retention und No-Train-Klauseln verhandeln. Aber der Code geht raus, und das muss man bewusst akzeptieren, nicht übersehen.
Opencode ist die Ausnahme. Weil es modellunabhängig ist und einen lokalen Endpunkt ansprechen kann, läuft es vollständig gegen ein selbst gehostetes Modell. Dann verlässt der Code das Haus nie. Das ist genau die Trennlinie, die über alles Weitere entscheidet. Welches Open-Weight-Modell ihr dahinter setzt, ist eine eigene Entscheidung, die wir in Open-Weight-Modell fürs deutsche B2B durchgehen.
03.
Wenn die Cloud okay ist: nach Stack wählen
Akzeptiert ihr die gehostete Cloud bewusst, dann entscheidet der Stack, nicht das Benchmark. Eine knappe Karte:
Werkzeug | Formfaktor | Modell | Quelloffen | Am besten für |
|---|---|---|---|---|
Claude Code | Terminal-CLI | Anthropic | nein | tiefe Mehrdatei-Arbeit im Terminal |
Codex | CLI + Cloud + IDE | OpenAI | Client teils offen | ChatGPT-Teams, Cloud-Sandboxes |
Cursor | IDE | Multi-Modell | nein | IDE-naher Fluss, Modellwechsel |
Antigravity | Agent-IDE | Multi-Modell | nein | Agenten-Orchestrierung mit Verifikation |
Opencode | Terminal-CLI | beliebig / lokal | MIT | Kontrolle, kein Lock-in, lokales Modell |
Die pragmatische Regel: Anthropic-Haus nimmt Claude Code, OpenAI-Haus nimmt Codex, ein IDE-zentriertes Team nimmt Cursor oder Antigravity. Benchmark-Zahlen wie SWE-Bench-Werte um die 85 Prozent kursieren, sind aber meist Anbieterangaben und selten unabhängig nachgeprüft; ich würde keine Werkzeugwahl darauf stützen. Was ein Coding-Agent außerhalb der reinen Entwicklung leistet, zeigt unser Beitrag Claude Code jenseits des Engineerings.
04.
Wenn der Code im Haus bleiben muss: Opencode plus eigenes Modell
Darf der Code nicht raus, bleibt eine ernsthafte Option, und sie ist gut.
Opencode ist quelloffen unter MIT, spricht viele Anbieter und, entscheidend, einen lokalen Endpunkt an. Gepaart mit einem selbst gehosteten Open-Weight-Modell entsteht ein Coding-Agent, bei dem weder Quelltext noch Prompts die eigene Infrastruktur verlassen. Für regulierte Daten, Mandantengeheimnisse oder schlicht vorsichtige Kunden ist das oft der einzige tragfähige Aufbau. Ein offenes Coding-Modell wie Kimi K2.7 haben wir dafür eigens angeschaut.
Der Preis dieser Kontrolle ist Eigenarbeit: ihr stellt Modell, Hardware und Betrieb selbst zusammen, es gibt keine gemanagte Cloud-Agenten-Flotte. In der Praxis hilft es, dem Agenten Struktur zu geben, etwa eine Codebasis-Karte, wie wir sie in Graphify beschrieben haben. Der Aufwand ist real, aber er kauft etwas, das die gehosteten Werkzeuge nicht bieten können.
05.
Wie ich das entscheide
Ihr braucht keine einzelne Antwort für die ganze Firma, sondern die richtige je nach Datenlage. So gehe ich vor:
Datenlage klären. Darf der betreffende Code in eine US-Cloud? Diese Antwort kommt von Recht und Kunde, nicht vom Entwicklerteam.
Wenn ja, nach Stack wählen. Anthropic-Haus zu Claude Code, OpenAI-Haus zu Codex, IDE-Team zu Cursor oder Antigravity, jeweils mit verhandelten ZDR- und No-Train-Bedingungen.
Wenn nein, Opencode plus eigenes Modell. Die einzige Option, bei der der Code das Haus nicht verlässt.
Lock-in im Blick behalten. Verlangt jedes Werkzeug seine eigene Bindung, also haltet euch einen Weg zurück zu einer tieferen Ebene offen, falls ein Anbieter die Bedingungen ändert.
Wir selbst arbeiten je nach Projekt mit mehreren dieser Werkzeuge, und genau das ist der Punkt: die Wahl ist projektgebunden, nicht weltanschaulich. Das eine kleine interne Tool, das wir mit einem Agenten gebaut haben, statt es zu beauftragen, steht in Building event-scout. Welche eurer Repositories dürften heute eigentlich gar nicht in eine fremde Cloud, und welches Werkzeug nutzt ihr trotzdem dafür?
