Copilot Studio: Credit-Verbrauch verstehen und Agentenkosten planen

Zuletzt aktualisiert: 27. Oktober 2026 · Version: 2.1.2

Redaktionshinweis: Dieser Artikel wurde mit KI-Unterstützung auf Grundlage der verlinkten Microsoft-Dokumentation erstellt und redaktionell kuratiert. Ein eigener Produkttest wurde nicht durchgeführt.

Ein Agent beantwortet eine Frage scheinbar in wenigen Sekunden. Im Hintergrund kann er jedoch ein Modell aufrufen, Informationen abrufen und mehrere Werkzeuge ausführen. Für Fachbereich und IT stellt sich deshalb eine praktische Frage: Wie lässt sich erkennen, was ein Entwurf kostet, bevor er im Unternehmen breit eingesetzt wird?

Microsoft beschreibt dafür eine Verbrauchsanzeige in Copilot Studio. Sie macht die Kostenwirkung von Designentscheidungen früher sichtbar – allerdings zunächst als Schätzung. Wer diese Anzeige für Budgetentscheidungen nutzt, muss wissen, welche Ansicht gerade angezeigt wird, wie aktuell ihre Daten sind und welches Abrechnungsmodell für den konkreten Agenten gilt.

Die Entscheidung für Unternehmen

Die wichtige Frage ist nicht allein, ob ein Agent pro Antwort wenige Credits benötigt. Entscheidend ist, ob er bei akzeptabler Qualität und kontrollierten Datenzugriffen innerhalb des verfügbaren Budgets arbeitet. Dafür müssen Entwicklung und Einkauf dieselbe Grundlage verwenden: zunächst vergleichbare Tests, anschließend verarbeitete Verbrauchswerte und schließlich die gültigen Vertragsbedingungen.

Direkt zum Thema: Die drei Anzeigen · Praxisbeispiele · Schritt für Schritt · Governance · FAQ

Was zeigt Microsoft – und für welche Agenten?

Die zugrunde liegende Microsoft-Dokumentation zu geschätztem Credit-Verbrauch beschreibt die Erfahrungen Preview, Evaluate und Monitor im Kontext der Agenten mit GitHub Copilot Harness. Laut Microsoft wurde die Seite am 29. September 2026 aktualisiert. Sie beschreibt eine Funktion und ihre Arbeitsweise; aus der Seite allein lässt sich weder ein allgemeiner Einführungstermin noch die Verfügbarkeit in jedem Tenant ableiten.

Copilot Credits sind eine Verbrauchseinheit. Sie zeigen, wie viel abrechnungsrelevante Nutzung anfällt. Sie sind nicht selbst ein Geldbetrag: Der finanzielle Effekt hängt unter anderem von Bezugsmodell, Vertrag, vorhandener Kapazität und gegebenenfalls Azure-Abrechnung ab. Eine Anzeige von 100 Credits bedeutet deshalb nicht automatisch 100 Euro.

Preview, Evaluate und Monitor: Was ist der Unterschied?

Preview und Evaluate sind eigenständige Testsichten, keine verpflichtenden Schritte einer festen Reihenfolge. Beide unterstützen die Optimierung; Monitor zeigt die bereits verarbeiteten Ereignisse.

Der Name der Monitor-Kennzahl kann irritieren: Obwohl sie „Total estimated credits used“ heißt, bezeichnet Microsoft sie als maßgebliche Quelle für die Credit-Verbrauchsberichterstattung und die abzurechnenden Credits im gewählten Zeitraum, sobald dessen Ereignisse verarbeitet sind. Das gilt für die Ereignisse, die bereits verarbeitet wurden. Ist der Zeitraum noch nicht vollständig verarbeitet, ist auch die angezeigte Summe noch nicht vollständig. Microsoft nennt dafür eine Verzögerung von einigen Stunden; eine feste garantierte Frist nennt die verlinkte Seite nicht.

Ein Informationssymbol und ein erklärender Hinweis kennzeichnen laut Microsoft geschätzte Werte. In Preview kann man die laufende Schätzung auswählen, um den Hinweis zu lesen. In Evaluate bezieht sich die Angabe auf den jeweiligen Evaluierungslauf. In Monitor sollte der gewählte Zeitraum immer zusammen mit dem Zeitpunkt der letzten Verarbeitung interpretiert werden.

Warum verbrauchen zwei ähnliche Antworten unterschiedlich viele Credits?

