> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2026/w30-model-harness-an-intelligent-routing-vision.md).

# W30-Modell × Harness: Ein Entwurf für intelligentes Routing

Kürzlich las ich Databricks’ Beitrag [„Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase“](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase).

Das Unternehmen erstellt aus bereits gemergten internen PRs Evaluationsaufgaben und vergleicht Modelle und Coding-Agent-Harnesses auf einer realen Codebasis mit Millionen Zeilen. Die wichtigste Erkenntnis: Der Harness verändert das Ergebnis stark. Die Rangfolge der Modelle ist weniger entscheidend.

Databricks führte Aufgaben mit demselben Modell und demselben Thinking Effort über Claude Code, Codex, Pi und weitere Harnesses aus. In einigen Vergleichen war die Qualität nahezu gleich, die Kosten unterschieden sich aber um mehr als den Faktor zwei. Pi übermittelte pro Runde ungefähr ein Drittel des Kontexts und erledigte Aufgaben mit kleinerem Arbeitsbestand und weniger Runden.

Das zeigt, dass wir oft die falsche Frage stellen.

Wir fragen, welches Modell am besten programmiert. Die reale Ausführungseinheit ist inzwischen eine Konfiguration:

> model × harness × thinking effort × tools × policy

Der Harness ist die Umgebung, die den Agenten-Kreislauf trägt. Das Modell setzt die obere Fähigkeitsgrenze. Der Harness bestimmt, wie es die Codebasis versteht, Kontext verwaltet, Werkzeuge aufruft, Ergebnisse prüft und aufhört. Die Leistung entsteht aus dem gesamten Paket.

### Ein Routingdienst für Konfigurationen

Nach der Lektüre dachte ich an einen Dienst mit drei Aufgaben:

1. Aktuelle Kombinationen aus Modell und Harness kontinuierlich evaluieren.
2. Typ, Komplexität und Risiko eingehender Aufgaben erkennen.
3. Automatisch eine unter Qualitäts-, Kosten-, Latenz- und Risikogrenzen Pareto-optimale Konfiguration wählen.

Er pflegt keine statische Rangliste, sondern eine zeitlich veränderliche Karte bedingter Leistung:

> Welche Konfiguration passt für diesen Aufgabentyp in dieser Codebasis unter diesen Bedingungen am besten?

Konfiguration A eignet sich vielleicht am besten für einen Feature-Flag-Wechsel, B für modulübergreifendes Refactoring. C erreicht nur wenige Prozentpunkte mehr Erfolg, kostet aber das Fünffache. Es gibt keinen allgemeinen Sieger, nur lokale Optima für unterschiedliche Aufgabenverteilungen.

Nach Eingang einer Aufgabe ermittelt der Router Merkmale: betroffene Sprachen und Verzeichnisse, erwarteter Änderungsumfang, vorhandene Tests, nötige Codesuche, Umkehrbarkeit und Berechtigungsrisiken. Daraus wählt er eine Konfiguration der aktuell gültigen Pareto-Grenze. Nach Abschluss fließen Testergebnisse, menschliche Nacharbeit, Tokenverbrauch, Laufzeit und Werkzeugspuren zurück in die Evaluation.

So entsteht ein Kreislauf:

> Private Aufgabenmenge → Kombinationen evaluieren → Aufgabe erkennen → Konfiguration wählen → reales Ergebnis → Evaluation aktualisieren

### Drei vorhandene Bausteine

Andere arbeiten bereits in diese Richtung, meist aber auf unterschiedlichen Ebenen.

Die erste Gruppe sind Modellrouter.

