AgentDome im Detail: KI-Kosten analysieren und optimieren

In AgentDome kann ich KI-Kosten bis zur Person, zum Agenten, zum Tool und zum Modell verfolgen. Von dort komme ich zu den Optimierungsvorschlägen und sehe, welche Änderung empfohlen wird.

Für diesen Rundgang habe ich mich durch die FinOps-Oberfläche geklickt und vorhandene Cache-Konfigurationen in meinem Intune-Demo-Tenant geprüft. Mich hat interessiert, wie Empfehlung, Änderung am Endgerät und spätere Verbrauchsauswertung zusammenpassen.

Transparenz: Ich bin Mitglied im Advisory Board von AgentDome. Die AgentDome-Screenshots zeigen Staging-Daten, einschließlich Identitäten, Beträgen, Zeiträumen und Evaluationen. Das sind keine Kundenergebnisse und kein unabhängiger Einspar-Benchmark. In Intune habe ich bestehende Demo-Pakete angesehen, aber weder eine neue Richtlinie verteilt noch eine Remediation ausgeführt.

Die Oberfläche und die beiden verfügbaren öffentlichen Produktartikel habe ich am 20. Oktober 2026 geprüft. Die Pilotschritte weiter unten sind Empfehlungen, kein Bericht über einen abgeschlossenen Rollout.

Was AgentDome macht

Die Oberfläche deckt Kostenzuordnung, Optimierungsvorschläge und Richtlinien ab:

AgentDome beschreibt einen Collector in der Kundenumgebung mit Connectoren zu den KI-Plattformen. Laut Sicherheitsartikel werden sensible Inhalte lokal verarbeitet; benötigte Metadaten gehen an die zentrale Plattform. Kläre die genaue Feldliste, besonders wenn du Prompts oder Antworten erfassen möchtest. Bereitstellungsmodell · Sicherheitsarchitektur

Die Umsetzung hängt vom Workload ab. Intune kann unterstützte Einstellungen an einen lokalen Coding-Client verteilen. Eine Änderung am Model Deployment in Microsoft Foundry oder an einer AWS-Agenten-Runtime gehört zum jeweiligen Workload-Verantwortlichen.

Kosten bis zur Person oder zum Agenten verfolgen

Ich habe unter Dashboard → General begonnen. Dort sind Gesamtverbrauch, Einsparpotenzial, Kosten je Tool, organisatorische Zuordnung und ausgewiesene realisierte Einsparungen getrennt dargestellt.

Die Aufteilung enthält Claude Code, Codex, Cursor, Microsoft Foundry, AWS Bedrock und Copilot Cowork. Dazu kommt nicht zugeordneter Verbrauch. Den würde ich sichtbar lassen: Unbekannte Kosten ohne Beleg einer Abteilung zuzuschlagen macht das Diagramm ordentlich, die interne Verrechnung aber unzuverlässig.

Ein Teamlead kann nach seiner Abteilung filtern, Personen suchen oder zwischen Geschäftseinheiten und Führungskräfte-Hierarchie wechseln. Die Zuordnung hängt von gepflegten Identitäten ab. Gemeinsam genutzte Zugangsdaten und fehlende Verantwortliche muss das Team weiterhin klären.

Personen und Service Principals brauchen unterschiedliche Verantwortliche

Der Beispielagent Motor Loans Processing Agent hat eine Service-Principal-Identität und Verbrauch in Microsoft Foundry. Seine Karte verlinkt Modellanpassung, ungenutzte MCP-Server und nachgeladene Tool-Definitionen. Vom Gesamtbetrag komme ich zu der Empfehlung, die ihn erklären soll.

Die Mitarbeiterkarte zeigt diese Informationen für eine Person. Die Demo-Mitarbeiterin ist über Okta zugeordnet und nutzt Cursor sowie Claude Code. Schau dir die Kosten zusammen an, bevor du entscheidest, welches Tool oder welche Einstellung du änderst.

Halte einen technischen und einen Budgetverantwortlichen fest. Der Service Principal allein verrät Finance nicht, wer eine Modelländerung freigeben oder einen ungewöhnlichen Lauf erklären kann.

Den Pfad im Kostengraph nachvollziehen

