You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GDPR-aware usage ledgers: what do you track per API call?
#51
If your app calls DeepSeek, Kimi, Qwen, GLM, MiniMax, or ERNIE behind an OpenAI-compatible gateway like AIWave, raw request logs are a weak source of truth for cost and privacy audits.
Most teams I've talked to store either too much (full prompt text, indefinite retention) or too little (just a model name and total tokens).
What I've been experimenting with
A minimal usage ledger per billable API call — append-only, queryable, no prompt text:
Field
Why
request_id
Join traces and support tickets
tenant_hash
Account-level cost without direct identifiers
task_class
Separate coding / extraction / chat / batch
model
Make routing and fallback visible
cached_input_tokens
Required for cache-aware pricing
uncached_input_tokens
Separate from cached for correct billing
output_tokens
Usually the biggest cost driver
retry_count
Retries quietly inflate bills
fallback_from
Did a cheaper model fail validation?
estimated_usd
Cost at request time
price_source_url + price_checked_at
Where the rate came from and when
retention_class
aggregate_only, debug_7d, audit_90d
Key principle: don't store prompts in the ledger. A row like "German tenant, invoice extraction, Kimi model, validation failed, fallback to DeepSeek, 1 retry, $0.00042" is enough to debug routing and billing without storing the invoice itself.
Real pricing snapshot (AIWave, 2026-08-05)
Model
Input $/1M
Output $/1M
Cached $/1M
deepseek-v4-flash
0.10
0.21
0.02
deepseek-v4-pro
0.54
1.09
0.27
kimi-k2.6
0.55
2.30
0.09
glm-5-turbo
0.90
2.70
0.24
qwen3.5-122b-a10b
0.25
1.86
n/a
minimax-m2.5
0.25
1.00
n/a
Full article with Python + JS code examples: Dev.to
Questions for the community
What fields are in your AI cost tracking? Anything beyond token counts and model name?
How do you handle tenant identification without storing PII? Hashed IDs? Pseudonymous tokens?
Do you separate cached vs uncached input tokens in your billing? With DeepSeek and GLM offering cache discounts, this matters.
What's your retention policy for AI call metadata? Do regulators ask about this?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Context
If your app calls DeepSeek, Kimi, Qwen, GLM, MiniMax, or ERNIE behind an OpenAI-compatible gateway like AIWave, raw request logs are a weak source of truth for cost and privacy audits.
Most teams I've talked to store either too much (full prompt text, indefinite retention) or too little (just a model name and total tokens).
What I've been experimenting with
A minimal usage ledger per billable API call — append-only, queryable, no prompt text:
request_idtenant_hashtask_classmodelcached_input_tokensuncached_input_tokensoutput_tokensretry_countfallback_fromestimated_usdprice_source_url+price_checked_atretention_classaggregate_only,debug_7d,audit_90dKey principle: don't store prompts in the ledger. A row like "German tenant, invoice extraction, Kimi model, validation failed, fallback to DeepSeek, 1 retry, $0.00042" is enough to debug routing and billing without storing the invoice itself.
Real pricing snapshot (AIWave, 2026-08-05)
Full article with Python + JS code examples: Dev.to
Questions for the community
Discuss 👇
All reactions