[Not Diamond](https://docs.notdiamond.ai/docs/key-concepts) analysiert Eingaben und optimiert unter Modellkandidaten nach Qualität, Kosten oder Latenz. [OpenRouter Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router) wählt ebenfalls nach Aufgabentyp und Komplexität. Not Diamond erlaubt zudem eigene Router auf Basis privater Evaluationsdaten und hat einen Code Router für Coding-Agenten angekündigt.

Der ursprüngliche Entscheidungsgegenstand bleibt überwiegend das Modell. Not Diamond kann eigene Modelle oder agentische Abläufe als Endpunkte verpacken und so technisch auch Kombinationen routen. Der Harness ist aber noch keine eigenständige, beobachtbare und kontinuierlich evaluierte Hauptdimension.

Auch OpenRouter geht über ein gewöhnliches Modellgateway hinaus. Der Pareto Code Router aktualisiert Qualitätsstufen anhand externer Programmierbenchmarks. Auto Exacto passt die Anbieterreihenfolge nach Echtzeitdurchsatz, Erfolg von Werkzeugaufrufen und interner Evaluation an. Damit ist gezeigt, dass Evaluation und Produktionssignale ins Routing einfließen können. Die eigene Codebasis und der Harness des Kunden bleiben jedoch unbekannt.

Die zweite Gruppe sind Plattformen für Evaluation und Beobachtbarkeit.

[Braintrust](https://www.braintrust.dev/articles/best-llm-routers-2026) verbindet in seiner öffentlichen Positionierung Gateway, Experimente, Onlinebewertung, Produktions-Traces und Routing in einem Arbeitsablauf. Teams können Modelle auf realem Traffic vergleichen und ihre Routingregeln nach Genauigkeit, Kosten und Latenz anpassen.

Das liegt nahe an kontinuierlich evaluationsgetriebenem Routing. Die öffentliche Produktdarstellung kreist aber weiterhin um Modelle und Modellendpunkte. Dass Ergebnisse Routing beeinflussen können, heißt noch nicht, dass das System seine Strategie automatisch im Raum Modell × Harness aktualisiert.

Die dritte Gruppe ist die Steuerungsebene für Harnesses.

[Omnigent](https://omnigent.ai/docs/build/harnesses) bietet eine gemeinsame Schicht über Claude Code, Codex, Cursor, Pi und weiteren. Bei gleichem Modell, gleichen Werkzeugen und Regeln lässt sich der Harness mit einer Konfigurationszeile wechseln. Harness und Modell können auch zur Laufzeit getrennt überschrieben werden. Es gibt bereits Policy-Hooks, die teure Modelle nach Aufgabenkomplexität begrenzen. Die im Juli 2026 veröffentlichte Version 0.5.0 fügte intelligentes Routing hinzu, bei dem ein Routing Judge pro Aufgabe ein Modell wählt.

Omnigent liegt diesem Entwurf deshalb am nächsten. Es macht Harnesses austauschbar, kombinierbar und steuerbar. Databricks besitzt außerdem interne PR-Aufgaben und reale Aufrufdaten aus dem Unity AI Gateway. Am Ende des Artikels kündigt das Unternehmen ausdrücklich weitere Beiträge zum intelligenten Routing in Unity AI Gateway und Omnigent an.

Bislang wählt Omnigents öffentlich umgesetztes intelligentes Routing aber nur das Modell innerhalb eines bereits gewählten Harness. Öffentliches Material zeigt noch keine automatische aufgabenbezogene Wahl zwischen Claude Code, Codex und Pi, geschweige denn eine fortlaufende Aktualisierung anhand von PR-Benchmarks. Die Bausteine Kombinationsevaluation, Harness-Abstraktion, Komplexitätserkennung, Modellrouting und Gateway sind sichtbar. Ein eigenständiger externer Dienst, der private Unternehmensaufgaben kontinuierlich über Kombinationen evaluiert und daraus automatisch Modell und Harness wählt, ist noch nicht zu sehen.

Es bleibt also Raum, aber weniger, als es zuerst scheint.

### Schwierig ist vor allem die Evaluation

Der Routingalgorithmus selbst muss nicht der Schutzgraben sein. Schwieriger ist, dauerhaft vertrauenswürdige Vergleiche zu erhalten.

#### 1. Evaluation muss zur konkreten Codebasis gehören

Öffentliche Benchmarks liefern Vorwissen, keine endgültige Unternehmensentscheidung.

Databricks nutzte SWE-bench nicht direkt. Öffentliche Aufgaben könnten in Trainingsdaten enthalten sein und repräsentieren die interne Mischung aus Scala, Go, Rust, Java, Python, Bazel und Protobuf nicht. Stattdessen werden Aufgaben aus kürzlich gemergten menschlichen PRs gewonnen, die ursprüngliche Umsetzung verborgen und die Agentenergebnisse mit vorhandenen Tests geprüft.

Ein wertvoller Router kann deshalb nicht nur eine branchenweite Rangliste verkaufen. Er muss für Code, Tests, Regeln und Aufgabenverteilung jedes Unternehmens eine private Leistungskarte aufbauen.

#### 2. Der Kombinationsraum wächst schnell

Zehn Modelle, fünf Harnesses und drei Stufen Thinking Effort ergeben bereits 150 Konfigurationen. Mit Werkzeugsets, Kontextstrategien und Berechtigungsregeln wird vollständiges Durchprobieren rasch unmöglich.

Das System muss stufenweise evaluieren. Zuerst kleine Stichproben, um klar unterlegene Konfigurationen auszuscheiden, dann mehr Budget nahe der Pareto-Grenze. Neue Modelle und Harnesses werden mit wenigen Probeaufgaben grob eingeordnet. Das ähnelt eher Versuchsplanung und einem Contextual Bandit als einer Rangliste.

#### 3. Komplexität ist kein Etikett am Prompt

Eine einfache Änderung kann durch Codeverantwortung, Abhängigkeiten oder fehlende Tests riskant werden. Komplexität verändert sich auch während der Arbeit. Ein Agent beginnt mit einer Datei und entdeckt später, dass er Protokolle anpassen und Daten migrieren muss.

Eine einmalige Klassifikation am Eingang reicht nicht. Der Router muss Repository-Metadaten lesen und eine Aufrüstung während der Ausführung zulassen. Ein günstiges Modell erkundet zunächst und übergibt bei modulübergreifenden Folgen an ein stärkeres. Ein leichter Harness grenzt das Problem ein und wechselt bei langen Änderungen zu einem mit besserer Kontextverwaltung.

Daraus entsteht die nächste Frage: Wie bewahrt man beim Wechsel brauchbaren Zustand, ohne das Kontextrauschen des bisherigen Harness mitzunehmen?

#### 4. Gute Strategien kosten Erkundung

Gehen alle Aufgaben an den derzeitigen Sieger, fehlen bald Vergleichsdaten. Modellupdates, Preisänderungen und Harness-Entwicklung lassen alte Ergebnisse veralten.

Fortlaufendes Routing braucht deshalb einen kleinen Anteil Erkundung, etwa Canary-Aufgaben oder Offline-Replays neuer Kombinationen. Es muss auch Fehlerursachen unterscheiden: fehlende Modellfähigkeit, misslungene Kontextverwaltung, unbrauchbare Werkzeuge oder instabile Testumgebung dürfen nicht in einer Gesamtnote verschwinden.

Regelmäßige Benchmarks sind nur ein Teil. Daten müssen aktuell bleiben, Ursachen zugeordnet und Erkundungsrisiken kontrolliert werden.

### Wo liegt der Schutzgraben des Produkts?

Gateways und einheitliche APIs werden leicht austauschbar. Dauerhafter Wert entsteht eher aus drei Datenarten.

Erstens der Aufgabenverteilung eines Unternehmens. Welche Aufgaben sind häufig oder teuer, welche Fehlschläge verursachen reale Schäden?

Zweitens Ausführungsspuren ganzer Kombinationen. Wie liest dasselbe Modell über verschiedene Harnesses Kontext, ruft Werkzeuge auf, verbraucht Tokens und korrigiert Fehler?

Drittens dem endgültigen Ergebnis. Bestehen Tests? Wird der PR angenommen? Wie viel ändert ein Mensch nach? Muss die Veröffentlichung zurückgesetzt werden?

Erst verbunden zeigen diese Daten, was günstig und wirksam tatsächlich bedeutet. Optimiert werden die Gesamtkosten vom Eingang der Aufgabe bis zur Annahme. Der Preis eines API-Aufrufs ist nur ein Teil.

So entsteht ein Datenkreislauf. Je länger das System genutzt wird, desto besser versteht es Code und Arbeitsgewohnheiten. Genauere Auswahl erhöht die Bereitschaft, Aufgaben zu übergeben. Mehr reale Ergebnisse verbessern die Auswahl weiter. Modelle und Harnesses bleiben austauschbar, während private Evaluationsbestände und Entscheidungsgeschichte auf der Steuerungsebene bleiben.

### Ein realistischerer Einstieg

Die erste Version sollte nicht sofort den gesamten Coding-Agent-Traffic übernehmen. Besser beginnt sie als Offline-Entscheidungssystem.

1. Repositories und kürzlich gemergte PRs anbinden.
2. Automatisch prüfbare private Aufgaben erzeugen.
3. Wenige Modell-Harness-Konfigurationen regelmäßig erneut ausführen.
4. Kosten-Qualitäts-Grenzen nach Aufgabentyp ausgeben.
5. Zuerst Konfigurationen empfehlen, später risikoarme Aufgaben automatisch routen.
6. Klassifikator und Aufgabensatz mit realen Ergebnissen kalibrieren.

Damit lassen sich zunächst zwei Dinge belegen: Die Kombinationen unterscheiden sich tatsächlich stabil, und die Einsparungen decken die Evaluationskosten.

Ist das nicht der Fall, schafft automatisches Routing nur zusätzliche Komplexität. Ist es der Fall, kann aus dem Empfehlungswerkzeug schrittweise eine Steuerungsebene werden.

### Mein Urteil

Der Bedarf ist real. Die Zahl der Modelle wächst, Harness-Unterschiede beeinflussen Kosten und Qualität unmittelbar, Unternehmen geben aber weiterhin oft allen Aufgaben dasselbe Standardmodell und denselben Agenten. Diese starre Konfiguration verschwendet vermutlich Rechenleistung und ordnet manche Aufgaben der falschen Fähigkeitsstufe zu.

Databricks steht dem vollständigen Kreislauf am nächsten. Omnigent liefert die Harness-Abstraktion, Unity AI Gateway den gemeinsamen Eingang und Aufrufdaten, interne PRs den privaten Evaluationssatz. Der angekündigte nächste Schritt könnte genau die Verbindung zwischen Evaluation und Routing schließen.

Die Chance unabhängiger Unternehmen liegt nicht in einer größeren Modellrangliste. Wertvoller ist eine anbieterneutrale Steuerung für Agentenkonfigurationen: eigene Aufgaben jedes Unternehmens kontinuierlich prüfen, Harnesses als routbare Dimension behandeln und zwischen Qualität, Kosten, Latenz und Risiko nachvollziehbar wählen.

Das Zeitfenster besteht, bleibt aber nicht lange leer. Not Diamond kann agentische Abläufe erweitern, Braintrust Evaluation und Gateway stärker automatisieren, Databricks sein internes System zum Produkt machen. Ein neuer Anbieter muss schnell etwas Konkretes zeigen:

> Auf realen Unternehmenscodebasen ist konfigurationsbezogenes Routing günstiger als der feste Einsatz des stärksten Modells mit Standard-Harness, ohne die endgültige Lieferqualität zu senken.

Lässt sich das verlässlich belegen, verschiebt sich die Wettbewerbseinheit der Coding-Agenten erneut nach oben. Modell und Harness bleiben wichtig. Mehr Wert liegt aber in dem System, das fortlaufend ihre beste Kombination auswählt.

### Quellen

* [Coding-Agenten auf Databricks’ Codebasis mit Millionen Zeilen vergleichen](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase)
* [Omnigent: Harnesses](https://omnigent.ai/docs/build/harnesses)
* [Omnigent: eingebaute Regeln](https://omnigent.ai/docs/policies/builtin)
* [Omnigent v0.5.0](https://omnigent.ai/releases/0.5.0)
* [Databricks: Unity AI Gateway](https://docs.databricks.com/aws/en/ai-gateway)
* [Not Diamond: Grundbegriffe](https://docs.notdiamond.ai/docs/key-concepts)
* [Not Diamond: einen eigenen Router trainieren](https://docs.notdiamond.ai/docs/router-training-quickstart)
* [OpenRouter: Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router)
* [OpenRouter: Pareto Router](https://openrouter.ai/docs/guides/routing/routers/pareto-router)
* [OpenRouter: Auto Exacto](https://openrouter.ai/docs/guides/routing/auto-exacto)
* [Braintrust: LLM-Router und Modellrouting-Plattformen 2026](https://www.braintrust.dev/articles/best-llm-routers-2026)