Der als Beta gekennzeichnete Cost Graph führt von Personen oder autonomen Agenten über Tools und Plattformen bis zum Modell. Knoten lassen sich aufklappen, schließen und verschieben. Hier habe ich den Demo-Agenten über Microsoft Foundry bis zu seinem Modell verfolgt.

Ein Modellknoten kann mehrere eingehende Pfade zusammenfassen. Prüfe diese Verbindungen, bevor du seinen Gesamtbetrag mit den Kosten eines einzelnen Agenten vergleichst. Halte Zeitraum und Workload zusammen mit dem Screenshot fest.

Unterschiedliche Ansichten für Finance und Engineering

Der Tab CFO zeigt Kostenprognosen, Budgetabweichungen, ROI je Geschäftseinheit und die Nutzung von Hersteller-Commitments. Eine niedrigere Rechnung kann ein Jahres-Commitment ungenutzt lassen. Eine höhere Rechnung kann mit mehr erfolgreich erledigter Arbeit zusammenhängen.

Unter Engineering stehen Projektkosten und Budgetziele zusammen. Ich habe dort auch die Budgeteinstellungen gefunden, aber unverändert gelassen. Bevor du die ROI-Werte oder Prognosen für eine Entscheidung nutzt, kläre ihre Berechnungsgrundlage.

Seat Based Licensing ist von Usage Billing getrennt. Die Demo zeigt Sitzungen in Copilot Outlook, Teams, Office und Loop zusammen mit der Zahl lizenzierter Nutzer. Die angezeigten null zusätzlichen Verbrauchskosten sind kein Lizenzpreis von null Euro. Feste Abonnements und nutzungsabhängige Kosten brauchen eigene Positionen in der Rechnung.

Sechs Arten von Einspar-Empfehlungen

Saving Opportunities gruppiert Vorschläge nach der vorgesehenen Änderung. Öffne eine Empfehlung, um den betroffenen Workload, die Begründung und die geschätzte Einsparung zu sehen.

Prüfe diese Eingriffe getrennt. Ein anderes Standardmodell kann die Antwort verändern; eine geleerte Sitzung kann noch benötigten Kontext entfernen. Die Freigabe, eine ungenutzte Verbindung zu entfernen, sollte nicht automatisch beides erlauben.

Die Evaluation hinter einer Modellempfehlung lesen

Im Rightsizing-Beispiel wird für den Motor-Loans-Agenten ein günstigeres Modell vorgeschlagen. Der Tab Reasoning enthält ein Evaluation Target in Microsoft Foundry und eine Vergleichstabelle.

Hier schaue ich zuerst auf die Evaluation. Groundedness bleibt in der Demo gleich. Task Completion fällt dagegen von 0,80 auf 0,70 und Coherence von 4,90 auf 4,60; Customer Satisfaction steigt. Die Leistung als ähnlich zu bezeichnen reicht mir nicht, um den Wechsel freizugeben.

Bei einem Kreditbearbeitungsprozess muss der Verantwortliche die relevanten Grenzen vorher festlegen: Welche Fehler sind unzulässig? Welche Fälle brauchen eine Prüfung? Frisst ein zusätzlicher Versuch die Einsparung wieder auf? Die Modellnamen und Dollarbeträge sind hier Staging-Beispiele, keine aktuelle Modell-Preisempfehlung.

Im Tab Cost graph lassen sich aktuelles und optimiertes Szenario vergleichen. Der Wechsel dieser Ansicht ändert die Visualisierung und belegt kein geändertes Foundry Deployment. Wie du Agentenänderungen separat untersuchst, beschreibe ich im Beitrag zu Agenten-Evaluationen in Microsoft Foundry.

Manche Änderungen gehören zum Runtime-Verantwortlichen

Das Caching-Detail für den Refund Processing Agent beschreibt wiederholten Kontext in einem AWS-Workload. Die vorgeschlagene Umsetzung betrifft dessen Runtime, nicht die Konfiguration eines Laptops.

Intune verteilt Einstellungen an verwaltete Endgeräte. Dieser gehostete Agent braucht eine Änderung in seiner eigenen Runtime. Deren unterstützte Einstellungen muss der Workload-Verantwortliche prüfen und dort anwenden.