Die Schätzung berücksichtigt laut Microsoft Informationen aus der Laufzeit: verwendete KI-Modelle, ausgeführte Tools und Aktionen sowie Komponenten von Harness und Orchestrierung. Das Harness ist hier die technische Laufzeitumgebung, die den Agenten ausführt; Orchestrierung bezeichnet die Steuerung der Schritte und Werkzeuge. Ein kurzer Text an der Oberfläche verrät daher nicht zuverlässig, wie viel Arbeit im Hintergrund stattgefunden hat.

Ein Agent kann beispielsweise eine Antwort direkt erzeugen. Ein anderer ruft zusätzlich ein internes System auf, verarbeitet dessen Ergebnis und führt einen weiteren Schritt aus. Mehr Schritte können den Verbrauch erhöhen; aus der Zahl der sichtbaren Chatnachrichten allein lässt sich der konkrete Wert nicht berechnen. Die Microsoft-Seite nennt für diese Anzeige keine allgemeingültige Formel je Nachricht und keine verbindlichen Einzelpreise für alle denkbaren Abläufe.

Drei Praxisbeispiele aus dem Unternehmen

Die folgenden drei Szenarien sind hypothetisch und dienen der Erklärung; sie beschreiben keine gemessenen Unternehmenseinsätze.

1. Personalabteilung: Wissensagent vereinfachen

Ein interner Agent beantwortet Fragen zu Reisekosten. Das Team testet dieselben anonymisierten Fragen zunächst mit einer einfachen Wissensquelle und anschließend mit einem zusätzlichen Tool-Aufruf. Die Preview-Schätzung zeigt, ob die zweite Variante bei diesen Tests mehr Credits benötigt. Erst nach mehreren vergleichbaren Fällen und nachgelagerter Verarbeitung in Monitor lässt sich die Differenz besser beurteilen. Gleichzeitig muss geprüft werden, ob der zusätzliche Aufruf die Antwortqualität tatsächlich verbessert.

2. Kundenservice: Evaluierung vor dem Rollout

Ein Service-Team vergleicht zwei Agentenvarianten anhand desselben Fragenkatalogs. Evaluate liefert pro Evaluierungslauf eine Verbrauchsschätzung; daneben dokumentiert das Team Lösungsquote, Fehler und notwendige menschliche Nacharbeit. Die günstigere Variante ist nicht automatisch die wirtschaftlichere: Wenn sie häufiger falsche Antworten liefert oder an Mitarbeitende übergeben muss, können an anderer Stelle höhere Kosten entstehen.

3. Einkauf: Budget und Abrechnung zusammenführen

FinOps betrachtet für einen produktiven Agenten einen abgeschlossenen Monat in Monitor und wartet, bis die Ereignisse verarbeitet sind. Danach gleicht das Team die Credits mit dem Bezugsmodell und den zugänglichen Abrechnungsdaten ab. Erst daraus entsteht eine Aussage zu den tatsächlichen Kosten im Unternehmenskontext. Credits weiterer Agenten, anderer Dienste oder zusätzliche Gebühren dürfen nicht ungeprüft in dieselbe Kennzahl hineingelesen werden.

Wichtige Abgrenzung: GitHub Copilot Harness und Standard-Harness

Microsoft dokumentiert unterschiedliche Agentenlaufzeiten und unterschiedliche Regeln. Für das hier behandelte GitHub Copilot Harness weist Microsoft ausdrücklich darauf hin, dass Nutzung, Erstellung, Tests und Evaluierungen Credits verbrauchen können.

Für Agenten mit Standard-Harness beschreibt die Abrechnungs-FAQ dagegen, dass die eigene Agentenaktivität im eingebetteten Testchat keine Copilot Credits verbraucht. Dazu zählen klassische und generative Antworten, Agent Actions und Tenant Graph Grounding. Für eingebundene Agent Flows und Prompts verweist Microsoft auf gesonderte Regeln. Diese Aussagen sind also nicht pauschal widersprüchlich: Sie beziehen sich auf unterschiedliche Laufzeit- und Testszenarien. Welcher Fall im eigenen Tenant gilt, sollte vor der Kostenplanung anhand der konkreten Agentenkonfiguration und aktuellen Lizenzbedingungen geklärt werden.

Auch Microsoft-365-Copilot-Lizenzen können für bestimmte authentifizierte Mitarbeiterszenarien Nutzung einschließen. Das ist an Bedingungen geknüpft und darf nicht pauschal auf externe Nutzer, autonome Auslöser oder jede Tool-Nutzung übertragen werden. Microsoft erläutert diese Grenzen in den Abrechnungsraten und Fußnoten; sie sind nicht automatisch eine Preisliste für jedes Harness. Für das Standard-Harness nennt Microsoft zudem einen konkreten Teams-Fall: Bei einem in der eigenständigen Copilot-Studio-Version erstellten und im Teams-Kanal bereitgestellten Agenten wird die Nutzung durch Endnutzer mit Microsoft-365-Copilot-Lizenz laut FAQ nicht berechnet. Die Bedingungen für Identität und einzelne Funktionen sind gesondert zu prüfen.

