KI-Token-Kosten nach Kunde oder Use Case in Connic auswerten

Connic zeigt, welche Kunden und Produktfunktionen die Kosten für KI-Modelle verursachen. Middleware schreibt eine Kennung wie customer_id in jeden Agenten-Run, und Connic gruppiert die Token-Kosten nach diesem Wert, in Dashboards ebenso wie auf der Seite Token Usage. Das Tutorial zeigt, wie die Kennung gesetzt wird, wie Rangliste und Verlauf pro Kunde entstehen und was die Summen nicht erfassen.

Jeden Run mit Kunde oder Use Case kennzeichnen

Jeder Agenten-Run hat einen Run Context, ein Dictionary, das Middleware, Tools und Tool-Hooks während des Runs gemeinsam nutzen. Connic speichert ihn mit dem Run, und jeder Schlüssel darin kann später Token-Kosten gruppieren. Die allgemeine Funktionsweise beschreibt der Artikel zu Run Context; für die Kostenzuordnung genügt ein Schlüssel pro Dimension.

Im Beispiel sendet das Backend einer SaaS-Anwendung Anfragen für einen eingebauten Assistenten an einen Webhook-Connector, der mit dem Agenten support-assistant verknüpft ist. Jede Anfrage enthält das Konto, von dem sie stammt, und die Produktfunktion, die sie auslöst:

{
  "customer_id": "acct_1042",
  "use_case": "ticket-summary",
  "message": "Fasse das offene Ticket für die Support-Leitung zusammen."
}

Die Middleware des Agenten übernimmt beide Werte vor dem Modellaufruf in den Kontext und gibt nur die Nachricht an das Modell weiter:

from typing import Any


async def before(
    content: dict[str, Any], context: dict[str, Any]
) -> dict[str, Any]:
    payload = context["payload"]
    context["customer_id"] = payload.get("customer_id") or "unattributed"
    context["use_case"] = payload.get("use_case") or "unattributed"
    return {"role": "user", "parts": [{"text": payload["message"]}]}

Connic ordnet middleware/support-assistant.py dem Agenten mit dem Namen support-assistant zu und ruft before() auf, bevor der Agent die Anfrage verarbeitet. Der Ersatzwert unattributed sammelt Anfragen ohne ID in einer eigenen, sichtbaren Gruppe. Verschachtelte Werte funktionieren ebenfalls: Nach context["customer"] = {"id": "acct_1042", "plan": "pro"} gruppiert der Schlüssel customer.id nach Konto.

Die ID aus dem eigenen Backend übernehmen

Die Kunden-ID sollte aus einem Wert stammen, dem das Backend bereits vertraut, etwa dem Konto hinter der angemeldeten Sitzung. Aus der Nachricht des Nutzers oder aus einem Tool-Argument, das das Modell ausfüllt, sollte sie nicht kommen. Das Modell kann den falschen Wert übernehmen, und die Nachricht eines Nutzers kann beeinflussen, was das Modell schreibt. Setzt die Middleware die ID aus dem Payload, kommt das Modell mit ihr gar nicht in Berührung. Auch use_case setzt das Backend, passend zur Funktion, von der die Anfrage kommt.

Die ID an Agenten weitergeben, die andere Agenten starten

Startet ein Agent einen anderen über trigger_agent oder als Schritt eines sequenziellen Agenten, läuft dieser als eigener Run mit eigenem Kontext. Er erhält nur die Eingabe, die ihm übergeben wird, nicht den Kontext des Aufrufers. Seine Token-Kosten werden also nur zugeordnet, wenn die ID in dieser Eingabe steht und seine Middleware sie übernimmt. Den Payload von trigger_agent füllt das Modell aus. Zuverlässiger ist deshalb ein Tool-Hook, der die ID vor dem Aufruf aus dem Kontext in den Payload schreibt. In einem sequenziellen Agenten erhält der erste Schritt die ursprüngliche Anfrage und jeder weitere Schritt die Ausgabe des vorherigen. Ein späterer Schritt bekommt die ID also nur, wenn diese Ausgabe sie enthält.

Token-Kosten nach Kunde ordnen

Dashboards öffnen sich über den Bereich Dashboards in der Projekt-Seitenleiste, und ein Dashboard im Bearbeitungsmodus nimmt neue Widgets auf. Ein Bar Chart mit diesen Einstellungen ordnet Kunden nach ihren Kosten:

• Group By: By Context
• Context Key: customer_id
• Metric: Token Cost
• Number of items to show: bis zu 20

Das Chart umfasst den Zeitraum des Dashboards und das gewählte Environment. Ein zweites Bar Chart mit dem Schlüssel use_case ordnet Produktfunktionen auf dieselbe Weise. Mit Token Usage als Metrik ergibt sich die Rangfolge aus den Tokens statt aus den Kosten, mit Run Count aus der Anzahl der Runs. Bei Token Cost zeigt die Begleitmetrik zu jedem Wert die Token-Summe neben den Kosten. Die weiteren Optionen beschreibt die Dashboard-Dokumentation.