Saving Automation setzt Empfehlungen gezielt um

Der Tab Coding Agents enthält sieben Regeltypen. Jede Zeile zeigt Aktivierung, erwartete Einsparung, Auswirkung auf die Entwicklerarbeit, Zielgruppe und die Aktion Enforce oder Inform.

Die Regeln decken Caching, Kontextbereinigung, Standardmodell-Anpassung, CLI-Alternativen, nachgeladene Tool-Definitionen, ungenutzte MCP-Server und ungenutzte MCP-Tools ab. Die Auswirkung auf die Entwicklerarbeit ist bei Context Cleanup als hoch eingestuft, bei Default Model Rightsizing als mittel. Prüfe diese Einschätzung mit den betroffenen Entwicklern.

Laut Oberfläche benachrichtigt Inform per E-Mail, Teams oder Slack; Enforce wendet die Richtlinie an. Bei Eingriffen in laufende Arbeit wäre mein Startpunkt Inform, gefolgt von einer geprüften Regel in einer Testgruppe.

Beim Standardmodell dürfen Entwickler laut Beschreibung für eine einzelne Sitzung ein anderes Modell wählen. Neue Sitzungen kehren zum empfohlenen Standard zurück. Solche Ausnahmen und ihre Kosten sollten für den Verantwortlichen sichtbar bleiben.

Vorhandene Verwaltungsgruppen als Ziel nutzen

Die Zielauswahl der Caching-Regel bietet MDM – Microsoft Intune, MDM – Jamf Pro und Custom. Im Intune-Tab stehen Gruppen mit Mitgliederzahlen; die Demo hat Developer workstations ausgewählt.

Jamf Pro hat eine eigene Gruppenliste; eine macOS-Verteilung habe ich nicht getestet. Unter Custom nennt die Oberfläche Tagging und Ausdrücke zur Entwicklerzuordnung. Eine vollständige Konfiguration konnte ich dort nicht prüfen.

Die Tabs Autonomous Agents und Coworker Agents hatten in diesem Tenant keine aktiven Richtlinien. Für diese Workloads gab es deshalb kein konfiguriertes Beispiel zu prüfen.

Die Intune-Verbindung an einem vorhandenen Skriptpaket

Für einen verwalteten Coding-Client heißt das: ein teures Nutzungsmuster finden, eine unterstützte Einstellung wählen, an eine Gruppe verteilen und das Ergebnis prüfen. Vergleiche danach im Verbrauchsbericht, was ähnliche Aufgaben gekostet haben.

Der MDM-Artikel von AgentDome beschreibt diesen Ansatz für Prompt-Cache-Einstellungen. Bestehende Geräteverwaltung verteilt die Client-Konfiguration; ein eigener AgentDome-Endgeräte-Agent ist dafür nicht vorgesehen. Vorhandene MDM-Komponenten und die passende Client-Konfiguration werden trotzdem benötigt.

In meinem Modern-Device-Management-Demo-Tenant liegen unter Devices → Scripts and remediations bereits zwei Pakete:

• Claude Code cache TTL - 1 hour
• Claude Code cache TTL - 5 min

Das Ein-Stunden-Paket war bereits aktiv. Es enthält Detection und Remediation, läuft in 64-Bit-PowerShell ohne die Anmeldedaten des angemeldeten Nutzers und ist stündlich an R&D Beta testers zugewiesen. Im AgentDome-Screenshot ist Developer workstations ausgewählt. Das sind getrennte Beispiele, keine nachgewiesene synchronisierte Zuweisung.

1. Detection prüft den konfigurierten Zustand

Das vorhandene Detection-Skript liest die Maschinen-Umgebungsvariable CLAUDE_CODE_PROMPT_CACHE_TTL und vergleicht sie mit 1h. Passt der Wert, liefert es Exit-Code 0; fehlt er oder weicht ab, liefert es 1.

Die relevante Leseoperation ist:

# Nur lesen: Einstellung aus dem vorhandenen Demo-Paket prüfen.
[Environment]::GetEnvironmentVariable(
    "CLAUDE_CODE_PROMPT_CACHE_TTL",
    "Machine"
)

