Why we never see your prompts and how that works

The architecture

Tokeven's wrapper runs in your environment — your machine, your server, your container. It sits between your code and the provider SDK. When a call completes, it reads the usage metadata from the response and pushes a small event to Tokeven's ingest API.

What we receive

• -Model ID (e.g., claude-sonnet-4-6)
• -Token counts (input, output, cache-read, cache-write)
• -Latency in milliseconds
• -A session identifier (for grouping related calls)
• -Developer identifier (for attribution)

What we never receive

• -Prompt content
• -Completion content
• -API keys
• -File contents or code

Why this matters

Most analytics tools ask you to proxy your traffic through their servers. That means they see everything — your prompts, your completions, your keys. Tokeven doesn't work that way.

The wrapper runs locally. It reads the response object's usage field after the call completes. The prompt text is never serialized, never transmitted, never stored anywhere but your machine.

The ingest token

Authentication to Tokeven uses a write-only ingest token (tkv_ing_...). It can only push metrics — it can't read your data, can't access your account settings, and can't be used to make API calls to any provider. If it leaks, the worst case is someone pushes fake metrics to your dashboard.

Verification

The wrapper is open source. You can read exactly what it captures and transmits. The ingest API validates the schema and rejects anything that includes content fields.