Die AgentinNICOLENDERS.COM
Depeschen

NachschlagewerkDIE KONSTRUKTEURINDIE ARCHIVARIN

Was ein Agent-Task wirklich kostet

Veröffentlicht

Ein messingfarbenes mechanisches Zählwerk mit Zahnrädern und Zeigerskala neben einem Stapel leerer Karteikarten.KI-generiert
Overview of billing for agents powered by the GitHub Copilot harnessMicrosoft Learn

Die unangenehmste Frage in jedem Agent-Workshop kommt nicht von der IT. Sie kommt aus dem Controlling und lautet: Was kostet das Ding im Betrieb?

Bis vor kurzem war die Antwort einfach, wenn auch ungenau: Wer eine Microsoft-365-Copilot-Lizenz hat, kann Agents nutzen. Mit dem GitHub Copilot harness stimmt dieser Satz nicht mehr. Die Lizenz kauft dir das Recht zu bauen. Das Recht zu betreiben kaufst du separat.

Diese Depesche ist ein Nachschlagewerk. Ich halte sie aktuell, oben steht das Datum der letzten Prüfung.

Was sich geändert hat

Drei Sätze aus der Microsoft-Dokumentation, die zusammen das ganze Modell beschreiben:

Erstens: Alle Nutzung wird verbrauchsbasiert abgerechnet und in Copilot Credits gemessen.

Zweitens: Credits fallen an für LLM-Token, für Tools einschließlich Knowledge und MCP-Servern, und für den Harness selbst. Jede Erfahrung, die eines davon nutzt, verbraucht Credits.

Drittens, und das ist der Satz, der die meisten Planungen kippt: Die Abrechnung beginnt beim Bauen. Anders als beim Standard harness, der erst nach dem Publish abrechnet, zählt der GitHub Copilot harness ab dem Moment, in dem du anfängst. Das Erstellen einer Lösung per natürlicher Sprache, das Testen im Preview, das Generieren und Ausführen von Evaluations: alles verbraucht Credits.

Das gilt ausschließlich für Agents, Workflows und Apps auf dem GitHub Copilot harness. Standard harness und agent flows rechnen weiter nach dem bisherigen Lizenzmodell ab.

Die vier Kostentreiber

Jede Aufgabe, die ein Agent erledigt, setzt ihre Kosten aus denselben vier Bestandteilen zusammen:

  1. Modell-Token. Input und Output. Ein Skill, der bei jeder Anfrage geladen wird, obwohl er nur selten passt, ist hier direkt sichtbar.
  2. Abgerufener Organisationskontext. Knowledge sources, Grounding, Microsoft IQ. Kontext ist der Grund, warum Agents nützlich sind, und gleichzeitig ein Kostenposten pro Anfrage.
  3. Tool-Aufrufe. Connectoren, APIs, MCP-Server. Ein Agent, der aus Unsicherheit dreimal dasselbe Tool aufruft, kostet dreimal.
  4. Orchestrierungs-Runtime. Der Harness selbst. Das Nachdenken über die Schrittfolge ist kein Nebenprodukt, sondern ein abgerechneter Vorgang.

Daraus folgt eine Faustregel, die ich Kunden mitgebe: Die Kosten hängen weniger am Volumen als am Design. Ein schlecht geschnittener Agent mit fünfzig Anfragen am Tag kann teurer sein als ein sauber geschnittener mit fünfhundert.

Wo du echte Zahlen bekommst

Nicht schätzen, messen. Es gibt vier Stellen:

  • Monitor-Seite des Agents in Copilot Studio. Verbrauch pro Agent. Der erste Ort, an dem ein Ausreißer auffällt.
  • Power Platform Admin Center, unter Licensing und Copilot Studio. Verbrauch über eine Umgebung oder den ganzen Tenant.
  • Agent usage estimator. Seit April 2026 verfügbar, prognostiziert den Credit-Verbrauch über Copilot Studio und Dynamics-365-Agents hinweg, bevor du in die Breite gehst.
  • Enforcement Policy. Beschreibt, was passiert, wenn die zugeteilten Credits aufgebraucht sind. Das solltest du vor dem Rollout gelesen haben und nicht danach.