Microsoft dokumentiert, dass die Remediation bei exit 1 aus der Detection läuft. Das Paket sollte deshalb eine echte Abweichung von einer fehlgeschlagenen Prüfung unterscheiden. Der Fehlerhandler des Beispiels gibt ebenfalls 1 zurück; dieses Verhalten würde ich vor einem Einsatz außerhalb der Demo prüfen. Intune Remediations

2. Remediation schreibt und kontrolliert den Wert

Die vorhandene Remediation verwendet SetEnvironmentVariable auf Maschinenebene, liest den Wert zurück und sendet WM_SETTINGCHANGE. Damit wird geprüft, ob Windows den Sollwert gespeichert hat. Ob ein bereits laufender Coding-Prozess ihn übernommen hat, ist damit noch nicht gezeigt.

Ich habe die Skripte ohne Speichern von Änderungen gelesen. Dass sie in Intune vorhanden sind, belegt nicht, dass AgentDome sie erstellt hat.

In der öffentlichen Claude-Code-Referenz konnte ich CLAUDE_CODE_PROMPT_CACHE_TTL nicht finden. Behandle sie als Einstellung dieser Demo, nicht als geprüfte Anleitung für andere Clients. Kläre vor dem Übernehmen die Unterstützung deiner Client-Version und deines Anbieters. Prüfe danach, was der laufende Client sendet. Claude-Code-Umgebungsvariablen

3. Den Gerätestatus genau lesen

Die zuletzt gemeldete Gerätezeile zeigt Without issues für Detection und Not run für Remediation.

Die Detection war bei der letzten gemeldeten Prüfung erfolgreich. Das zeigt weder einen neuen Remediation-Lauf noch einen geänderten API-Request oder gesunkene Kosten.

Erfasse im Pilot drei Ergebnisse getrennt:

1. Konfiguration: Hat das Zielgerät den gewünschten Wert erhalten, ohne andere Einstellungen zu verändern?
2. Client-Verhalten: Nutzt ein frischer Prozess die unterstützte Konfiguration? Zeigen Request- oder Verbrauchsdaten das gewünschte Cache-Verhalten?
3. Arbeitsergebnis: Kosten vergleichbare Aufgaben weniger, ohne zusätzliche Fehler, Verzögerungen oder manuelle Korrekturen?

Prüfe Konfiguration und Ausführung in Intune, den Verbrauch in AgentDome und das Arbeitsergebnis mit dem Workload-Verantwortlichen.

Zielgruppe und Rollback

Maschineneinstellungen betreffen die Nutzer dieses Geräts. Eine Empfehlung je Entwickler braucht deshalb eine bewusste Zuordnung zu Benutzereinstellungen oder Gerätegruppen, besonders bei gemeinsam verwendeten Rechnern. Ein SYSTEM-Skript darf nicht versehentlich das SYSTEM-Profil prüfen, wenn die Einstellungen eines Entwicklers gemeint sind.

Sichere den vorherigen Wert, einschließlich des Zustands „Variable war nicht vorhanden“, und teste die Wiederherstellung. Laufende Terminals können geerbte Werte behalten. Prüfe daher denselben Startweg, den die Entwickler verwenden. Ein Gerät ohne aktuelle Rückmeldung bleibt ausstehend.

Vor einer Verteilung müssen unterstütztes Windows-Enrollment, Remediations-Lizenzberechtigung und Intune-Rolle geklärt sein. Ein sichtbarer Create-Button ersetzt keine Lizenzprüfung. Voraussetzungen und Berechtigungen

Wann eine längere Cache-TTL hilft und wann sie Geld kostet

Eine längere Cache-Laufzeit kann sich lohnen, wenn ein Entwickler nach einer Pause mit demselben Kontext weiterarbeitet. Bei einem Agenten mit unabhängigen Aufgaben pro Aufruf sieht die Wiederverwendung anders aus.

Anthropic dokumentiert fünf Minuten als Standard-Cache-Laufzeit und optional eine Stunde mit höheren Schreibkosten. Die längere Variante kann bei Wiederverwendung nach fünf Minuten helfen; sie ist kein pauschaler Rabatt. Prompt Caching

