Etwa einen Monat lang habe ich versucht, unsere proprietären Modelle durch Open-Weight-Modelle zu ersetzen.
Nicht im gesamten Unternehmen — nur im Maschinenraum. OwlMeans ist eine KI-Entwicklungs-Pipeline: Sie beschreiben als User Stories, was Sie wollen, und ein Team aus spezialisierten KI-Rollen macht daraus eine vollständige Full-Stack-App, die Ihnen gehört. Unter der Haube ruft jede dieser Rollen ein Sprachmodell auf. Heute ist das eine Kombination aus Anthropic- und OpenAI-Modellen — Claude erledigt den Großteil der schweren Arbeit, OpenAI ist für bestimmte Rollen mit dabei. Es ist ein Setup, dem ich vertraue. Es hat aber auch einen Preis.
Also habe ich das naheliegende Experiment gemacht. Die Open-Weight-Modelle hatten ein sehr lautes Jahr — bis Mitte 2025 kamen die besten Open-Weight-LLMs aus China, und GLM, Kimi, Qwen und DeepSeek lieferten sich beim Coding ein Kopf-an-Kopf-Rennen mit der proprietären Spitzenklasse. Sie kosten nur einen Bruchteil. Wenn ich meine Pipeline auf Open Weights laufen lassen könnte, ohne dass das Ergebnis schlechter wird, war die Rechnung unwiderstehlich.
Ich habe den Monat damit verbracht, sie einzubinden, zu benchmarken und zu tunen. Hier ist, was tatsächlich passiert ist — einschließlich des Teils, den ich nicht erwartet hatte und der sich als der eigentliche Punkt herausstellte.
Die Wette: Die Pipeline sollte das Modell austauschbar machen
Hier ist das, was mich überhaupt glauben ließ, dass das funktionieren würde.
OwlMeans übergibt einem Modell keinen vagen Prompt und betet dann. Es zerschlägt ein Projekt in sehr kleine, eng umrissene Aufgaben, die jeweils mit sehr wenig Kontext laufen — eine einzelne User Story, ein einzelner Fix, die Änderung an einer einzelnen Datei. Eine Business-Analyst-Rolle steckt die Arbeit ab, ein Architekt entwirft sie, eine Entwickler-Rolle setzt einen Ausschnitt um, ein Fixer räumt auf. Niemand bittet ein einzelnes Modell, „die App zu bauen”. Man bittet es, eine kleine, genau spezifizierte Sache zu tun.
Dieses Design hat einen stillen Nebeneffekt: Je kleiner und genauer spezifiziert die Aufgabe ist, desto weniger spielt die Wahl des Modells eine Rolle. Wenn der Kontext winzig und die Anweisung exakt ist, landet fast jedes kompetente Modell ungefähr am selben Punkt. Es gibt weniger Raum, brillant zu sein, und weniger Raum, abzuschweifen. Genau deshalb bleiben auch unsere Token-Kosten vernünftig — die Forschung zu Agent-Loops ist unmissverständlich, dass die Token-Kosten mit dem Quadrat des Kontexts wachsen, den man bei jedem Schritt erneut abrechnet. Jede Aufgabe klein zu halten ist also der Unterschied zwischen einer tragbaren und einer ausufernden Rechnung.
Meine Hypothese war also einfach: Wenn die Pipeline die Aufgabe bereits zur Massenware macht, sollte sie auch das Modell zur Massenware machen. Tausche ein proprietäres Modell gegen GLM aus, und die App, die hinten herauskommt, sollte im Grunde dieselbe App sein.
Damit lag ich größtenteils richtig. Und es spielte nicht so eine Rolle, wie ich gehofft hatte.
Was zuerst brach: die Modelle, die zu viel nachdenken
Der Open-Weight-Weg verlief nicht sanft.
Die erste Mauer waren die „Thinking”-Modelle. GLM, Kimi, Qwen — sie schlussfolgern standardmäßig. Das klingt großartig, bis man die Ausgabe hart begrenzt und das Modell sein gesamtes Budget mit stillem Schlussfolgern verbraucht und dann nichts zurückgibt. Leerer Inhalt. Die Coder-Rolle würde feuern, das Modell würde sich bis an die Token-Grenze denken und einen leeren String zurückgeben. Die Pipeline würde an einer Nicht-Antwort ersticken.
Ich setzte effort: none. Es wurde stillschweigend ignoriert. Das Modell dachte weiter nach.
Das ist keine Eigenart, die nur bei mir auftritt — es ist das schmutzige Geheimnis von Reasoning-Modellen in der Produktion. Der Reasoning-Aufwand ist, wie es ein guter Artikel formuliert, ein Kosten-Regler, kein Qualitäts-Regler: Dreht man ihn auf, kann man seine Thinking-Token für ein paar Benchmark-Punkte verdreifachen, und man bekommt Abrechnungsüberraschungen und leere Ausgaben, wenn das Reasoning genau den Platz auffrisst, in dem die Antwort eigentlich hätte leben sollen. Die Lösung war unspektakulär: ein hartes, absolutes Limit für Reasoning-Token pro Rolle, Modell für Modell abgestimmt, damit das Nachdenken die Ausgabe nicht aushungern kann. Coder bekommen eine kurze Reasoning-Leine; die Planungsrollen bekommen mehr Spielraum. Es gibt keine universelle Einstellung. Jedes Modell wollte seine eigene.
Die zweite Mauer war die strukturierte Ausgabe. Meine Pipeline stützt sich darauf, dass Modelle sauberes, schemavalides JSON zurückgeben, damit die nächste Stufe darauf reagieren kann. Proprietäre APIs sind darin inzwischen sehr gut — OpenAIs strikter Structured-Output-Modus drückt Formatfehler unter 0,1 %. Viele Open-Weight-Modelle sind, bei vielen Anbietern, noch nicht so weit. Sie produzieren bei einem nennenswerten Teil der Antworten fehlerhaftes JSON, besonders bei langen Ausgaben und verschachtelten Schemata. Also habe ich aufgehört, den wackligen Modellen JSON aufzuzwingen, und sie stattdessen Tool-Calls nutzen lassen, und ich habe die Quellcode-Behandlung neu geschrieben, sodass der Agent nur die relevanten Snippets extrahiert und Patch-Diffs anwendet, statt ganze Dateien neu zu schreiben. Kleinerer Kontext, weniger Gelegenheiten, das Format zu brechen. Diese eine Änderung hat mehr für die Open-Weight-Zuverlässigkeit getan als jeder Modellwechsel.
Die dritte Mauer waren die Anbieter selbst. Dasselbe offene Modell verhält sich unterschiedlich, je nachdem, wer es hostet — Geschwindigkeit, Zuverlässigkeit, sogar die Frage, ob strukturierte Ausgabe überhaupt funktioniert. Ich habe einen ganzen Stapel davon gebenchmarkt. Einige waren großartig. Einige scheiterten bei jedem Call an der Schemavalidierung. Einige kürzten ab. Ein paar konnten die Modelle, die ich brauchte, schlicht nicht bereitstellen. Am Ende habe ich über OpenRouter geroutet, das jedes Modell über sechzehn bis über zwanzig zugrunde liegende Anbieter verteilt und zwischen ihnen umschaltet — und ich habe mich auf seine :nitro-Variante gestützt, die Anbieter nach reinem Durchsatz sortiert, um Geschwindigkeit zurückzuholen. Am Ende konnte ich die gesamte Pipeline mit einem einzigen Flag zwischen einem Open-Weight-Preset und einem proprietären umschalten und dasselbe Projekt durch beide laufen lassen.
Dieser Schalter ist es, der mir endlich einen ehrlichen Vergleich ermöglichte. Und beim Vergleich wurde es interessant.
Die Überraschung: Die Ausgabe war im Grunde gleich
Ich hatte erwartet, dass die offenen Modelle sichtbar schlechteren Code produzieren würden. Taten sie nicht.
Weil die Pipeline alles in winzige Aufgaben zerlegt, fiel das Endergebnis über alle Modelle hinweg nahezu gleich aus. Dieselbe Struktur, dasselbe Verhalten, dieselbe App. Die Unterschiede waren klein und fast ästhetisch — meist die CSS-Qualität und die gelegentliche Verzierung. Und hier ist der Teil, den ich wirklich komisch finde: Die fortgeschritteneren Modelle waren die schlimmeren Übeltäter. Gib einem Spitzenmodell eine kleine, exakte Aufgabe, und es wird kreativ — fügt der UI eine Spielerei hinzu, nach der niemand gefragt hat, entscheidet, dass dein Formular eine Animation braucht. Haiku macht einfach das Ding. Je intelligenter das Modell, desto wahrscheinlicher improvisiert es, wenn Improvisieren genau das ist, was du nicht willst.
Die Qualitätsfrage — die, um die alle auf Benchmark-Leaderboards kämpfen — löste sich also größtenteils in Luft auf. Was mich vor zwei Achsen stehen ließ, und nur zwei: Preis und Geschwindigkeit.
Und ich würde behaupten, das ist der ehrliche Ort, an dem diese ganze Branche landen sollte. Die neutralen Datenanbieter trennen die Modelle bereits genau entlang dieser Linien — Intelligenz, Geschwindigkeit und Preis als drei verschiedene Spalten —, denn sobald die Intelligenz für die Aufgabe „gut genug” ist, sind Geschwindigkeit und Preis das, womit man tatsächlich lebt.
Wo die günstigen Modelle aufhören, günstig zu sein
Auf dem Papier gewinnen Open Weights beim Preis erdrutschartig. Sie kosten einen Bruchteil dessen, was das Anthropic-und-OpenAI-Preset pro Token kostet. Das ist der einzige Grund, das überhaupt zu tun.
Aber der Preis pro Token ist eine Falle, und ich bin geradewegs hineingetappt.
Auf der proprietären Seite tragen die Anthropic-Modelle den Großteil der Last — und Sonnet und Haiku machen weniger Fehler und inferieren schneller als das, was ich über OpenRouter bekomme, selbst mit aktiviertem Nitro. Pro Anfrage ist der Geschwindigkeitsunterschied nicht dramatisch. Er summiert sich. Und die Fehler sind die eigentliche Steuer: Mit dem Open-Weight-Preset muss der Agent öfter anhalten und Dinge korrigieren. Hier eine fehlerhafte JSON-Rückgabe, dort ein verwirrtes Diff, ein Retry, eine Neuplanung. Jedes davon bedeutet mehr Token und mehr Echtzeit.
Das ist die Rechnung, die niemand auf die Preisseite schreibt. Ein Modell, das pro Token fünfmal günstiger ist, aber Retries braucht, ist in der Praxis nicht fünfmal günstiger — eine Fehlerquote von 20 % pro Schritt verdoppelt die Token-Rechnung ungefähr, und in einem agentischen Loop summieren sich diese Fehler über die Schritte hinweg. Die ganze Branche lernt gerade leise wieder, dass günstigere Token größere Rechnungen produziert haben, weil die Retries die Ersparnisse bei lebendigem Leib auffressen.
Genau das habe ich beobachtet. Der Preisvorteil auf dem Zähler wurde vom Anhalten-und-Korrigieren-Loop zerkaut. Und als ich alles zusammenrechnete — die langsamere Inferenz, die zusätzlichen Retries, die Neuplanung —, ergab sich die reale Lücke zwischen meinem proprietären Preset und meinem Open-Weight-Preset zu etwa 5x. Nicht auf einem Benchmark. Bei der tatsächlichen Arbeit, von Anfang bis Ende.
Um klarzustellen, was ich nicht behaupte: Das heißt nicht, dass Open Weights schlecht sind. Es heißt: Open Weights, in meiner Pipeline, heute, bei den Anbietern, die ich getestet habe, mit dem Tuning, das ich bisher gemacht habe. Womit ich zu dem Teil komme, bei dem ich am wenigsten sicher bin.
Warum ich meinen eigenen Zahlen noch nicht traue
Hier ist das unangenehme Eingeständnis. Ich habe eine 5x-Zahl. Ich traue ihr nicht ganz, und ich finde, Sie sollten es auch nicht — nicht weil sie falsch ist, sondern wegen der Art und Weise, wie solche Dinge üblicherweise gemessen werden.
Die Benchmark-Ära bricht vor aller Augen zusammen. Die gängigen Coding-Benchmarks sind gesättigt und kontaminiert; das Feld hat 2025 dabei zugesehen, wie die Bewertungsskala aufhörte, reale Fähigkeit widerzuspiegeln. Und die bequeme Abkürzung, zu der alle greifen — ein starkes Modell die Ausgabe bewerten zu lassen — ist selbst unzuverlässig: LLM-as-Judge zeigt große, reihenfolgeabhängige Varianz bei Coding-Aufgaben. Ein Spitzenmodell zu fragen, ob der Code eines anderen Modells gut ist, ist kein Beweis. Es ist ein Bauchgefühl mit Konfidenzintervall.
Mein nächster Schritt ist also kein weiterer Benchmark. Es ist, mir den tatsächlichen Code anzuschauen, den diese Modelle vibe-codet haben, mit eigenen Augen und echten Metriken — baut er, besteht er die Tests, ist er wartbar, würde ich ihn besitzen wollen. Es ist durchaus möglich, dass GLM und Kimi am Ende bessere Gesamtergebnisse liefern, wenn ich das echte Artefakt beurteile statt eines synthetischen Werts. Es ist auch möglich, dass die offenen Modelle einfach noch nicht richtig getunt sind — die Reasoning-Budgets und das Dutzend kleiner Stellschrauben brauchen mit ziemlicher Sicherheit eine modellspezifische Anpassung, und ich habe daran nur gekratzt. Meine ehrliche Erwartung: In dem Moment, in dem man sich von synthetischen Benchmarks wegbewegt und anfängt, echte Ausgaben zu vergleichen, wird das ganze Bild trüber, nicht klarer.
Ich werde weitergraben. Aber der Monat hat mir das beigebracht, worauf es wirklich ankommt, und das ist kein Modell.
Die Lektion, die mehr wert ist als das Ergebnis
Treten wir einen Moment vom Leaderboard zurück.
Alles, was Open Weights in meiner Pipeline nutzbar machte — die modellspezifischen Reasoning-Limits, damit das Nachdenken die Ausgabe nicht aushungert, der Tool-Calling-Fallback für wackliges JSON, die Snippet-Extraktion und die Patch-Diffs, die den Kontext schrumpfen, das Provider-Failover und das Durchsatz-Routing, die rollenspezifischen Modellzuweisungen — nichts davon ist das Modell. Es ist die Struktur um das Modell herum. Es ist ein Monat unspektakuläre Ingenieursarbeit, die zwischen „günstige Token existieren” und „du hast funktionierende Software ausgeliefert” sitzt.
Das ist eigentlich das ganze Produkt. Ein Coding-Agent ist ein Coding-Agent — kein Software-Entwicklungsteam. Das Modell ist eine Massenware; man kann es morgen austauschen, und nach diesem Monat kann ich Ihnen genau sagen, wie viel der Austausch tatsächlich bringt. Der Wert war nie das Modell. Der Wert ist die Pipeline, die jedes Modell dazu bringt, Code zu produzieren, den Sie besitzen und warten können — und die die Retries, die Formatfehler, das modellspezifische Tuning abfängt, sodass Sie sie nicht mit Ihren Wochenenden bezahlen.
Das ist dasselbe Versprechen, das OwlMeans seinen Kunden gibt, und ich habe gerade einen Monat damit verbracht, es mir von innen heraus selbst zu beweisen: OwlMeans ist das Team um den Agenten herum. Sie beschreiben Ihr Produkt als User Stories. Die Pipeline zerlegt es, führt es aus, korrigiert es und übergibt Ihnen ein typisiertes Monorepo, das Ihnen gehört — Code, an dem Sie mit jedem beliebigen Agenten weiterbauen. Die Kosten sind pro Story vorhersehbar, weil die Pipeline das ist, was sie vorhersehbar macht.
Sie können sich meinen Monat sparen
Hier also der ehrliche Pitch, und ich mache ihn so, wie ich ihn mir selbst gemacht haben wollte.
Wenn Sie ein echtes Produkt vibe-coden, werden Sie genau vor dieser Frage stehen — welches Modell, welcher Anbieter, wie halte ich die Rechnung niedrig, ohne dass die Ausgabe auseinanderfällt. Sie können tun, was ich getan habe: Wochen damit verbringen, Presets zu verdrahten, herauszufinden, dass effort: none eine Lüge ist, zuzusehen, wie Ihre günstigen Token sich in Retries verflüchtigen, und Modell für Modell zu lernen, was tatsächlich stimmt. Für mich war es das wert, denn diesen Motor zu bauen ist mein Job.
Es ist nicht Ihr Job.
Sie können die Pipeline, die diesen Kampf bereits ausgefochten hat, für sich arbeiten lassen — die Modellökonomie wählen, die Retries schlucken, die Struktur durchsetzen und Ihnen besitzbaren, wartbaren Code mit vorhersehbaren Kosten pro Story zurückgeben. Das ist das Angebot. Ich habe einen Monat und eine Menge Token verbrannt, um die 5x zu finden. Sie können einfach die Pipeline haben.
Wenn das Problem darin besteht, beim Vibe-Coding Zeit und Token zu sparen, ist dies der günstigste Monat F&E, den Sie nie selbst durchlaufen müssen.
OwlMeans ist eine KI-Entwicklungs-Pipeline: Beschreiben Sie als User Stories, was Sie wollen, und erhalten Sie Full-Stack-Apps, Chatbots, KI-Agenten und Datenpipelines — typisiert, SSO-bereit und Ihr Eigen, um damit mit jedem beliebigen Agenten weiterzubauen. Sehen Sie, was sie kann →