Include Judge Tokens ist standardmäßig aktiviert. Connic rechnet jede Judge-Bewertung dem Kontextwert des bewerteten Runs zu. Ein Kunde, dessen Runs häufiger bewertet werden, trägt also auch diese Bewertungskosten. Ist die Option aus, lässt das Chart Judge-Bewertungen weg.

Einen Kunden im Zeitverlauf verfolgen

Wann sich die Kosten eines Kunden verändert haben, zeigt ein Area Chart mit Token Cost und dem Filterausdruck context.customer_id == 'acct_1042'. Es stellt die Kosten dieses Kunden über den gewählten Zeitraum dar. Eine Stat Card mit der Metrik Token Cost und demselben Filter zeigt die Summe.

Damit dieselben Widgets für alle Kunden funktionieren, kommt ein Input Widget mit dem Variablennamen customer hinzu, und der Filter lautet context.customer_id == '{customer}'. Eine im Input eingetragene Konto-ID aktualisiert dann jedes Widget, das darauf verweist; ein leeres Eingabefeld entfernt die Bedingung. Ein Auswahlfeld kann seine Optionen aus einer Datenbank-Collection des Projekts laden, zum Beispiel aus einer Liste der Kundenkonten.

Monatssummen auf der Seite Token Usage

Für Abrechnungszeiträume gruppiert die Seite Token Usage dieselben Daten nach Kalendermonat. Der Tab By Context nimmt einen Kontextschlüssel entgegen, mit Punkten für verschachtelte Schlüssel, und zeigt pro Tag einen Balken, der nach Werten aufgeteilt ist. Unter dem Chart listet die Rangliste alle Werte des Monats auf (das Bar Chart zeigt höchstens 20) und teilt die Kosten jedes Werts auf die Spalten Input, Output, Thinking, Cached und Judge auf.

Dieselbe Gruppierung ist auch außerhalb des Dashboards verfügbar. Die REST-Endpunkte budgets/daily-cost und budgets/agent-ranking akzeptieren group_by=context.customer_id. Das eignet sich für einen monatlichen Export in ein separates Abrechnungssystem. Über Connic MCP kann ein KI-Client direkt fragen, welche Kunden in diesem Monat die höchsten Kosten haben.

Die Zahlen prüfen, bevor Entscheidungen fallen

Bevor eine Rangliste in eine Preisentscheidung oder ein Kundengespräch einfließt, zeigen einige Prüfungen, ob sie die erwarteten Kosten vollständig abdeckt.

Runs ohne Wert

Ein Bar Chart mit Token Cost fasst Runs ohne den Schlüssel unter Unknown zusammen, die Seite Token Usage zeigt sie als (not set). Mit Token Usage oder Run Count als Metrik lässt das Bar Chart diese Runs weg. Ein großer Anteil ohne Wert deutet meist auf einen Agenten ohne die Middleware hin, auf einen aufgerufenen Agenten, der die ID nie erhalten hat, oder auf einen Schlüssel, der zwischen Agenten unterschiedlich geschrieben ist. Mit dem Ersatzwert unattributed aus dem Beispiel landen Anfragen ohne ID in einer eigenen Gruppe. Der verbleibende Anteil ohne Wert verweist dann auf Agenten, die den Schlüssel nie setzen.

Preisabdeckung

Fehlen für einzelne Modellaufrufe Nutzungs- oder Preisdaten, zeigt das Widget den Hinweis Cost unavailable. Sein Tooltip nennt, wie viele Aufrufe exakte Kosten haben, und listet die betroffenen Modelle auf. Das kann passieren, wenn ein Run endet, bevor das Modell seinen Nutzungsbericht sendet. Fehlt für ein BYOK-Modell der Preis, hilft ein Preiseintrag in den Token-Pricing-Einstellungen des Projekts. Connic berechnet aufgezeichnete Aufrufe bei Preisänderungen neu und verwendet für jeden Aufruf den Eintrag, der zu seinem Zeitpunkt galt. Ein später angelegter Eintrag deckt daher auch frühere Runs in seinem Gültigkeitszeitraum ab.

Währungen

connic/*-Modelle werden in EUR berechnet, BYOK-Modelle in der Währung ihres Preiseintrags, USD oder EUR. Connic hält beide Währungen getrennt: Ein Bar Chart zeigt eine Rangliste pro Währung, und die Tabelle unter Token Usage nennt für jeden Wert beide Beträge. Die Einstellung Cost Display unter Token Pricing oder die Option Currency eines Widgets rechnet alles in EUR oder USD um, mit dem täglichen Referenzkurs der Europäischen Zentralbank zum Datum des Aufrufs. Umgerechnete Summen sind Schätzwerte und können von Anbieterrechnungen abweichen.

Was Token-Kosten umfassen

Token-Kosten umfassen die Tokens der KI-Modelle, einschließlich der Tokens von Judge-Bewertungen, sofern Include Judge Tokens aktiviert ist. Run-Starts, abgeschlossene Judge-Bewertungen, Laufzeit, Websuchen, extrahierte Seiten, Browser-Sitzungen, Speicher und Retrieval werden ebenfalls vom Projektguthaben abgebucht, erscheinen aber auf der Billing-Seite, nicht in diesen Auswertungen. Soll ein Kundenpreis die gesamten Kosten für diesen Kunden decken, ist der Token-Betrag die Untergrenze.