Für einen Vergleich würde ich Aufgabenmix und Modell gleich halten und Cache-Erstellung, Cache-Lesevorgänge, ungecachten Input und Output messen. Das Präfix muss tatsächlich wiederverwendbar sein. Wird der Prompt jedes Mal verändert, kann die gewünschte Optimierung ausbleiben, obwohl die Einstellung korrekt verteilt wurde.

Ich würde Kosten je akzeptierter, fertig erledigter Aufgabe vergleichen, einschließlich zusätzlicher Versuche und menschlicher Korrekturen.

Budgets, Pakete und Benachrichtigungen

Budgets & Limits hat eigene Ansichten für Abteilungen, Personen und Tools. Der gemeinsame Kopf zeigt Monatsbudget, Verbrauch, Auslastung und aktive Alerts.

Abteilungsstandards und wiederverwendbare Pakete

Die Abteilungsansicht verbindet Mitglieder mit einem Standardpaket, Monatslimit und aktuellem Verbrauch. Ein Standard hilft beim Onboarding. Besondere Workloads brauchen eine dokumentierte Ausnahme mit Verantwortlichem.

Unter Budget Packages werden wiederverwendbare Tool-Zuteilungen definiert. Die sichtbaren Stufen Standard, Pro und darüber sind Beispiele für interne Budgets. Es sind keine AgentDome-Produktpreise.

Nutzer-Ausnahmen und Limits je Client

User Budgets & Allocation zeigt vererbte Zuteilungen, Pakete und individuelle Ausnahmen. So muss wegen eines einzelnen Workloads nicht der Standard einer ganzen Abteilung steigen. Die Ausnahmen sollten regelmäßig geprüft werden.

Client Tool Limits zeigt Budgets für Tools wie Claude Code, Codex und Cursor. Eigene Tools lassen sich ergänzen.

Eine Benachrichtigung ist noch kein harter Stopp

Policy & Alert Rules enthält Warn- und Überschreitungsschwellen, Wartezeiten zwischen Meldungen, Kanäle und Empfänger. Der sichtbare Text zu Automated Spend Threshold Enforcement beschreibt fortlaufende Prüfungen und Slack-Benachrichtigungen.

Diese Ansicht belegt keine Sperre des nächsten Modellaufrufs am Budgetlimit. Kläre je Integration: Wird eine Nachricht gesendet, der Client umkonfiguriert oder ein providerseitiges Limit durchgesetzt? Prüfe auch die Verzögerung zwischen Verbrauchserfassung und Richtlinienprüfung.

Im Alert Feed waren keine aktiven Einträge vorhanden. Ich habe keine Testbenachrichtigung gesendet. Im Pilot würde ich Warnung, Überschreitung, Wartezeit und Rückkehr in den Normalbereich mit den vorgesehenen Empfängern testen.

Eine FinOps-Frage stellen und das Ergebnis prüfen

Der AI Chat bietet Einstiege zu Nutzungstrends, aufwendigen Aufgaben, Verbrauchern, aktiven Tools und Einsparungen. Ich habe die Frage nach Einsparpotenzial gewählt. Als Antwort kamen eine kurze Erklärung und eine Tabelle mit Vorschlägen sowie Aktionen für PDF, Excel und CSV.

Öffne anschließend die passende Empfehlung und prüfe Zeitraum und Evaluation. Die älteren Modellnamen in dieser Demo-Antwort sind keine aktuellen Modellempfehlungen.

Halte für jede Änderung den Workload, den Verantwortlichen, die Belege und den nächsten Test fest. Eine Aussage wie „zero quality loss“ braucht passende Testergebnisse.

Einsparungen mit dem Ausgangswert vergleichen

Reporting hat Wochen- und Monatsansichten, einen Kostenverlauf mit Baseline, ausgewiesene realisierte Einsparungen und umgesetzte Empfehlungen. Die Kategorien umfassen Modellanpassung, Caching, Routing, MCP-Kontextbereinigung und Budgetlimits. In der Tabelle werden Änderungen mit Umfang, Datum und ausgewiesener Wirkung verknüpft.

Das Detail einer umgesetzten Caching-Empfehlung enthält Vorher-Nachher-Konfiguration, Cache-Hit-Informationen und Qualitätsangaben. Diesen Nachweis würde ich ans Change-Ticket hängen. Die Werte hier sind Staging-Daten.

