The core principle: metadata is enough
Here is the entirety of what one Weckr log event contains:
{
"userId": "u_8f3k2", // your opaque id, never an email
"feature": "doc-summary",
"model": "claude-sonnet-4-6",
"provider": "anthropic",
"inputTokens": 1500,
"outputTokens": 500,
"cachedTokens": 1200,
"latencyMs": 840,
"planName": "pro",
"planRevenueUsd": 29
}No prompt text. No model output. No names, emails, or content of any kind. Cost is recomputed server side from the token counts and current provider rates, so the client’s opinion of cost is ignored, which also means a compromised client cannot deflate its own bill. Everything the dashboard shows, per user cost, per feature cost, margin, caps, is derived from events of this shape.
Refusing PII instead of discouraging it
The obvious leak in metadata only systems is the user id field: send jane@company.comas the id and your metadata is suddenly personal data. Weckr’s API validates for this and rejects user ids or feature labels that look like email addresses or card numbers with a 400, asking for a hashed or opaque identifier instead. The safe pattern is your database primary key or a hash of it: stable for attribution, meaningless to anyone else. The wider identifier hygiene topic is covered in the docs section on PII and user identifiers.
Beside the request path, never in it
- Logging is fire and forget. The SDK sends the event after your LLM call has already resolved. Zero added latency, and a failed log drops silently rather than surfacing to your user.
- Cap checks fail open. If Weckr is unreachable, the check allows the call. An outage of a monitoring tool must never take your product down; the tradeoff, a brief enforcement gap during our outage, is the right one, and it is documented rather than discovered. Details in what to do when the Claude API is down.
- Auth fails closed. The exception: an invalid or revoked key throws instead of silently disabling enforcement, because failing open on a broken config would mean caps quietly off.
Verify, don’t trust
- The SDKs are MIT licensed and public: read exactly what leaves your process at github.com/Ghiles3232/weckr-sdks, TypeScript and Python, small enough to audit in a sitting.
- API keys are 128 bit random, scoped to a single project, and rotatable from the dashboard. The database is hosted in the EU with row level security on every table.
- The five questions for any vendor in this category, including us: which fields leave my server, can I read the client source, are you in my request path, when do you fail open versus closed, where does data live. Refusing to answer any of them in writing is itself an answer.
FAQ
Is it safe to use an AI cost tracking tool?
It can be, if the tool is built to see as little as possible. The questions that decide it: does it receive your prompts and outputs or only metadata, does it sit in your request path where its outage becomes yours, can leaked data identify your users, and can a client forge cost figures. A well designed tracker needs none of that exposure: token counts, model names, latency, and an opaque user id are enough for complete cost math.
Does Weckr see my prompts or my users’ data?
No, structurally. The SDK sends metadata only: model, provider, token counts, latency, your feature label, plan price, and the user identifier you choose. Prompt text and model output are never transmitted. The API also actively rejects user ids or feature labels that look like emails or card numbers, asking you to send an opaque id instead, so PII is refused rather than merely discouraged.
What happens to my app if the cost tracker goes down?
For Weckr, nothing, by design. Logging is fire and forget after your LLM call resolves, so it adds no latency and a failed log drops silently. Spending cap checks fail open: if the API is unreachable, the call is allowed. A monitoring outage must never become your product outage. The one deliberate exception is a revoked or invalid API key, which fails closed so a broken config cannot silently disable enforcement.
Can a malicious client fake its own costs?
Not the figure that matters. Weckr recomputes cost server side from the reported token counts and its own price table, ignoring any client supplied cost. Requests are idempotent on an event id, keys are 128 bit random, and each key is scoped to one project. Attribution is only as honest as the token counts your server sends, which come from the provider’s own usage object.
What should I ask any vendor before sending them usage data?
Five questions: exactly which fields leave my servers, is the SDK source readable, are you in my request path or beside it, do you fail open or closed and when, and where does the data live. For Weckr: metadata only, MIT licensed SDKs you can read, beside the path, fail open except on auth, EU hosted database. Any vendor should answer all five in writing without hedging.
Keep reading
Safe by architecture, not by promise
The honest pitch is structural: Weckr cannot leak what it never receives, cannot slow what it never sits in front of, and cannot be gamed on figures it recomputes itself. The rest is verifiable in the open SDKs and visible in the live demo. The wider playbook is the AI cost and margin guide.