Copilot Cowork: Warum dein Copilot-Abo nur noch die halbe Rechnung ist

Seit dem 16. Juni ist Copilot Cowork allgemein verfügbar, und damit ändert sich etwas Grundsätzliches daran, wie Microsoft KI-Nutzung abrechnet. Das feste Abo pro Kopf bleibt. Aber die eigentliche Arbeit, die Cowork erledigt, kostet ab jetzt extra, und zwar nach Verbrauch. Wer in den letzten Monaten fleißig Agenten gebaut hat, weil das im Abo ohnehin inklusive war, muss umdenken.

Wir halten das nicht für eine Fußnote in den Release Notes. Es ist der erste Punkt, an dem nutzungsbasierte Abrechnung im Kern von Microsoft 365 ankommt, und der Mittelstand wird daran nicht vorbeikommen. Was sich konkret ändert, was belegt ist und was du vor dem Rollout entscheiden solltest, steht hier.

‍

Was sich mit Copilot Cowork konkret ändert

Cowork ist Microsofts Agenten-Schicht in Microsoft 365 Copilot. Du beschreibst ein Ergebnis, Cowork erledigt die mehrstufige Arbeit quer über Mails, Dateien, Teams und angebundene Systeme und liefert ein fertiges Resultat, nicht nur einen Entwurf. Seit dem 16. Juni 2026 ist die Funktion weltweit allgemein verfügbar [1].

Die Abrechnung läuft jetzt zweigeteilt. Die Microsoft-365-Copilot-Lizenz, rund 28 Euro pro Nutzer und Monat, bleibt der feste Teil und der Einstieg. Die Cowork-Arbeit kommt nutzungsbasiert oben drauf, abgerechnet in sogenannten Copilot Credits, bei Pay-as-you-go zu 0,01 US-Dollar pro Credit [4]. Der Preis pro Aufgabe ergibt sich aus vier Faktoren: welches Modell läuft, wie viel Kontext geholt wird, wie viele Tool-Aufrufe nötig sind und wie lange die Aufgabe läuft [5]. Eine kurze Aufgabe auf einem leichten Modell ist günstig. Eine lange Recherche über viele Tools auf dem stärksten Modell kostet spürbar mehr.

Zwei Dinge solltest du dir merken. Erstens: Cowork ist standardmäßig aus. Niemand verbraucht etwas, bis ein Admin die Funktion aktiviert und Budgets setzt, und zwar wahlweise auf Ebene des gesamten Tenants, einzelner Gruppen oder einzelner Nutzer [1]. Zweitens der Stichtag. Wer Cowork in der Frontier-Preview genutzt hat, hat eine Schonfrist: Vom 16. bis 30. Juni läuft Cowork für ihn weiter ohne Abrechnung, ab dem 1. Juli verliert ein Tenant ohne aktiviertes Billing den Zugriff auf Cowork komplett [1]. Wer das verschläft, verliert die Funktion, nicht nur den Überblick.

‍

‍

Vom Flatrate-Abo zum Verbrauchsmodell, und warum das kein Microsoft-Sonderweg ist

Wer das nur als Microsoft-Preiserhöhung liest, verpasst das eigentliche Muster. Drei der wichtigsten Anbieter haben innerhalb von gut zwei Wochen denselben Schritt gemacht. GitHub Copilot ist zum 1. Juni auf nutzungsbasierte Abrechnung umgestiegen, bei Claude Code wurde die agentische Nutzung zum 15. Juni in einen eigenen, verbrauchsabhängigen Topf verschoben, und Copilot Cowork folgt zum 16. Juni [5]. Das ist kein Zufall.

Der Hintergrund ist simpel. Wir kommen aus einer Phase, in der vieles faktisch quersubventioniert war: festes Abo, dahinter mehr oder weniger freie Nutzung. Für die Anbieter rechnet sich das bei langlaufenden Agenten nicht, weil ein Agent, der minutenlang über Modelle und Tools arbeitet, echte Rechenleistung frisst. Die Subventionsphase für agentische Last geht zu Ende, und Verbrauchsabrechnung ist der Weg, den die Anbieter jetzt einschlagen. Bei Microsoft ist das Prinzip nicht einmal neu: Wer mit Copilot Studio Agenten gebaut oder Workloads in der Power Platform betrieben hat, zahlt dort längst nach Verbrauch, abgerechnet in denselben Copilot Credits. Neu ist, wo das jetzt ankommt, nämlich im alltäglichen Microsoft 365 Copilot, den eure Leute ohnehin nutzen. Cowork ist also kein Einzelfall, sondern der Punkt, an dem dieses Abrechnungsmodell im Alltag der Copilot-Nutzer ankommt.

