Nutzerkosten für KI-Anwendungen präzise zuordnen – so geht’s

Die ersten Erfolge mit deiner KI-Funktion sind da – doch plötzlich zeigt dein OpenAI-Konto eine Rechnung von 400 US-Dollar. Wer hat welche 5 Cent verursacht? Diese Frage nach den Nutzerkosten pro Anfrage wird in der Praxis oft unterschätzt. Dabei lässt sich die Zuordnung überraschend einfach umsetzen, wenn man die richtigen Werkzeuge nutzt.

Drei bewährte Ansätze haben sich in der Praxis durchgesetzt. Sie unterscheiden sich vor allem im Aufwand für die Implementierung, liefern aber alle dasselbe Ziel: eine lückenlose Kostenzuordnung pro Endnutzer.

KI-Client direkt einbinden – der schnellste Weg

Diese Methode eignet sich für Anwendungen mit einer zentralen Instanz des KI-Anbieters wie OpenAI oder Anthropic. Innerhalb weniger Minuten lässt sich die Kostenverfolgung integrieren.

import OpenAI from 'openai'
import { wrapOpenAI, withTrace } from '@voightxyz/openai'

// Client mit Trace-Funktion einbinden
const openai = wrapOpenAI(new OpenAI(), {
  agent: 'production-chat-api',
})

// API-Endpunkt definieren
app.post('/api/chat', async (req, res) => {
  await withTrace(
    async () => {
      const response = await openai.chat.completions.create({
        model: 'gpt-4o-mini',
        messages: req.body.messages,
      })
      res.json({ reply: response.choices[0].message })
    },
    {
      routeTag: 'POST /api/chat',
      tags: {
        userId: req.user.id,
        plan: req.user.plan,
      },
    },
  )
})

Der entscheidende Schritt ist die Funktion withTrace() am Beginn der Anfrage. Jeder KI-Aufruf innerhalb dieses Blocks erhält automatisch die Nutzer-ID und den Tarif zugewiesen – ohne manuelles Weiterleiten durch den Code. Verantwortlich dafür ist AsyncLocalStorage, das die Tags an alle verschachtelten Funktionen übergibt.

Vorteile:

• Minimaler Implementierungsaufwand
• Funktioniert mit OpenAI und Anthropic

Nachteile:

• Abhängigkeit von spezifischen Wrapper-Bibliotheken

OpenTelemetry-Telemetrie für den Vercel AI SDK

Falls du den Vercel AI SDK verwendest, bietet die experimentelle Telemetrie-Funktion eine nahtlose Integration. Die Nutzerdaten werden automatisch an die OpenTelemetry-Spans angehängt.

import { openai } from '@ai-sdk/openai'
import { streamText } from 'ai'

export async function POST(req: Request) {
  const result = streamText({
    model: openai('gpt-4o-mini'),
    prompt: (await req.json()).prompt,
    experimental_telemetry: {
      isEnabled: true,
      metadata: {
        userId: session.user.id,
        plan: session.user.plan,
      },
    },
  })
  return result.toAIStreamResponse()
}

Die Daten werden als Span-Attribute an jedes OpenTelemetry-kompatible Überwachungstool wie Langfuse, Phoenix oder Datadog weitergegeben. Der Vorteil: volle Unabhängigkeit von der verwendeten Bibliothek.

Vorteile:

• Keine direkte Kopplung an eine bestimmte Bibliothek
• Flexible Wahl des Auswertungstools

Nachteile:

• Nur nutzbar, wenn der SDK bereits OpenTelemetry-Spans unterstützt

Manuelle Ereignisprotokollierung für Hintergrundprozesse

Für autonome Bots oder Hintergrundjobs, die KI-Modelle in Schleifen aufrufen, ist eine manuelle Protokollierung oft die einzige Option. Hier übernimmst du die volle Kontrolle über die erfassten Daten.

import { Voight } from '@voightxyz/sdk'

const voight = new Voight({
  agentId: 'my-bot',
})

