← ClaudeAtlas

ai-cost-tracking-and-guardrailslisted

Use when adding or changing any LLM call in a system that handles regulated or sensitive data (health records, financial data, other personal information) or that needs hard cost control: provider fallover between vendors, rate limiting, per-session or per-tenant cost caps, or making sure every call is tracked and priced.
HamzaYM/reliable-ai-skills · ★ 0 · AI & Automation · score 67
Install: claude install-skill HamzaYM/reliable-ai-skills
# AI cost tracking and safety guardrails Every LLM call in a production system costs real money and, in a lot of real systems, also carries sensitive or regulated data. Both problems get solved the same way: make the safe/tracked path the only path that's easy to write, and enforce it with an automated check rather than a code-review convention that erodes over time. ## Guardrail 1: every call is tracked, with an explicit opt-out The failure mode to design against is a new LLM call that quietly bypasses your cost/usage tracking because it was written against the raw SDK client instead of your tracked wrapper. Enforce this with a static check (a script that greps for raw provider-client usage and diffs against an allowed baseline), wired into your test suite so it runs on every change, not just something a reviewer might remember to check. Two things make this actually hold up: - **The check needs to catch direct instantiation, not just direct function calls.** A grep for "raw call" typically misses `new ProviderClient(...)`. Wrap the instance yourself immediately after constructing it. - **The opt-out must be explicit and local.** If a script, test, or one-off tool genuinely can't build the tracking context, require an explicit `{ untracked: true }` (or equivalent) on the same line as the call, never a silent bypass. That keeps the opt-out visible to the same grep that catches accidental misses. - **Tracking failures should fail loud, not swallow silently.** If writing a