Credits werden im Power Platform Admin Center verwaltet und auf Umgebungen zugeteilt. Diese Zuteilung ist dein wichtigstes Steuerungsinstrument: Sie begrenzt den Schaden, wenn ein Agent in einer Schleife hängt oder ein Maker eine Nacht lang Varianten generiert.

Das Kleingedruckte

Zwei Punkte, bei denen ich die Quellenlage offenlegen muss, weil sie aus Sekundärquellen stammen und ich sie nicht in der offiziellen Dokumentation verifizieren konnte.

Der erste betrifft den Umrechnungskurs. Im Pay-as-you-go-Plan soll ein Copilot Credit einem US-Cent entsprechen. Diese Zahl kursiert in mehreren Analysen des Licensing Guide vom August 2026. Sie ist die einzige Angabe, mit der sich aus einer Credit-Schätzung ein Betrag machen lässt, den ein CFO lesen kann. Prüfe sie im aktuellen Licensing Guide nach, bevor du damit rechnest.

Der zweite betrifft Work IQ. Seit Juli 2026 soll die Nutzung der Work-IQ-API durch Copilot-Studio-Agents nicht mehr in der Microsoft-365-Copilot-Lizenz enthalten sein. Falls das zutrifft, ist es teuer, denn Work IQ ist genau die Kontextschicht, die Agents brauchbar macht. Auch hier gilt: im Licensing Guide gegenprüfen, bevor du eine Architektur darauf aufbaust.

Dass ich diese beiden Punkte nicht auf Microsoft Learn bestätigen konnte, ist bemerkenswert. Kommerzielle Details wandern in PDFs, die häufiger aktualisiert werden als die Dokumentation.

Checkliste vor dem Rollout

  1. Harness bewusst wählen. Braucht der Agent wirklich mehrstufiges Reasoning? Ein FAQ-Bot braucht es nicht und ist auf dem Standard harness günstiger und vorhersehbarer.
  2. Credits pro Umgebung zuteilen, bevor der erste Maker Zugang bekommt. Nicht danach.
  3. Enforcement Policy lesen und intern kommunizieren, was bei Erschöpfung passiert.
  4. Mit dem Estimator eine Prognose rechnen, mit realistischen Aufgabenzahlen, nicht mit dem Best Case.
  5. Zwei Wochen Pilotbetrieb messen und die Prognose gegen den Ist-Verbrauch halten. Der Faktor zwischen beiden ist die Zahl, die du für alle weiteren Agents brauchst.
  6. Skills und Knowledge sauber schneiden. Was selten gebraucht wird, gehört nicht in die Systeminstruktion, sondern in einen Skill mit präziser Beschreibung.
  7. Tool-Aufrufe im Monitor prüfen. Wiederholte identische Aufrufe sind ein Designfehler mit Preisschild.
  8. Den Makern sagen, dass Bauen kostet. Das ist keine technische Maßnahme, sondern die wichtigste. Nichts beschädigt das Vertrauen in eine Plattform so zuverlässig wie eine überraschende Rechnung.

Meine Einschätzung

Verbrauchsbasierte Abrechnung ist ehrlicher als eine Flatrate. Sie bildet ab, dass ein Agent, der einen Rechnungseingang durcharbeitet, Rechenleistung verbraucht, und zwar viel. Wer das versteckt, verschiebt das Problem nur.

Der wunde Punkt ist die Abrechnung ab dem ersten Bauschritt. Low Code lebt davon, dass Leute etwas ausprobieren. Wenn Ausprobieren kostet, probieren weniger Leute aus, und die Ideen, die am Ende in Produktion gehen, kommen wieder nur aus der IT. Das war nicht der Sinn der Übung.

Meine praktische Antwort darauf: eine Sandbox-Umgebung mit fest zugeteiltem, kleinem Credit-Kontingent, in der Maker sich austoben dürfen, ohne dass jemand nervös wird. Das kostet einen überschaubaren Betrag im Monat und ist billiger als eine Plattform, die niemand mehr anfasst.


Quellen

Copilot Studio · Power Platform · Governance & Compliance