Engineering · 2 min read
The four laws of a cost SDK
An SDK that sits on every AI call is in the critical path of your product. If it can break your app, it shouldn't exist. Here are the rules ours is built around.
By Akhil Anand · October 8, 2026
The fastest way to lose a customer's trust is to cause an outage in a tool they installed to save money. A cost SDK wraps every AI call a product makes. That's an enormous amount of leverage over someone else's uptime, and it should come with rules that don't bend.
These are the four AtlasBurn's SDK is built around.
Law 1: Never crash the host
Every code path in the SDK is wrapped. Parsing a provider response that changed shape, a malformed stream chunk, a network error to our own servers — none of it can throw into your application. If instrumentation breaks, instrumentation stops. Your product doesn't.
Law 2: Never block the host on our account
The SDK checks the guardrail gate before a call, and that check fails open. If AtlasBurn is slow or unreachable, your request goes through untouched. Telemetry is queued and flushed in small batches in the background, with retries and backoff, never on your request path.
There is exactly one case where the SDK stops a call: when you configured a guardrail and it tripped. Even then it doesn't throw an exception your code wasn't written to handle. It returns a provider-native HTTP 429 with Retry-After and an x-atlasburn-blocked header, so the error-handling you already wrote for rate limits does the right thing.
Law 3: Never leak secrets or content
The SDK sends model names, token counts, and latency. That's it. When a provider doesn't report usage, the SDK estimates tokens locally and sends only the estimate, flagged as estimated. Prompts and outputs never leave your process. API keys are never logged, and on our side ingest keys are stored only as salted HMAC hashes.
Law 4: Fail silently — but not invisibly
Silent failure protects the host. Invisible failure hurts the customer, because a cost tool that quietly reports $0 is worse than no tool. So the SDK exposes an onError hook with structured diagnostics: zero usage on a successful response, a stream that ended without usage data, a gate error, a failed flush. Your app keeps running, and you still find out when something's off.
Fail open for your users. Fail loud for your engineers. Those aren't in tension — they're two different audiences.
Why laws, not features
Features get traded off under deadline pressure. Laws don't. Every change to the SDK is checked against these four, and a feature that would break one doesn't ship. That's what it takes to earn a place on every AI call a company makes.