Nicht alle ziehen mit, zumindest noch nicht. Cursor hat seine Preise vorerst unverändert gelassen, und für manche Teams ist genau das gerade ein Argument. Für dich heißt das: Das Modell setzt sich durch, aber es ist nicht alternativlos. Es lohnt sich, beim eigenen Stack genau hinzusehen, statt jede Umstellung mitzumachen.

‍

Jeder Use Case braucht ab jetzt einen Business Case

Solange Agenten im Abo inklusive waren, war die Frage einfach: Geht das technisch? Wenn ja, wurde gebaut. Ob der Agent zweimal im Monat oder fünfzigmal am Tag lief, war egal, die Kosten standen ohnehin fest.

Das kippt jetzt. Jede Ausführung kostet. Damit wird aus einer technischen Frage eine betriebswirtschaftliche: Lohnt sich dieser Use Case? Ein Agent, der einen mühsamen Vertragsvergleich von vier Tagen auf wenige Stunden drückt, hat einen klaren positiven ROI, auch wenn jeder Lauf Credits kostet. Ein Agent, der eine nette, aber selten gebrauchte Spielerei automatisiert, vielleicht nicht mehr. Genau diese Fälle, die man früher einfach gebaut hat, weil sie nichts kosteten, gehören jetzt auf den Prüfstand.

Microsoft sagt das selbst. In der Ankündigung zur Verfügbarkeit heißt es sinngemäß, nutzungsbasierte Abrechnung mache es notwendig, Wert und ROI der AI im Blick zu behalten [1]. Das ist ungewöhnlich offen für eine Produktankündigung und im Kern richtig. Für dich bedeutet es: Vor dem Bauen kommt die Bewertung. Nicht für jeden Mini-Use-Case mit Stoppuhr und Excel, aber als Haltung. Was bringt der Agent, was kostet er ungefähr, und steht das in einem vernünftigen Verhältnis. Wer seine Use Cases sauber priorisiert, holt am Ende mehr Wirkung aus jedem Credit.

‍

Controlling wird zur Daueraufgabe, und die Werkzeuge liefert Microsoft schon mit

Die zweite Konsequenz betrifft die Planung. Bisher konntest du sagen: 200 Lizenzen, fester Betrag, fertig kalkuliert. Mit Verbrauchsabrechnung schwankt die monatliche Rechnung, je nachdem, wie viel deine Leute an Cowork übergeben. Damit wird Kostensteuerung von der Einmal-Entscheidung zur laufenden Aufgabe.

Immerhin musst du das Werkzeug dafür nicht selbst bauen. Microsoft hat ein Cost-Management-Dashboard ins Microsoft-365-Admin-Center gepackt. Es zeigt Verbrauch und Restkapazität in Echtzeit und lässt dich in einer Detailansicht den Verbrauch nach Nutzer, Gruppe, Dienst und einzelnem Agenten aufschlüsseln [2].

Gesteuert wird über sogenannte Spending Policies. Du legst ein Monatsbudget fest, optional ein Limit pro Nutzer, und du entscheidest, welche Dienste eine Policy überhaupt freigibt [2]. Die Kehrseite ist genau die Sorge, die ich gerade von vielen IT-Verantwortlichen höre: Ist das Limit erreicht, verlieren die zugewiesenen Nutzer den Zugriff auf die Agenten und Dienste, bis die Credits zum Monatswechsel zurückgesetzt werden [2]. Es gibt keinen sanften Übergang. Cowork ist heute Teil des Arbeitsablaufs und morgen, wenn das Budget aufgebraucht ist, einfach weg. Deshalb lieber konservativ starten und die Limits gezielt für die Leute anheben, die viel damit arbeiten.

‍

‍

Beim Bezahlen hast du mehr als nur Pay-as-you-go. Du kannst Credits vorab kaufen, entweder als Capacity Pack oder als einjährigen Pre-Purchase Plan über Azure-Reservierungen. Beide bieten einen Mengenrabatt und laufen automatisch in Pay-as-you-go über, sobald der Vorrat leer ist [4]. Der Haken: vorausgezahlte Credits verfallen, was du nicht verbrauchst, ist am Jahresende weg. Vorauszahlung lohnt sich also erst, wenn du deinen Verbrauch ungefähr kennst, nicht am ersten Tag.

Beim Einrichten noch zwei Hinweise. Lass dir per E-Mail melden, wenn eine Policy einen Schwellenwert erreicht, damit du es vorher merkst, nicht erst auf der Rechnung [2]. Und ein Detail, das leicht untergeht: In der Policy gibt es eine Option, die neue Dienste automatisch aufnimmt, sobald sie verfügbar werden. Die würde ich bewusst abschalten, sonst greifen künftige Dienste ungefragt auf dein Budget zu.

