Observability für Agenten: Kosten, Tokens und Runs erfassen

Nach dem Deployment des ersten KI-Agenten verarbeitet dieser 500 Requests an einem Tag. Das Team weiß jedoch nicht, wie viele Tokens er verbraucht hat, welche Kosten entstanden sind oder warum 12 % der Requests unbemerkt fehlgeschlagen sind. Genau hier beginnt das Observability-Problem.

Klassische APM-Tools wurden für Request-Response-Muster entwickelt: Latenz-Perzentile, Fehlerraten und Durchsatz. KI-Agenten passen nicht in dieses Schema. Sie führen mehrere LLM-Calls pro Request aus, ihre Token-Nutzung schwankt stark mit dem Kontext und lange Inputs können die Kosten verzehnfachen. Agenten-Workloads brauchen eine darauf zugeschnittene Observability.

Was Agenten-Observability anders macht

Wenn ein Nutzer einem Agenten eine Nachricht sendet, passiert im Hintergrund viel. Der Agent kann:

• 1.Retrieval nach Kontext abfragen (RAG-Retrieval)
• 2.Einen ersten LLM-Aufruf ausführen, um über den Request nachzudenken
• 3.Zwei bis drei Tool-Aufrufe ausführen (API-Anfragen, Datenbankabfragen)
• 4.Mit einem weiteren LLM-Aufruf die Ergebnisse zusammenführen
• 5.Optional einen anderen Agenten für spezialisierte Aufgaben aufrufen

Jeder Schritt verbraucht Tokens und kann fehlschlagen. Klassische Metriken wie die durchschnittliche Antwortzeit verbergen das. Jede Phase muss einzeln nachvollziehbar sein.

Die vier Säulen der Agenten-Observability

Das erste Dashboard erstellen

Connic erstellt beim Start des ersten Projekts ein Standard-Dashboard. Den größten Nutzen bringt jedoch die Anpassung. Das Dashboard sollte die Daten zeigen, die das Team tatsächlich auswertet:

Schritt 1: Zu Observability navigieren

In der Projektseitenleiste auf Observability klicken. Das Standard-Dashboard enthält vorkonfigurierte Widgets für Total Runs, Success Rate, Token-Nutzung und Kosten.

Schritt 2: Edit Mode öffnen

Oben rechts auf Edit klicken. Im Edit Mode lassen sich Widgets per Drag-and-drop verschieben sowie hinzufügen, entfernen oder konfigurieren.

Schritt 3: Widgets hinzufügen

Auf Add Widget klicken und einen von drei Widget-Typen auswählen:

Schritt 4: Nach Agenten filtern

Die meisten Widgets lassen sich nach Agenten filtern. Bei mehreren Agenten mit unterschiedlichen Aufgaben eignen sich eigene Widgets pro Agent oder ein gemeinsames Vergleichsdiagramm.

Token-Kosten verstehen

Die Token-Nutzung bestimmt die LLM-Kosten, aber nicht alle Tokens sind gleich:

Bei großen Providern kosten Output-Tokens typischerweise drei- bis achtmal so viel wie Input-Tokens. Die aktuellen Verhältnisse der KI-Modell-Preisstufen finden sich beispielsweise in OpenAIs aktuellen API-Preisen. Wirken die Kosten hoch, sollte zuerst die Output-Nutzung geprüft werden. Lange, ausführliche Antworten sind meistens die Ursache.

KI-Modell-Preise einrichten

Token-Anzahlen zeigen den Verbrauch. Erst die zugehörigen Geldbeträge machen deutlich, welche Kosten entstehen. Mit den Preisen der verwendeten KI-Modelle lassen sich Tokens in Kosten umrechnen.

Globale Defaults

Connic enthält globale Preise für verbreitete KI-Modelle. Diese Einträge tragen in den Pricing Settings ein Global-Badge. Für gängige KI-Modelle wie GPT, Claude Sonnet oder Gemini ist keine Konfiguration nötig, um Kosten zu erfassen.

Eigene KI-Modell-Preise

Für feinabgestimmte oder selbst gehostete KI-Modelle sowie abweichende Preise lässt sich unter Settings > Token Pricing über Add Pricing ein eigener Preis hinterlegen.

# Exact model match
openai/gpt-5-mini
anthropic/claude-haiku-4-5
gemini/gemini-2.5-flash

# Regex pattern for model families
openai/gpt-5.*          # Matches all GPT-5 variants
anthropic/claude-.*      # All Claude models
gemini/gemini-.*         # All Gemini models

Alle Preise gelten pro Million Tokens. Preise auf Projektebene überschreiben die globalen Standardwerte. So lassen sich Kosten für einzelne Anwendungsfälle anpassen, ohne andere Projekte zu beeinflussen.

Volumenabhängige Preisstufen

Einige Provider verwenden mit steigendem Token-Volumen progressive Preisstufen. Jeder Schwellenwert sorgt dafür, dass Tokens darüber mit dem entsprechenden Satz berechnet werden:

Workflows mit mehreren Dashboards

Ein einzelnes Dashboard deckt selten alle Anforderungen ab. Unterschiedliche Perspektiven profitieren von getrennten Dashboards:

• -Ein Executive Overview liefert Kosten und Erfolgsmetriken auf hoher Ebene für wöchentliche Reviews
• -Ein Debugging Dashboard bündelt aktuelle Runs, Fehlerraten und Logs für On-Call Engineers
• -Eine Ansicht zur Kostenoptimierung verbindet Token-Aufschlüsselungen und Kostentrends für die Budgetplanung
• -Ein Agenten-Vergleich zeigt die Metriken verschiedener Agentenkonfigurationen beim A/B-Testing direkt nebeneinander

Beim Einstieg kann ein Standard-Dashboard geladen werden, mit einem eigenen Standardzeitraum pro Dashboard. Das Executive Overview kann 30 Tage zeigen, das Debugging Dashboard dagegen nur die letzte Stunde.

Echtzeit-Monitoring

Dashboards aktualisieren sich alle zehn Sekunden. Der Indikator Last updated zeigt die Aktualität der Daten. Bei Incidents lassen sich Fehler live verfolgen, ohne manuell zu aktualisieren.

Häufige Muster und Anti-Patterns

Erste Schritte

Observability ist in allen Connic-Projekten verfügbar. Die ersten Schritte:

• 1.Einen Agenten bereitstellen und einige Anfragen ausführen, um Daten zu erzeugen
• 2.Im Projekt Observability öffnen
• 3.Das Standard-Dashboard prüfen und anschließend an die relevanten Anforderungen anpassen
• 4.Für eine präzise Kostenerfassung die KI-Modell-Preise unter Settings > Token Pricing konfigurieren

Observability zeigt, was die Agenten getan haben und was es gekostet hat. Um zu messen, ob die Ausgabe die festgelegten Kriterien erfüllt, lässt sie sich mit automatisierter Agentenbewertung kombinieren: Ein LLM-Judge bewertet jede Ausführung nach diesen Kriterien und verfolgt Qualitätstrends im Zeitverlauf.

Im Quickstart-Leitfaden lässt sich ein erster Agent bereitstellen. In der Agentendokumentation sind fortgeschrittene Konfigurationen beschrieben.