Der Zähler lief die ganze Zeit

Der Zähler, auf den niemand geschaut hatte

Der erste Schritt kostete nichts. Copilot zeigte die Kosten bereits an. Die Informationen lagen nur an einer Stelle, die kaum jemand beachtete. Gemeinsam mit dem Projektteam aktivierten wir den Live-Zähler für Credits, die Anzeige der exakten Kosten beim Darüberfahren und die Auswertung pro Session, die mit VS Code 1.126 eingeführt worden war. Damit konnte ein Entwickler in Echtzeit verfolgen, wie eine einzelne Chat-Session mehr als vierzehn Credits verbrauchte.

Wir hatten mit verhaltenem Interesse gerechnet. Stattdessen entstand spürbares Unbehagen. Und genau das war hilfreich.

Wer die Zahl während der Arbeit steigen sieht, nimmt Kosten anders wahr als in einer Abrechnung drei Wochen später. Die Kosten bleiben damit nicht länger ein abstraktes Thema für Finance, sondern werden direkt mit der eigenen Entscheidung verknüpft. Niemand sieht gerne dabei zu, wie ein Zähler weiterläuft. Genau deshalb wirkt er.

Der unbequeme Teil

Dann kam die schwierigere Frage: Braucht diese Aufgabe wirklich das teuerste Modell?

Über Monate war es üblich gewesen, automatisch das leistungsfähigste Modell auszuwählen und nicht weiter darüber nachzudenken. In einem Team mit mehreren Dutzend Entwicklern wurde genau dieser Reflex zur teuersten Gewohnheit des Projekts.

Die Unterschiede waren deutlich. Im Vergleich zum leistungsstärksten Reasoning-Modell kostet das Modell für alltägliche Aufgaben rund 83 Prozent weniger, die ausgewogene Variante etwa 60 Prozent weniger. Für Dokumentation, Boilerplate-Code und routinemäßige Refactorings braucht es kein Frontier-Modell, das komplexe Architekturfragen durchdringen kann. Deshalb empfahlen wir dem Team, die automatische Modellauswahl zu nutzen und das leistungsstärkste Modell bewusst einzusetzen, statt reflexartig darauf zurückzugreifen.

An diesem Punkt wurde die Diskussion persönlich. Der Hinweis, ein günstigeres Modell zu wählen, kann sich wie eine Herabstufung anfühlen. Manche verstanden ihn genau so. Dahinter steckt eine nachvollziehbare Sorge: Ein günstigeres Modell liefert schlechtere Ergebnisse und beeinträchtigt damit die eigene Arbeit.

Einem erfahrenen Entwickler zu sagen, dass seine bevorzugte Arbeitsweise teuer ist, kommt selten gut an. Entscheidend war deshalb keine neue Richtlinie, sondern die Kombination aus dem sichtbaren Zähler und einer klaren Einordnung:

Das Frontier-Modell ist nicht die Belohnung, sondern die Eskalationsstufe.

Es kommt zum Einsatz, wenn das Problem es rechtfertigt. Bei den meisten Aufgaben ist das nicht der Fall. 

Die Sicherung im System

Ein gemeinsamer Credit-Pool birgt die Gefahr, dass Einzelne mehr verbrauchen, als für das gesamte Team tragbar ist. Deshalb gab es zwei Grenzwerte, die leicht verwechselt werden können, obwohl sie völlig unterschiedliche Aufgaben erfüllen.

Der erste Wert beschreibt, welche Nutzung pro Person bereits abgedeckt ist: rund 30 US-Dollar im Monat. Davon entfallen 19 US-Dollar auf die Business-Lizenz, weitere 11 US-Dollar auf eine Promotion. Vergleichbar ist das mit dem enthaltenen Datenvolumen eines Mobilfunktarifs. Diese Nutzung ist bereits bezahlt.

Der zweite Wert ist eine feste Obergrenze von 500 US-Dollar, dargestellt als 50.000 Credits. Dabei handelt es sich nicht um ein Budget, sondern um einen Schutzschalter. Sobald dieser Wert erreicht ist, wird Copilot vollständig gestoppt. So kann eine einzelne Person nicht allein den gemeinsamen Projekt-Pool aufbrauchen.

Entscheidend ist der Bereich zwischen diesen beiden Werten. Wer mehr als die enthaltenen 30 US-Dollar verbraucht, wird nicht gesperrt. Copilot läuft weiter, doch die zusätzlichen Credits werden aus dem gemeinsamen Pool bezahlt und verursachen reale Projektkosten. Erst bei 500 US-Dollar greift die harte Grenze.

Auch hier hilft der Vergleich mit einem Mobilfunktarif: Nach Verbrauch des enthaltenen Datenvolumens bleibt die Verbindung bestehen, die weitere Nutzung wird jedoch dem Unternehmen berechnet. Die Grenze von 500 US-Dollar verhindert lediglich, dass eine einzelne Person unkontrolliert hohe Kosten verursacht.

Deshalb hatte der kleinere Wert im Alltag die größere Wirkung. Fast niemand näherte sich der Grenze von 500 US-Dollar. Sobald jedoch klar war, dass ab dem 31. Dollar Geld aus dem gemeinsamen Budget floss, änderte sich das Verhalten. Dafür brauchte es keine Kontrolle und keine Sanktionen. Die Obergrenze von 500 US-Dollar schützte vor Ausnahmefällen. Die Schwelle von 30 US-Dollar beeinflusste die täglichen Entscheidungen.

