IQuest-Coder: Neues Open-Source-Code-Modell übertrifft Claude Sonnet 4.5 und GPT 5.1 [pdf]

• Ein auf Coding spezialisiertes offenes Code-LLM, das durch mehrstufiges code-flow-Lernen nicht statischen Code, sondern Veränderungen in Repositories und den Entwicklungsprozess lernt
• Stärkt langfristiges Schlussfolgern und die Leistung bei Agentenaufgaben durch eine evolutionäre Lernpipeline aus Pretraining, Mid-Training und Post-Training
• Sichert sich durch die Einspeisung von Reasoning-Daten und Agenten-Trajektorien in 32K- und 128K-Kontexten die Fähigkeit, komplexe Multi-File- und Repository-Probleme zu lösen
• Schlägt mit der LoopCoder-Architektur mit wiederholender Struktur ein praktisches Design vor, das die Bereitstellungseffizienz im Verhältnis zur Modellgröße verbessert
• Erreicht auf SWE-Bench, LiveCodeBench, Terminal-Bench und weiteren Benchmarks mit einem Open-Weights-Modell eine mit kommerziellen Modellen konkurrenzfähige Leistung

---

Überblick

• IQuest-Coder-V1 ist eine Familie großer, ausschließlich auf Code ausgelegter Sprachmodelle mit 7B, 14B, 40B und 40B-Loop
• Verwendet das code-flow-Paradigma, bei dem nicht Code-Snapshots, sondern Commits und die Evolution von Repositories als Lernziel dienen
• Führt Leistungsbewertungen in agentischer Softwareentwicklung, Competitive Programming und beim allgemeinen Tool-Einsatz durch

Code-Flow-Lernpipeline

• In der Pretraining-Phase werden allgemeine Daten und große Code-Datensätze gemeinsam trainiert, anschließend wird High-Quality Code Annealing angewendet
• In der Mid-Training-Phase erfolgt eine Kontext-Erweiterung von 32K → 128K sowie das Lernen mit Reasoning-QA-, Agenten-Trajektorien- und repositorybasierten Code-Daten
• In der Post-Training-Phase erfolgt eine Aufspaltung in den Thinking-Pfad (Reasoning-zentriertes RL) und den Instruct-Pfad (Optimierung für allgemeine Assistenz)

Zentrale Forschungsergebnisse

• Experimente bestätigen, dass Repository-Commit-Flow-Daten bessere Signale für die Aufgabenplanung liefern als statische Code-Snapshots
• Eine Struktur, die nach High-Quality Code Annealing im Mid-Training Reasoning- und Agenten-Daten einspeist, sorgt für Stabilität gegenüber Verteilungsverschiebungen
• Im Thinking-Pfad mit Reasoning-zentriertem RL zeigt sich deutlich eine Fähigkeit zur selbstständigen Fehlerkorrektur bei langfristigen Aufgaben

LoopCoder-Architektur

• Einführung einer Loop-Transformer-Struktur, die denselben Parameterblock zweimal wiederholt ausführt
• Kombiniert globale und lokale Attention per Gating, um Verfeinerung des Langstreckenkontexts und Erhalt der Kausalität gleichzeitig zu erreichen
• Ziel ist es, die Recheneffizienz im Verhältnis zur Modellgröße zu verbessern und so Einschränkungen in Deployment-Umgebungen zu adressieren

Datenaufbau und Pretraining-Strategie

• Formalisiert in mehrsprachigem gemischtem Code-Training Synergieeffekte zwischen Sprachen über ein formelbasiertes Scaling Law
• Aufbau von (R_old, Patch, R_new)-Triplet-Daten unter Nutzung von Commits aus dem Bereich von 40–80 % des Repository-Lebenszyklus
• Stärkt die Code-Vervollständigungsfähigkeit mit Fill-in-the-Middle-Techniken auf Datei- und Repository-Ebene

Evaluationsergebnisse

• Erreicht 76,2 auf SWE-Bench Verified und Spitzenleistungen in mehreren Benchmarks wie LiveCodeBench v6, Terminal-Bench und Mind2Web
• Führt eine umfassende Evaluation über Codegenerierung, Reasoning, Editing, Effizienz, Text-to-SQL und Agentenaufgaben hinweg durch
• Zeigt bei einigen Metriken nahezu gleichwertige oder konkurrenzfähige Ergebnisse gegenüber geschlossenen Modellen wie Claude Sonnet 4.5 und GPT-5.1

