Fünf neue Modelle in dreißig Tagen. Ich habe sie an einem Freitag gezählt, vor einem Stripe-Dashboard sitzend, das ich mit aller Kraft klein halten will, weil ich alleine ein Produkt shippe und „Modellevaluierungsteam" keine Budgetposition ist, die ich habe.
Das ist die Falle, von der niemand warnt, wenn die gesamte Branche jede Woche die Werkzeuge wechselt. Jedem Release nachjagen und man hört auf zu bauen. Man wird zum Vollzeit-Tool-Reviewer, der zufällig noch einen GitHub besitzt. Den Wandel ignorieren und eines Morgens verdoppelt sich die Rechnung, weil ein Anbieter die Abrechnungsbedingungen geändert hat, während man schlief. Beides habe ich gemacht. Also ist das, worüber ich wirklich reden will: Wie ich meinen KI-Coding-Workflow fast jede Woche aktuell halte, ohne die ganze Woche dafür zu opfern.
Der Monat, der meine alten Gewohnheiten brach
Ich gehe einfach mal den Juni 2026 durch, weil es fast komisch ist.
OpenCode überholte Cursor auf Platz 1 in den Dev-Tool-Leistungsrankings, ein Tool, das vor einem Jahr kaum registriert wurde, sitzt jetzt auf einer sechsstelligen GitHub-Sternanzahl. Ein neues Open-Weight-Modell tauchte günstig auf der WebDev Arena auf und unterbot die etablierten Anbieter, die ich bereits bezahlte. GitHub Copilot stellte seine gesamte Basis auf nutzungsbasierte AI Credits um, und der Festpreis war einfach weg. Und Anthropic kündigte eine Abrechnungsaufteilung an, die Agent SDK und claude -p aus den Abonnementgrenzen herausgelöst hätte, verschickte die Claim-Mails, und zog dann die ganze Sache etwa zwei Wochen später zurück nach dem Aufschrei.
Lesen Sie das mit Anthropic noch einmal. Sie veröffentlichten die Ankündigung, öffneten den Claims-Prozess, ließen ihn etwa zwei Wochen laufen, und pausten und überarbeiteten ihn dann nach dem Aufschrei.
Das ist der Job jetzt. Der Boden verschiebt sich ständig unter den Füßen, und die einzige wirkliche Frage ist, welche Teile man anfasst und welche man vollständig in Ruhe lässt.
Was ich in meinem KI-Coding-Workflow jede Woche wirklich überprüfe
Ich habe ein Ritual. Freitagnachmittag, vierzig Minuten, ein Timer damit ich nicht überziehe. Ich prüfe drei Dinge und nichts sonst.
Modell-Routing. Welches Modell macht welchen Job und was kostet mich jedes einzelne. Als das günstige Open-Weight-Modell auftauchte, riss ich nicht meinen ganzen Stack raus. Ich richtete es auf eine langweilige, hochvolumige Aufgabe: Massen-Metadaten-Bereinigung, das, was ich tausende Male pro Woche ausführe. Die Rechnung, die einen Wechsel rechtfertigt, sieht so aus — die Zahlen sind eine Illustration der Mechanik, keine gemessene Abrechnung: ein etabliertes Modell, das bei dieser Aufgabe etwa 180 Dollar im Monat kostet, gegenüber rund 95 für das gleiche Volumen bei einer Qualität, mit der man leben kann. Damit verdient es sich einen Platz für genau diese eine Aufgabe. An meinen Produktcode kam es nicht heran, und das wird sich nicht ändern, bis es sich einen Monat lang an irgendeinem risikoarmen Ort bewährt hat.
Abrechnungsbedingungen. Das ist das, was die meisten Builder überspringen, und es ist das, was tatsächlich beißt. Die Copilot-Änderung war kein Feature-Update, es war ein Schlag auf meine Marge. Als Completions kostenlos blieben, aber Chat, Agenten und CLI anfingen, Credits zu verbrauchen, hatten genau die Dinge, auf die ich den ganzen Tag angewiesen bin, plötzlich einen Zähler. Man muss Abrechnungs-Changelogs so lesen wie Release Notes, weil das für das eigene Portemonnaie genau das ist, was sie sind.
Die Spitze der Rankings. Nicht um launenhaft zu wechseln, nur um das Wetter zu lesen. Dass OpenCode die Charts anführt und dabei modell-agnostisch über Dutzende Anbieter hinweg bleibt, sagt mir: Lock-in verliert, Portabilität gewinnt. Gut zu wissen. Ich schreibe es auf. Ich migriere nichts an einem Freitag, weil sich eine Grafik verschoben hat.
Alle drei sind günstig zu überprüfen und teuer zu ignorieren. Zahlen, Bedingungen und Rankings. Man kann alles in weniger Zeit als einer Kaffeepause scannen.
Was ich bewusst langweilig halte
Das ist mein eigentlicher Vorteil, und er ist fast peinlich öde. Der Großteil meines Stacks bewegt sich überhaupt nicht.
Mein Kernzyklus hat sich seit Monaten kaum verändert: Claude Code im Terminal, meine eigenen Skripte, mein Test-Suite, mein Deploy-Pfad. Die Modelle innerhalb dieses Zyklus wechseln ständig rein und raus. Der Zyklus selbst behält seine Form. Meine Prompts leben in git. Meine Eval-Skripte gehören mir, nicht dem Dashboard irgendeines Anbieters, auf das ich den Zugang verlieren würde. Wenn ein Modell herauskommt, richte ich mein bestehendes Harness darauf und bekomme in etwa zwanzig Minuten eine Zahl zurück. Das Harness ist das, was mich schützt, weit mehr als ein einzelnes Modell.
Genau das ist der Grund, warum die Anthropic-Abrechnungswirren mich nie berührt haben. Mein Workflow setzt keine bestimmte Abrechnungsstruktur voraus. Er setzt voraus, dass ich auf die eine oder andere Weise für Tokens bezahlen werde und verfolgt den Ausgaben selbst. Als die Änderung also angehalten und überarbeitet wurde, hatte ich nichts rückgängig zu machen. Die Menschen, die erwischt wurden, waren diejenigen, die ihre Pipeline an ein Abrechnungsmodell gekoppelt hatten, das zwei Wochen hielt.
Was bleibt konkret eingefroren? Meine Datenschemata. Meine MCP-Server-Schnittstellen. Meine Deploy-Skripte und meine Definition von „fertig." Das sind tragende Teile, also ändere ich sie langsam, bewusst und nur mit einem Grund, den ich laut aussprechen kann. Selbst wenn sich der darunter liegende Standard verschiebt, wie die jüngsten MCP-Spec-Ergänzungen, lese ich die Notizen, archiviere sie und übernehme nur das Stück, das ein Problem löst, das ich heute habe.
Wenn man die eigene Grundlage so behandelt, als ob sie ebenfalls zur wöchentlichen Neubewertung offensteht, hat man eigentlich keine Grundlage. Sein Test-Suite jedes Mal neu schreiben, wenn ein Benchmark wackelt, und irgendwann hat man kein Test-Suite mehr, sondern nur eine Commit-Historie voller Angst.
Die Regel, die ich auf einen Haftzettel gekritzelt habe
Inputs wöchentlich neu bewerten. Schnittstellen stabil halten.
Modelle, Preise, Rankings: das sind Inputs. Sie fließen rein und raus und sind per Design austauschbar, günstig zu testen und günstig zu lassen. Die Schnittstellen zwischen den eigenen Bestandteilen sind das Gebäude: Prompts als Code, das Eval-Harness, die Schemata, der Deploy-Pfad. Man renoviert ein Gebäude. Man reißt es nicht ab, weil das Geschäft gegenüber einen neuen Anstrich bekommen hat.
Als Claude Fable 5 letzten Monat in GA ging, war das ein echter Fortschritt, und ich übernahm es innerhalb einer Woche. Es dauerte einen Nachmittag, weil ich mein bestehendes Harness auf claude-fable-5 richtete, sah, dass die Zahlen in meinen eigenen Evals besser wurden, und es auslieferte. Das ist schnelle Anpassung. Es fühlte sich nur deshalb schnell an, weil alles rund um den Wechsel langweilig, stabil und bereits jahre vor der Existenz von Fable gebaut war.
Wenn also das nächste Fünf-Modelle-in-einem-Monat kommt, und das wird es, wahrscheinlich diesen Monat, mache ich mich nicht darauf gefasst. Ich habe meinen Freitags-Timer und mein langweiliges Rückgrat. Die nächsten vierzig Minuten am Freitag sind bereits in meinem Kalender blockiert. Das Chaos ist nur der Input. Bau zuerst das Harness, halte es stabil, und lass die Modelle dahinter anstehen.