‍

‍

Die eigentliche Frage bleibt also nicht, ob es Controlling-Werkzeuge gibt, sondern wer sie betreibt. Das Dashboard ist da, aber es bleibt leer, bis jemand Policies, Limits und Alerts konfiguriert. Und es ist nicht selbsterklärend, wer das tun sollte: die IT, der Fachbereich oder beide gemeinsam. Diese Rolle solltet ihr vor dem Rollout klären, nicht erst nach der ersten überraschenden Rechnung.

‍

Der deutsche Sonderfall: erst die Datenresidenz, dann die Kosten

Für Unternehmen in Deutschland kommt eine Schicht obendrauf, die in den meisten internationalen Berichten untergeht. Cowork lässt dich inzwischen das Modell wählen, und die stärksten Optionen kommen von Anthropic, Opus 4.8 und Sonnet 4.6 [1]. Genau da liegt der Haken: Die Anthropic-Modelle laufen außerhalb der EU Data Boundary, die Verarbeitung findet in den USA statt, und für Kunden in der EU, der EFTA und in UK sind sie standardmäßig deaktiviert [3].

Das ist kein Verbot, aber eine bewusste Entscheidung. Wer Cowork in der EU mit den Anthropic-Modellen nutzen will, muss Anthropic als Microsoft-Subprozessor aktiv freischalten und im Admin Center bestätigen, dass die Daten zur Verarbeitung außerhalb der EU Data Boundary gehen [3]. Für viele Mittelständler, besonders in regulierten Branchen oder mit Datenresidenz-Zusagen an die eigenen Kunden, ist das keine Formalie, sondern eine Frage für Datenschutz und Compliance. Das gehört auf den Tisch, bevor Cowork ausgerollt wird.

‍

‍

Und jetzt die gute Nachricht für die Datenresidenz: Du musst Anthropic gar nicht freischalten, um Cowork zu nutzen. Cowork hat inzwischen eine Modellauswahl [5]. Schaltest du die Anthropic-Modelle aus, läuft Cowork auf den GPT-Modellen weiter, die innerhalb der EU Data Boundary verarbeitet werden. GPT 5.5 ist dort im Frühzugang schon verfügbar. Genau hier liegt der Unterschied: Die Anthropic-Modelle sind die ausdrückliche Ausnahme, sie werden außerhalb der EU Data Boundary verarbeitet [3]. Wer also keine Daten in die USA geben will, bekommt Cowork trotzdem, nur eben mit dem Microsoft-Modell.

‍

‍

Microsoft hat dazu auch ein eigenes, in Azure gehostetes Modell namens Cowork 1 angekündigt, das günstiger sein soll [1]. Die Datenresidenz im Detail, etwa beim Routing unter Last, solltest du für deinen Tenant trotzdem einmal prüfen. Aber die Grundregel für Deutschland bleibt: erst die Datenschutz-Entscheidung, dann die Kostenfrage, nicht umgekehrt.

‍

Was bleibt, und was wir beobachten

Ehrlich gesagt ist vieles davon noch in Bewegung. Microsoft selbst sagt, die Kosten sollen über die Zeit sinken, weil Modelle billiger werden, Cowork Aufgaben besser auf passende Modelle verteilt und Kontext wie Tool-Nutzung effizienter werden [1]. Ob das so eintritt, wissen wir in ein paar Monaten. Wir prüfen den Stand dann erneut und halten in einem zweiten Teil fest, was sich bestätigt hat und was nicht.

Bei aller zusätzlichen Arbeit bewegt sich das Ganze in eine vernünftige Richtung. Die Administration wird anspruchsvoller, keine Frage. Aber du bist nicht auf einen Anbieter festgelegt: Cowork läuft inzwischen auch auf Microsofts eigenen GPT-Modellen, nicht mehr nur auf Anthropic. Das ist mehr als ein technisches Detail, es gibt dir bei den Kosten und besonders bei der Datenresidenz Spielraum.

Was jetzt schon feststeht: Das feste Pro-Kopf-Abo ist nicht mehr die ganze Rechnung. Wer Cowork ernsthaft einsetzen will, braucht drei Dinge vor dem Rollout. Eine Priorisierung der Use Cases nach Nutzen. Ein eingerichtetes Kosten-Controlling mit klaren Zuständigkeiten. Und, in Deutschland, eine bewusste Datenresidenz-Entscheidung. Keine dieser Aufgaben ist riesig. Aber alle drei wollen vorher gemacht werden, nicht hinterher.

Wenn du gerade überlegst, wie ihr Cowork einführt, ohne dass die Rechnung am Monatsende zur Überraschung wird, lass uns 20 Minuten sprechen. Wir schauen, wo bei euch der größte Hebel liegt.

‍