Für die in der Standard-Harness-FAQ beschriebene monatlich zugewiesene Kapazität zählt Microsoft den Verbrauch je Kalendermonat; ungenutzte monatliche Kapazität wird nicht übertragen. Diese Regel ist nicht pauschal auf alle Bezugsmodelle übertragbar: Für das GitHub Copilot Harness beschreibt Microsoft auch einen einjährigen Prepurchase-Plan. Entscheidend sind die jeweils geltenden Produkt- und Vertragsbedingungen.

Von Credits zu Kosten: So gelingt eine realistische Planung

Eine einfache Planungsformel lautet: erwartete Anzahl vergleichbarer Vorgänge × beobachtete Credits je Vorgang = geschätzter Credit-Bedarf. Beispiel: Ein Pilot ergibt nach Verarbeitung durchschnittlich 12 Credits je bearbeitetem Vorgang. Bei angenommenen 5.000 gleichartigen Vorgängen wären das rechnerisch 60.000 Credits. Beide Werte sind illustrative Annahmen, keine Microsoft-Preisangaben oder Messergebnisse.

Das Ergebnis bleibt eine Hochrechnung. Sie setzt voraus, dass Aufgabenmix, Modell, Werkzeuge und Verhalten vergleichbar bleiben. Ergänzen Sie Reserven für komplexere Fälle, Wiederholungen, Tests, Evaluierungen und saisonale Spitzen. Dokumentieren Sie, ob Tests im konkreten Harness überhaupt in den beobachteten Verbrauch eingehen. Wiederholen Sie die Rechnung nach Änderungen an Modell oder Agentendesign.

Für den Geldbetrag müssen Einkauf und Administration das gültige Bezugsmodell prüfen. Microsoft beschreibt unter anderem Pay-as-you-go über Azure und Vorauszahlung. Ein vereinfachter Euro-Preis je Credit kann für interne Kalkulationen nützlich sein, muss aber aus dem tatsächlich geltenden Vertrag und den relevanten Mengen abgeleitet werden. Weitere Azure-, Power-Platform- oder Drittanbieter-Kosten können je nach Architektur zusätzlich entstehen.

Schritt für Schritt: Verbrauch im Pilot prüfen

1. Geltungsbereich klären: Agent, Harness, Umgebung, Kanal, Nutzergruppe und Bezugsmodell dokumentieren. Prüfen, ob die beschriebenen Ansichten im Tenant verfügbar sind.
2. Testfälle festlegen: Typische, einfache und komplexe Anfragen mit datenschutzkonformen Testdaten auswählen. Für Vergleiche denselben Katalog und möglichst gleiche Bedingungen verwenden.
3. Preview beobachten: Eine Sitzung durchführen, die laufende Schätzung und wesentliche Konfigurationsänderungen festhalten. Den Wert als vorläufig kennzeichnen.
4. Evaluate vergleichen: Varianten mit demselben Testsatz auswerten. Credits zusammen mit Ergebnisqualität, Fehlerrate und menschlichem Aufwand dokumentieren.
5. Monitor später prüfen: Agent und Zeitraum auswählen, „Total estimated credits used“ betrachten und ausreichend Zeit für die Verarbeitung lassen. Datenstand und verbleibende Unsicherheit protokollieren.
6. Budget abstimmen: Mit Administration und Einkauf Kapazität, Abrechnungsmodell und mögliche Zusatzkosten abgleichen. Grenzwerte und Eskalation für den Betrieb festlegen.

Praktische Vorlage: Agent und Version | Harness und Umgebung | Zeitraum und Datenstand | Anzahl Vorgänge | Credits laut Monitor | Credits je Vorgang | Qualitätsmaß | Bezugsmodell | verantwortliche Person | nächste Prüfung.

Governance für DACH-Unternehmen

Eine Kostenanzeige ersetzt keine Betriebs- und Datenschutzprüfung. Verantwortliche sollten Datenquellen und Berechtigungen begrenzen, Rollen für Entwicklung und Freigabe festlegen und protokollieren, welche Tools ein Agent aufrufen darf. Bei personenbezogenen Daten sind Zweck, Rechtsgrundlage, Aufbewahrung, Zugriffe und gegebenenfalls Auftragsverarbeitung sowie Drittlandtransfers mit Datenschutz und Rechtsabteilung zu prüfen. Je nach Einsatz können eine Datenschutz-Folgenabschätzung und die Einbindung des Betriebsrats relevant sein.