Eine ruhigere Woche senkt Kosten auch ohne Optimierung. Mehr erfolgreich erledigte Aufgaben können den Gesamtverbrauch erhöhen und trotzdem die Kosten pro Aufgabe senken. Für eine Bewertung würde ich vergleichbare Aufgaben über definierte Zeiträume betrachten und Folgendes einbeziehen:

• Herstellerverbrauch sowie Cache-Schreib- und Lesevorgänge.
• Akzeptierte Ergebnisse, Wiederholungen und fehlgeschlagene Läufe.
• Latenz und menschlichen Korrekturaufwand.
• Feste Lizenzen, Plattformkosten und Collector-Betrieb.
• Aufwand für Umsetzung und Pflege der Änderung.

Halte geschätzt, umgesetzt und gemessen im Reporting auseinander. Die Prognose einer Empfehlung wird erst dann zu einem gemessenen Ergebnis, wenn die dazugehörigen Verbrauchs- und Ergebnisdaten vorliegen.

Datenquellen, Datenschutz und Betriebseinstellungen

In Settings sind OpenAI, Anthropic, Cursor, Microsoft Foundry, AWS Bedrock, LiteLLM und Microsoft Copilot in der Demo als verbunden aufgeführt. Bei den Identitätsquellen sind Okta und Microsoft Entra ID verbunden. Google Workspace steht zur Verfügung, ist in dieser Sitzung aber nicht angebunden.

Weitere Einstellungen betreffen SSO, Berichtswährung, Aufbewahrung, Intensität der Empfehlungen, Standardlimits und den Wochenbericht. In dieser Sitzung hatte ich nur Lesezugriff.

AgentDome beschreibt lokale Verarbeitung sensibler Inhalte und die Übermittlung benötigter Metadaten. Lass dir Feldliste und Bereitstellungsdiagramm geben, um zu prüfen, was lokal bleibt und was das Netzwerk verlässt. AgentDome-Sicherheitsartikel

Bei Claude Code kann OpenTelemetry Nutzungsinformationen liefern; für die Erfassung von Prompt-Inhalten gibt es eigene Einstellungen. Kläre zuerst, welche Daten für Zuordnung und Optimierung gebraucht werden, bevor Inhalte erfasst werden. Claude-Code-Monitoring

Prüfe Collector-Ausgangsverkehr, Datenstandort, Connector-Berechtigungen, Secret-Rotation, Aufbewahrung, Löschung und den Zugriff auf individuelle Nutzungsdaten. Prüfe die Freigabe von Intune-Schreibrechten getrennt von den Leserechten bei den KI-Anbietern.

So würde ich den ersten Pilot aufsetzen

Ich würde mit einem Coding-Client, einem verantwortlichen Team und einer rückgängig machbaren Änderung starten. Dadurch bleibt der Vergleich nachvollziehbar, und Entwickler wissen, wohin sie eine Verschlechterung melden können.

1. Aufgabe festlegen. Wiederkehrende Arbeit mit Abnahmekriterium auswählen, statt beliebige Chat-Aktivität zu messen.
2. Zuordnung klären. Identitäten, Tools und Abrechnungsdaten verbinden; unbekannten Verbrauch untersuchen.
3. Ausgangswert erfassen. Repräsentative Aufgabenkosten, erfolgreiche Abschlüsse, Latenz und Korrekturaufwand dokumentieren.
4. Eine Empfehlung prüfen. Client-Unterstützung und Evaluation klären, bevor die Zielgruppe gewählt wird.
5. Verteilung und Rückweg vorbereiten. Skript, Ausführungskontext, frühere Werte, Zeitplan und Ausnahmen prüfen.
6. An einen Testring verteilen. Gerätenachweis und wirksamen Client-Zustand verlangen; Offline-Geräte nicht als erfolgreich zählen.
7. Vergleichen und entscheiden. Nur ausweiten, wenn die fertige Arbeit bei akzeptabler Qualität günstiger wird. Sonst die vorherige Konfiguration wiederherstellen und die Ursache prüfen.

Bevor die nächste Gruppe dazukommt, geh Befund, freigegebene Änderung, Gerätenachweis und spätere Aufgabenkosten mit dem Workload-Verantwortlichen durch.