Etwa einen Monat lang habe ich versucht, die proprietären Modelle in unserer Entwicklungspipeline durch Open-Weight-Modelle zu ersetzen.
Diesen Monat hätte ich auch in das Produkt selbst stecken können. Ich bin das Risiko eingegangen, weil jede spezialisierte Rolle in OwlMeans ein Sprachmodell aufruft. Eine Änderung an dieser Stelle schlägt auf den gesamten Entwicklungsablauf durch.
Damals kombinierte unser Preset Modelle von Anthropic und OpenAI. GLM, Kimi, DeepSeek und Qwen habe ich über Hosting-Anbieter ausprobiert. Ich wollte wissen, ob ein anderes Preset dieselbe Arbeit zuverlässig erledigen kann.
Dieses Experiment vom Juni ist kein Benchmark. Einen Kostenvorteil für OwlMeans belegt es nicht.
Unsere Pipeline zerlegt ein Produkt in kleine Teile. Eine Rolle arbeitet an einer User Story, einer Designentscheidung oder einer klar abgegrenzten Codeänderung. Sie bekommt den Kontext für genau diese Aufgabe und nicht den Auftrag, die ganze Anwendung zu erfinden.
Ich dachte, diese Struktur könnte den Modellwechsel einfach machen. Wäre die Aufgabe eng genug gefasst, hätte das Modell vielleicht weniger Gelegenheit, sie misszuverstehen.
Das war eine technische Hypothese, die ich in meinem eigenen System testen konnte. Für einen Solo-Gründer war es aber auch ein verlockender Umweg. Die Maschinerie zu verbessern, kam mir wie ein Gewinn für jedes künftige Projekt vor. So ließ sich leicht noch ein Tag Feintuning rechtfertigen.
Ich musste mir den ganzen Durchlauf ansehen und ebenso die App, die dabei herauskam.
Leere Antworten
Das erste Problem war das Reasoning. Einige Modelle verbrauchten das verfügbare Ausgabebudget für internes Reasoning und lieferten keinen brauchbaren Inhalt zurück. Die Coder-Rolle schloss ihre Anfrage ab, aber die nächste Stufe hatte nichts, was sie anwenden konnte.
Ich habe versucht, das Reasoning über eine Einstellung abzuschalten, die der Anbieter nicht durchgängig beachtete. Danach habe ich den betroffenen Rollen explizite Grenzen gesetzt und sie Modell für Modell angepasst.
Das kostete mehr Aufmerksamkeit, als der Wechsel des Presets vermuten ließ. Eine Planungsrolle und eine Coder-Rolle brauchten nicht dieselbe Behandlung. Eine Einstellung, die bei einem Modell funktionierte, war keine Regel, die ich gefahrlos auf die anderen übertragen konnte.
Das nächste Problem war das Antwortformat. Unsere Stufen reichen einander strukturierte Ergebnisse weiter. Eine Antwort, die mir vernünftig vorkommt, kann trotzdem an dem Schema scheitern, das der nächste Schritt erwartet.
Wo ein Modell die erwartete Struktur nicht zuverlässig zurückgab, habe ich einen Weg über Tool-Aufrufe ergänzt. Außerdem habe ich geändert, wie Code durch die Pipeline wandert. Der Agent arbeitete mit relevanten Ausschnitten und Patches, statt immer wieder ganze Dateien zu verarbeiten.
Diese Änderungen wurden Teil des Systems, das ich pflegen musste. Das Experiment war längst mehr, als ein Modell aus einer Liste zu wählen.
Der Anbieter dazwischen
Ein Modellname legte die Ausführungsumgebung noch nicht vollständig fest. Der Host bestimmte mit, welche Features verfügbar waren und wie sich Anfragen verhielten. Ich habe verschiedene Anbieter getestet. Im experimentellen Preset nutzte ich schließlich das Routing und Failover von OpenRouter.
Die Dokumentation von OpenRouter zum Provider-Routing erklärt, mit welchen Einstellungen man Hosts auswählen und filtern kann. Meine Pipeline war auf eine bestimmte Form der Antwort angewiesen, deshalb kam es auf diese Einstellungen an. Die vollständige Route, die ich nutzte, musste ich trotzdem selbst testen.
Endlich konnte ich zwischen Presets wechseln und dasselbe Projekt durch sie laufen lassen. Hinter diesem Schalter steckten inzwischen allerdings Reasoning-Grenzen, die Verarbeitung der Antworten, das Extrahieren von Code und die Wahl der Anbieter.
Die App am Ende
In diesen Durchläufen waren die entstandenen Anwendungen im Großen und Ganzen ähnlich. Mir fielen Unterschiede im CSS auf und gelegentlich Ergänzungen an der Oberfläche, um die ich nicht gebeten hatte.
Ich habe auch gesehen, wie fähige Modelle eine kleine Aufgabe ausschmückten, obwohl ich eine wörtliche Umsetzung wollte. Das war eine Beobachtung zu meiner Arbeitslast und meiner Konfiguration. Für eine allgemeine Rangliste der Modelle wäre sie eine schwache Grundlage.
Weil ich das System selbst betreibe, musste ich mich mit weniger sichtbaren Unterschieden herumschlagen. Fehlgeschlagene strukturierte Ergebnisse brauchten einen weiteren Versuch, und um Patches, die sich nicht anwenden ließen, musste ich mich kümmern. Selbst ein gewöhnlicher Schritt konnte abbrechen, weil der Anbieter nicht passte. Ein Screenshot vom Ergebnis verschweigt diese Arbeit.
Modelle auszutauschen, bedeutete mehr Arbeit in der Pipeline.
Meine eigene Messung lieferte einen informellen Vergleich. Ich traute ihm aber nicht genug, um daraus eine allgemeine Aussage über die Leistung zu machen.
Die Modelle waren unterschiedlich abgestimmt. Das Verhalten der Anbieter floss ins Ergebnis ein. Durch Wiederholungen und Reparaturschritte zählte der Weg durch einen Durchlauf genauso viel wie das fertige Artefakt.
Für einen ordentlichen Vergleich bräuchte es eine definierte Aufgabe, dieselben Abnahmeprüfungen, eine einheitliche Messung und offen berichtete Fehlschläge. Meine Durchläufe hatten mir technische Notizen geliefert.
Deshalb verzichtet diese Überarbeitung auf die alte Schlagzeile mit der Zahl. Die öffentliche Adresse bleibt gleich, damit bestehende Links weiter funktionieren.
Ich musste trotzdem entscheiden, wofür ich meine Zeit einsetze. Ich konnte das experimentelle Preset weiter abstimmen oder mich wieder dem Rest des Produkts zuwenden. Mehr Messungen hätten nur geholfen, wenn sie eine Entscheidung geklärt hätten, die tatsächlich anstand.
Ein Monat Feintuning
Geblieben ist mir ein funktionierender Weg, verschiedene Modelle auszuprobieren. Außerdem habe ich mehrere Annahmen gefunden, die in der Pipeline versteckt waren: wie eine Rolle ihr Reasoning einsetzt, wie sie ein Ergebnis zurückgibt, wie viel Quellcode sie bekommt und was passiert, wenn ihr Anbieter ausfällt.
Für die Engine, die ich baue, ist das nützliches Wissen. Dass andere Gründerinnen und Gründer dasselbe Experiment wiederholen sollten, beweist es nicht.
Bei einem zweiten Versuch würde ich die Abbruchkriterien früher festlegen. Und ich würde entscheiden, welche Fehlermuster ich verstehen muss, bevor ich noch eine Woche an Einstellungen drehe.
Durch diesen Monat verstehe ich mein eigenes System besser. Dem Rest von OwlMeans hat er dafür gefehlt. Beides gehört in die Bilanz.
Überarbeitet am 15. Oktober 2026. Der Bericht über das Experiment vom Juni bleibt erhalten. Das Verhalten von Modellen und Anbietern hat sich seitdem weiter verändert. Die Beobachtungen oben beschreiben die damaligen Durchläufe.