Für die technische Ausgestaltung von Copilot-Studio-Workflows und Freigaben sind insbesondere Tool-Zugriffe und Genehmigungsschritte relevant. Für den Betrieb empfiehlt sich eine klare Kostenzuordnung: Der Fachbereich verantwortet den Nutzen, Maker erklären Änderungen am Agenten, IT administriert Umgebungen und Berechtigungen, FinOps verfolgt Verbrauch und Einkauf prüft den Vertrag. Microsoft beschreibt im Power Platform Admin Center Kapazitätszuweisungen und monatliche Agentenlimits. Ob diese für das konkrete Harness und die eigene Konfiguration greifen, ist vor dem Einsatz zu prüfen. Ein verzögerter Monitor-Wert allein ist jedenfalls keine Echtzeit-Budgetbremse.

Grenzen der Aussage

Die Erklärung basiert auf Microsofts Produktdokumentation; ein unabhängiger Praxistest der Anzeigen oder Abrechnung wurde für diesen Entwurf nicht durchgeführt. Funktionen, Oberflächen und Lizenzbedingungen können sich ändern. Die Beschreibung der drei Ansichten erlaubt keine Aussage darüber, dass jeder Agent jede Funktion bereits sieht oder dass alle Kosten in einer einzigen Kennzahl enthalten sind. Bei auffälligen Abweichungen sollten Organisationen den Datenstand, die ausgewählten Zeiträume, das Harness und die Abrechnungsunterlagen prüfen und gegebenenfalls Microsoft-Support einbeziehen.

FAQ

Sind die Werte in Preview und Evaluate schon die endgültige Rechnung?

Nein. Microsoft beschreibt sie als zeitnahe Näherungswerte. Nach Verarbeitung der Ereignisse liefert Monitor den maßgeblichen Credit-Verbrauch für die bis dahin verarbeiteten Ereignisse.

Warum steht in Monitor „estimated“, wenn die Werte maßgeblich sind?

Die Kennzahl trägt diesen Namen. Laut Microsoft zeigt sie nach Verarbeitung den maßgeblichen Verbrauch; vor Abschluss der Verarbeitung können Ereignisse für den gewählten Zeitraum fehlen.

Kosten Agententests immer Credits?

Nein. Beim hier behandelten GitHub Copilot Harness können Entwicklung, Tests und Evaluierungen Credits verbrauchen. Für den eingebetteten Testchat des Standard-Harness dokumentiert Microsoft andere Regeln und Ausnahmen für zusätzliche Funktionen.

Kann ich Credits direkt in Euro umrechnen?

Nur mit passenden Vertrags- und Abrechnungsdaten. Bezugsmodell, verfügbare Kapazität, Nutzung und mögliche zusätzliche Dienste bestimmen den finanziellen Effekt.

Reicht ein einzelner Test für eine Budgetprognose?

Nein. Unterschiedliche Anfragen und Tool-Aufrufe verändern den Verbrauch. Nutzen Sie repräsentative Testfälle und prüfen Sie verarbeitete Werte über einen geeigneten Zeitraum.

Fazit: Erst messen, dann skalieren

Die Anzeige macht die wirtschaftlichen Folgen von Agentendesign früher sichtbar. Ihr größter Nutzen liegt im Vergleich: Welche Konfiguration liefert bei ähnlicher Qualität einen tragfähigen Verbrauch? Unternehmen sollten mit einem begrenzten, dokumentierten Pilot beginnen, Preview und Evaluate für die Optimierung nutzen und den verarbeiteten Verbrauch in Monitor mit Kapazitäts- und Vertragsdaten abgleichen. Erst danach ist eine belastbare Skalierungsentscheidung möglich.

Quellen und Stand

• Microsoft Learn: Understand estimated credit usage – Grundlage für Preview, Evaluate und Monitor.
• Microsoft Learn: Monitor agent performance overview – Monitor und GitHub Copilot Harness.
• Microsoft Learn: FAQ for Copilot Studio billing and licensing – Standard-Harness und Testchat.
• Microsoft Learn: Purchase and manage Copilot Credits – Bezugsmodelle.
• Microsoft Learn: Manage Copilot Credits and capacity – Verwaltung und Limits.

Quellen geprüft am 27. Oktober 2026.

Weiterführende Artikel auf AI-Fabrik

• Microsoft Copilot und Copilot Studio: Lizenz-Guide 2026 – zur Einordnung der Lizenzmodelle.
• Copilot Studio: Apps, Workflows und Agenten verbinden – zu Integrationen und Freigaben.