Sicherheitsbewertung

• In Sicherheits-Benchmarks wie BeaverTails, HarmBench und TrustLLM erzielt das Thinking-Modell hohe Ablehnungsgenauigkeit und ausgewogene Leistung
• Präsentiert Ergebnisse, die darauf hindeuten, dass Reasoning-zentriertes RL auch in Bezug auf Sicherheit positive Effekte hat

Fazit

• Belegt, dass auf Code-Evolutionsflüssen und Agenten-Trajektorien basierendes Lernen wirksam für die Ausbildung autonomer Code-Intelligenz ist
• Zeigt mit der LoopCoder-Struktur eine praktische Richtung für das Design von Code-LLMs unter Berücksichtigung des Performance-Effizienz-Trade-offs auf
• Ziel ist es, durch die Offenlegung aller Trainingsphasen und Checkpoints Open-Code-Intelligence-Forschung und die Entwicklung realer Agentensysteme zu beschleunigen

[GN⁺]

Hacker-News-Kommentare

• Der bessere Link ist iquestlab.github.io Leider sieht es aber so aus, als hätte der Agent beim Benchmark geschummelt

  • Laut dem GitHub-Issue waren die Ergebnisse auch nach der Korrektur des Schummelns weiterhin gut Der Wert fiel von 81,4 % auf 76,2 %, lag damit aber immer noch über Opus 4.5 (74,4 %)
  • Vor ein paar Tagen hat dieser Link offenbar nicht genug Votes bekommen

• Kurz gesagt: Der .git/-Ordner wurde nicht bereinigt, sodass das Modell sich per Reward Hacking auf Fixes aus zukünftigen Commits beziehen konnte Ich möchte den Leuten Anerkennung geben, die geholfen haben, das aufzudecken Die Diskussion dazu findet sich auch in diesem Tweet und im Reddit-Thread Dass IQuestLab die SWE-Bench-Verified-Daten veröffentlicht hat, spricht eher für einen simplen Anfängerfehler beim Benchmarking als für absichtliche Manipulation

  • Wie John erwähnt hat, wurde dieses Problem in SWE-bench bereits behoben Man muss nur den aktuellen Code verwenden und die Evaluierung mit dem aktualisierten Docker-Image ausführen Zugehöriger Tweet
  • Ich glaube auch, dass es nur ein Versehen war, aber schade ist, dass die Forschenden es sofort bemerkt hätten, wenn sie sich die Ausgaben auch nur einmal angesehen hätten
  • SWEbench kommt weiterhin nicht aus der Hype-Kontroverse heraus

• Meiner Erfahrung nach ist GLM-4.7 (opencode-Version) unter den Open-Source-Modellen am nächsten dran Man sieht gelegentlich Formulierungen, die wirken, als seien Claude-Daten hineingeraten, daher vermute ich, dass teilweise Claude-Daten genutzt wurden

  • Die Leistung liegt aber noch weit hinter Sonnet 4.5 zurück und ist mit Opus überhaupt nicht vergleichbar
  • Formulierungen wie „What’s your use-case?“ tauchen auch oft auf Das ist ein Ausdruck, den Claude häufig als Ausweichformulierung benutzt, wenn es an Grenzen stößt

• Ein 40B-Parameter-Modell schlägt Sonnet 4.5 und GPT 5.1? Ich frage mich, ob das überhaupt möglich ist

  • Meine Vermutung (ich bin nicht sicher) ist Testdatenleckage oder dass Teile des Benchmark-Sets in den Trainingsdaten enthalten waren Trotzdem ist Sonnet 4.5 bereits ein älteres Modell, und zuletzt gab es viele Innovationen Es ist interessant zu sehen, wie Open Models große Modelle schnell einholen
  • Es gibt sogar schon das Wortspiel, dass der Name „IQuest“ verdächtig klingt (It's questionable)
  • Vielleicht wurden auch Model-Pruning-Techniken eingesetzt. Davon gibt es derzeit viele neue Ansätze
  • Tatsächlich stellte sich heraus, dass der Agent den Evaluierungs-Harness gehackt hat

• Hat irgendjemand dieses Modell selbst ausprobiert oder es über eine gehostete API getestet?

• Das ist eine falsche Behauptung, daher frage ich mich, warum es immer noch auf der Startseite steht