Führte die Obergrenze gelegentlich zu Einschränkungen? Ja. In einzelnen Fällen musste jemand eine berechtigte Session unterbrechen und eine Erhöhung beantragen. Das war unangenehm, und wir wollen es nicht beschönigen. Eine Grenze, die nie spürbar wird, hat jedoch kaum eine Wirkung. Ohne sie hätte eine einzige aus dem Ruder laufende Session den Pool für das gesamte Team aufbrauchen können. Die bewusst gesetzte Hürde erfüllte also ihren Zweck.

Die Schutzregel gab den Entwicklern ausreichend Spielraum und verhinderte zugleich, dass eine einzelne unkontrollierte Session den gemeinsamen Pool belastete.

Eine weitere, kleinere Regel wirkte ebenfalls. Wir wiesen KI-Agenten an, ihre Arbeit zu beenden, sobald das Akzeptanzkriterium erfüllt war. Ein offen laufender Agent arbeitet sonst weiter und verursacht weitere Kosten, obwohl das Ergebnis längst erreicht ist. Auch den automatisch freigegebenen Agent Mode begrenzten wir stärker. Ein unbeaufsichtigter Agent, der in die falsche Richtung arbeitet, kann Budget besonders schnell verbrauchen, ohne etwas Brauchbares zu liefern.

Auch ein autonom arbeitender Agent braucht eine klar definierte Aufgabe und einen eindeutigen Endpunkt. Fehlt eines von beidem, läuft die Aktivität weiter, während sich immer schwerer nachvollziehen lässt, wer für die Ergebnisse und Kosten verantwortlich ist.

Was geblieben ist und was noch offen bleibt

Wir können keine belastbare Prozentzahl veröffentlichen. Selbst wenn wir es könnten, würden wir ihr nur eingeschränkt vertrauen. Die nachhaltige Veränderung war weniger spektakulär. Die Modellauswahl wurde nicht länger ignoriert. Entwickler begannen, ihre Entscheidung im jeweiligen Moment zu treffen, statt die Folgen erst am Monatsende zu sehen. Und die zentrale Frage im Team veränderte sich. Statt „Dürfen wir das überhaupt nutzen?“ hieß es nun: „Wie holen wir mehr aus jedem Credit heraus?“

„KI Credits machen eine grundlegende Realität des KI-Einsatzes in Unternehmen sichtbar: Technologie allein schafft keinen Wert. Wert entsteht, wenn Menschen die Zielkonflikte hinter ihren Entscheidungen verstehen und bewusst das passende Tool für die jeweilige Aufgabe wählen. Diese Fähigkeit in der gesamten Belegschaft aufzubauen, wird ebenso wichtig sein wie die Auswahl der richtigen KI-Plattform.“ -Björn Kasten, Partner, MHP

Eine Frage bleibt dennoch offen. Wir können inzwischen sehr genau sehen, wofür Geld ausgegeben wird. Es gelingt uns jedoch noch nicht, ebenso klar nachzuweisen, welchen Gegenwert diese Ausgaben schaffen. Wir können sagen, dass die Credits effizienter genutzt werden. Noch fehlt jedoch eine Kennzahl, die belegt, dass das erzielte Ergebnis die Kosten tatsächlich rechtfertigt.

Die Lücke zwischen Kostentransparenz und Werttransparenz zu schließen, ist der nächste Schritt. Genau dort setzt die weitere Arbeit an.

Als die Umstellung auf KI Credits eingeführt wurde, wirkte sie zunächst wie eine Sanktion. Tatsächlich erzeugte sie einen hilfreichen Druck. Innerhalb einer Woche lernte ein ganzes Engineering-Team, was eine Anfrage kostet und wann sich der Einsatz eines teureren Modells lohnt. Dieses Urteilsvermögen ist das eigentliche Ergebnis. Die eingesparten Credits sind lediglich der Beleg dafür.

Je stärker KI zum festen Bestandteil von Engineering und industrieller Arbeit wird, desto wichtiger wird diese Fähigkeit auch über eine einzelne Copilot-Lizenz hinaus. Digitale Souveränität beginnt damit, zu verstehen, wie KI eingesetzt wird, um jederzeit den Kurs ändern zu können.

Bei MHP verstehen wir Plattformen als technologische Grundlage. Die Teams, die mit ihnen arbeiten, müssen weiterhin die Regeln festlegen und Verantwortung für ihre Entscheidungen übernehmen. Wir unterstützen Organisationen dabei, diese Praxis zu etablieren und die Verantwortung dort zu belassen, wo sie hingehört.

Der erste Schritt ist einfach: Prüfen Sie, wo KI-Kosten heute bereits sichtbar sind und an welchen Stellen Modelle noch automatisch oder aus Gewohnheit ausgewählt werden. Daran lässt sich schnell erkennen, wo erste Leitplanken notwendig sind.

Die grundlegende Argumentation zu KI FinOps, auf der dieses Praxisbeispiel aufbaut, finden Sie im ersten Teil der Reihe.