const startTime = Date.now()

const response = await fetch(' {
  method: 'POST',
  headers: {
    authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
  },
  body: JSON.stringify({
    model: 'gpt-4o-mini',
    messages: [...],
  }),
}).then((r) => r.json())

voight.log({
  type: 'reasoning',
  model: 'gpt-4o-mini',
  durationMs: Date.now() - startTime,
  outcome: 'success',
  metadata: {
    tokens: {
      input: response.usage.prompt_tokens,
      output: response.usage.completion_tokens,
    },
    tags: {
      userId: job.userId,
      tenantId: job.tenantId,
    },
  },
})

Diese Methode erfordert mehr Code pro Aufruf, bietet aber maximale Flexibilität – besonders wenn der KI-Aufruf nicht in eine klassische HTTP-Anfrage passt.

Vorteile:

• Volle Kontrolle über Protokollierung und Datenformat
• Ideal für komplexe Anwendungsfälle

Nachteile:

• Zusätzlicher Programmieraufwand
• Verantwortung für korrekte Token-Zählung

Welche Fragen du mit Nutzer-Tags beantworten kannst

Sobald die userId in den Metadaten aller KI-Aufrufe enthalten ist, eröffnen sich völlig neue Analyseoptionen.

• Wer verursacht die höchsten Kosten?

Gruppiere alle Anfragen nach tags.userId und summiere die Kosten.

• Subventionieren Free-Tier-Nutzer die Premium-Kunden?

Filtere nach tags.plan: 'free' und sortiere nach Gesamtkosten.

• Hatte ein Release unvorhergesehene Kostenfolgen?

Kombiniere Nutzer-ID mit Zeitstempel, um plötzliche Ausreißer zu identifizieren.

• Wie hoch ist das Kosten-Erlös-Verhältnis pro Kunde?

Verknüpfe die KI-Kosten mit Stripe-Daten über die gemeinsame userId.

Dabei musst du keine zusätzliche Client-Bibliothek einbinden oder die Nutzer-ID in die KI-Anfragen selbst einbetten. Die Tags propagieren automatisch von der Anfragegrenze bis in jeden verschachtelten Aufruf.

Datenschutz und Multi-Tenant-Sicherheit

Verwende als userId immer eine interne, stabile Kennung wie user_a3f9c2 – niemals E-Mail-Adressen oder Wallet-Adressen. Sensible Daten wie die E-Mail gehören nicht in die Telemetrie-Metadaten. Die meisten Beobachtungstools filtern PII ohnehin heraus, aber fehlerhafte Eingaben führen zu unbrauchbaren Ergebnissen.

Für Multi-Tenant-Anwendungen fügst du einen zweiten Tag hinzu:

{
  "tags": {
    "userId": "user_a3f9c2",
    "tenantId": "company_123"
  }
}

Damit kannst du sowohl die Frage "Welcher Kunde ist das?" als auch "Welcher Nutzer innerhalb des Kunden?" beantworten.

Fazit: Ein Modell, drei Umsetzungen

Egal ob du einen KI-Client direkt einbindest, OpenTelemetry nutzt oder manuell protokollierst – das Grundprinzip bleibt gleich: Weise die Nutzer-ID am Anfang der Anfrage zu und lasse sie automatisch durch alle verschachtelten KI-Aufrufe propagieren. Die Wrapper-Bibliotheken von Voight unterstützen alle gängigen KI-Anbieter und sind unter Apache-2.0-Lizenz verfügbar.

Die gleiche Methode funktioniert auch mit Langfuse, Phoenix, Braintrust oder deiner bestehenden OpenTelemetry-Pipeline. Der Schlüssel liegt im konsistenten Nutzen der metadata.userId-Struktur – egal welches Tool du letztlich zur Auswertung verwendest. Wie trackst du aktuell die Nutzerkosten in deiner KI-Anwendung? Server-Logs? Stripe-Metering? Oder fliegst du bisher noch blind?