Claude Code vs. Codex: Realer Build-Test – 36 Dateien vs. 28, Endlosschleife und 0,46-Dollar-Kostendifferenz
Ein Entwickler führte einen direkten Vergleich zwischen Claude Code und Codex (via Cursor) mit identischen Prompts und der gleichen MCP-Konfiguration (GitHub + Slack) durch. Keine Hinweise, keine zusätzliche Hilfe. Zwei Aufgaben:
- Aufgabe 1: PR-Triage-Bot – offene PRs lesen, Komplexität bewerten, Bericht schreiben, bei hoher Priorität in Slack benachrichtigen. Erforderlich: Wiederholungslogik, Fehlerprotokollierung, striktes TypeScript (kein
any). - Aufgabe 2: Echtzeit-Code-Review-Oberfläche – React, WebSocket, Inline-Kommentare, optimistische Updates mit Rückrollfunktion, virtualisierte Diff-Ansicht, erneute Verbindung mit Backoff. Keine UI-Bibliotheken, alles von Grund auf.
Ergebnisse
- Claude Code: Überprüfte, ob MCP-Tools aktiv waren, bevor Code geschrieben wurde. Erstellte 36 Dateien in 12 Minuten. Enthielt einen nicht angeforderten WebSocket-Smoke-Test mit zwei Clients. Broadcast-Latenz: 3 ms. Kein einziges
any. Bestand den Typtest beim ersten Versuch. - Codex (Cursor): Konnte bei Aufgabe 1 nicht auf GitHub MCP zugreifen (Cursor's Ausführungspfad legte keine Tool-Beschreibungen offen). Nach 3 Wiederholungen
tool not found, aber sauber protokolliert und behandelt – Umgebungsproblem, keine Modellqualität. Aufgabe 2 lieferte eine funktionierende Oberfläche in ~15 Minuten, 5 ms Latenz. Der erste Compile-Lauf hatte TypeScript-Fehler und eine Endlos-Schleife in React (useEffectruft wiederholthydrateauf), die einen Ref-Guard-Patch erforderte.
Kosten
API-Kosten für beide Aufgaben: Claude ~2,50 $, Codex ~2,04 $. Claude war ~23 % teurer, lieferte aber eine detailliertere Architektur und eine sofort saubere Oberfläche.
Wichtige Erkenntnisse
Der Autor stellt fest, dass die beiden Tools nicht wirklich für denselben Anwendungsfall konkurrieren. Claude Code fühlt sich an wie die Zusammenarbeit mit jemandem, der zuerst die Dokumentation liest; Codex fühlt sich an wie ein Senior-Entwickler, der schnell liefern will. Keines der Tools hat any durchsickern lassen, keines hat einen Tool-Namen halluziniert, und beide haben WebSocket-Broadcasts unter 10 ms erreicht – eine deutliche Verbesserung gegenüber vor sechs Monaten.
📖 Vollständige Quelle lesen: r/LocalLLaMA
👀 Siehe auch
Claudes stiller Absturz: Der Ausfall der Handlungsebene, wenn KI-Agenten auf Geschäftsseiten treffen
Claude kann Geschäftsseiten (Preise, Buchungsabläufe, Formulare) lesen, scheitert jedoch an der Handlungsebene – Buchung, Übermittlung oder Weiterleitung – aufgrund fehlender aufrufbarer Endpunkte. Dies verursacht unsichtbare Nutzerabbrüche ohne Analysesignal.
Messung des Off-Task-Token-Verbrauchs in Claude Code: Die 'Undeclared-Intent'-Metrik
Ein Entwickler erstellte eine Metrik, um Rechenressourcen zu quantifizieren, die für nicht vorgesehene Ausführungspfade in Claude-Code-Sitzungen aufgewendet wurden, und stellte fest, dass 22,8 % der Tokens für Nebenaufgaben verwendet wurden.
Flash-MOE-Benchmark auf dem M5 Max: 12.99 Tok/s mit Qwen3.5-397B
Ein Benchmark des 397-Milliarden-Parameter-Modells Qwen3.5, das lokal auf einem MacBook Pro M5 Max mit 128 GB RAM läuft, erreichte 12,99 Token pro Sekunde mit 4-Bit-Quantisierung und Cache-IO-Split 4, was dreimal schneller ist als der ursprüngliche Benchmark mit 48 GB.
LightMem: Leichtgewichtiges Speichersystem für LLM-Agenten mit 10-fachen+ Leistungsgewinnen und 100-fach geringeren Kosten
LightMem ist ein modulares Speichersystem für LLM-Agenten, das eine Genauigkeitsverbesserung von bis zu 10,9 % erreicht und gleichzeitig die Tokenanzahl um bis zu das 117-fache, API-Aufrufe um bis zu das 159-fache und die Laufzeit um über das 12-fache reduziert. Es ist für skalierbare Langzeitkontext-Verarbeitung in Agenten-Workflows konzipiert.