LLM-Kostenoptimierung mit Prüfung der Codequalität bei jedem Schritt

Eine Rechnung für Coding-Agenten vereint mehrere Kostenarten. Claude Code, OpenAI Codex, OpenCode, Cursor und GitHub Copilot lassen sich jeweils als Seats oder Abonnements beziehen, als nutzungsbasiert abgerechnete Anfragen an ein Modell oder Gateway oder als Kombination aus beidem. Wir schlüsseln Ihre Ausgaben anhand der Rechnungen auf, nicht anhand von Listenpreisen. Außerdem sehen wir uns die Nutzungsgrenzen der Abonnements an, denn auch Drosselung, Gebühren für Mehrverbrauch und blockierte Arbeit haben ihren Preis.

• Seats und Abonnements
• Nutzungsbasiert abgerechnete Anfragen an Modelle und Gateways, einschließlich Tokens
• Kapazität, die Sie reserviert oder fest gebucht haben
• Wiederholte oder abgebrochene Läufe

Eine kleinere Token-Rechnung ist wenig wert, wenn mehr Änderungen abgelehnt werden. Wir rechnen Seats, Abonnements und nutzungsbasiert abgerechnete Anfragen mit Nacharbeit, Reverts und Review-Befunden zusammen und vergleichen, was jede akzeptierte Änderung kostet.

Frei gewordene Kapazität wird erst dann zu Geld, wenn sich die Rechnung ändert. Bei Seats oder reservierter Kapazität geschieht das, wenn sich ein Vertrag oder eine Zuteilung ändert. Sie erfahren, welche Einsparungen auf einer Rechnung ankommen und ab welchem Monat.

Seats und nutzungsbasierte Abrechnung belohnen unterschiedliche Gewohnheiten. Mit einem Seat kostet eine Session am Tag so viel wie zwanzig. Bei nutzungsbasierter Abrechnung steigen die Kosten mit der Größe des Kontexts, der Zahl der Wiederholungen und den parallelen Läufen. Prompt Caching macht wiederkehrenden Kontext günstiger, sofern Anbieter und Tool es anbieten, etwa Anweisungsdateien oder große Quelldateien, die mit jeder Anfrage mitgehen.

Bevor wir einen Plan oder eine Voreinstellung ändern, sehen wir uns an, wie Ihre Teams ihre Tools tatsächlich nutzen. Intensive Nutzer nutzungsbasiert abzurechnen oder gelegentlichen Nutzern einen Seat zu geben, erhöht die Rechnung, statt sie zu senken.

Ihr Plattformteam arbeitet dabei mit uns zusammen, und wir ändern immer nur eine Modellentscheidung auf einmal.

• Ein Katalog freigegebener Modelle, für den eine benannte Person verantwortlich ist
• Standardmodelle und Routing-Regeln für jeden Aufgabentyp, auf Basis von Ergebnissen aus Ihrer eigenen Arbeit
• Zuordnung der Kosten nach Team am Gateway, abgeglichen mit den Rechnungen der Anbieter
• Budgets und Limits, getestet mit parallelen und gestreamten Anfragen, denn ein Limit, das bei einem einzelnen Aufruf hält, kann unter Last versagen
• Ein schriftlich festgelegter Ablauf für Teams, die ein höheres Limit brauchen
• Fallbacks für den Fall, dass ein Anbieter langsam ist oder ausfällt, in Übungen erprobt

OpenCode hält Anbieter und Modell in einer versionierten Konfiguration fest. Über die Rechnung entscheiden trotzdem Ihre Verträge, deshalb gleichen wir die konfigurierten Endpunkte mit Ihren Rechnungen ab.

Wenn ein Workflow ein zweites Modell für das Review hinzunimmt oder Agenten parallel laufen lässt, wird derselbe Repository-Kontext mehrfach gesendet, und jede Wiederholung sendet ihn noch einmal. Wir zählen diese Anfragen pro akzeptierter Änderung und rechnen die Review-Zeit hinzu, die der Workflow Ihre Engineers kostet oder ihnen erspart. Wie wir die Kosten zuordnen, hängt davon ab, wie sie abgerechnet werden: über Rechnungen von Anbietern oder Gateways bei einem Tool wie Kilo, über den Vergleich von Seats mit der tatsächlichen Verbrauchsmessung und über das, was Ihr Plan für die Arbeit von Cloud-Agenten nach Verbrauch abrechnet, etwa Devin-Sessions. Auch wenn er pro Änderung mehr kostet, kann sich ein Workflow lohnen.

Kilo einrichten · Aufgaben an Devin übergeben · pstack in Cursor nutzen

• Ausgaben je Team, Tool und Aufgabe
• Die Kosten einer akzeptierten Änderung vor und nach jeder Umstellung des Setups
• Akzeptanz und Nacharbeit neben den Kosten, damit eine Einsparung nur dort ausgewiesen wird, wo die Qualität stabil geblieben ist