We replaced the quickstart with a prompt

The last few posts covered how usage flows into BurnCap — out-of-band events, idempotent retries, the fail-open budget check. We skipped the boring-but-critical part: how that wiring actually gets into your code. The traditional answer is a quickstart: "install the SDK, call trackUsage after each model call, here's a snippet." We wrote one. Then we deleted it and shipped a prompt instead.

Here's the reasoning, because it's a small bet on where dev tools are going.

The quickstart is written for a workflow people don't use anymore

A quickstart assumes a human reads the docs, understands the SDK, finds every place their app calls an LLM, and translates the example into their codebase by hand. But that's not how a lot of people write integration code now. They open Cursor or Claude Code and say "add BurnCap to this project." The agent does the reading and the wiring.

So the real artifact a dev tool needs to ship isn't a doc for a human to translate — it's the instruction the human will hand to their agent. If we make you translate our quickstart into a good prompt yourself, we've left the hardest, most error-prone step as your homework.

So BurnCap ships the prompt. You pick your stack, copy it, paste it into your agent, and it installs the SDK, finds every server-side LLM call, instruments each one, and — optionally — adds budget guardrails. There are tailored versions for the Vercel AI SDK, the OpenAI / Anthropic / Gemini SDKs, and plain Python.

A prompt can be an executable spec — that's the actual win

Here's the part we didn't expect to matter so much. The value isn't "saves you copy-paste." It's that a prompt can encode the things people get wrong, in a way a snippet can't.

BurnCap's accuracy depends on a few rules that are easy to skim past in docs and quietly break:

• input_tokens must exclude cached tokens; output_tokens must exclude reasoning tokens. Get this wrong and every cost is subtly off.
• Always send a stable request_id — the provider's response id — so a retry doesn't double-count.
• The API key is server-only; it must never reach the browser bundle.
• Tracking is best-effort; it must never block or fail a user's request.
• The budget check fails open — a monitoring outage must never take down your app.

In a quickstart, those are bullet points you hope the reader honors. In the prompt, they're hard rules the agent must follow, with per-stack snippets that already do the token math correctly — including the annoying ones, like Anthropic's cache-creation vs cache-read split and Gemini's "thinking" tokens. The prompt is closer to a spec than a tutorial.

It also includes the parts good integration prompts need but people forget:

• "Discover before you change anything" — list every call site back to us first, find where env vars live, don't expose the key. Guardrails so the agent doesn't go rogue.
• "Minimal, surgical changes" — a thin shared client plus one tracking call per site, no broad refactors, so the diff stays reviewable.
• A verify step — trigger one real call, show us the result, then confirm it appears in the dashboard.

That last one matters: it makes the agent prove the integration works instead of declaring victory. The proof is a real response, not a thumbs-up:

// POST /api/v1/events — first call
{ "inserted": 1 }

// same request_id again — idempotent, nothing double-counted
{ "inserted": 0, "duplicates": 1 }

One source, two surfaces — and your key is already in it

The prompts come from a single source of truth, and they're hand-authored, plain strings — no LLM generates them (the same refusal that keeps a model out of the Insights feature). They're unit-tested, because a wrong instruction is worse than no instruction.

That one source feeds two places:

1. 01A public /prompts page with a placeholder key — a real marketing and discovery surface ("add BurnCap with zero effort") that ranks for people searching how to wire this up.
2. 02The in-app version, where the moment you create an API key the prompt comes back with your real key already baked in. Create key, copy prompt, paste into your agent, done — no "now substitute your key" step to fumble.

What it isn't

It's not magic, and we won't pretend it is. You still read the diff your agent produces — the prompt is deliberately sized so you can (one client, one call per site). Agents vary; the verify step exists precisely because some will claim success without proof. And it changes nothing about the boundaries: these prompts only add out-of-band usage tracking and advisory budget checks. BurnCap still never proxies your traffic and never sees your prompts — the integration teaches those refusals rather than quietly dropping them.

That's the theme of this whole series showing up again: the integration step is one more place to either earn trust or lose it. A prompt that bakes in "server-only key, never block the request, fail open, never store prompts" is the product's values, delivered at the exact moment a developer is deciding whether to trust it.

“People keep asking what makes something "built for the AI era." For us it wasn't adding a model to the product — it was noticing that our users' workflow is now agent-first, and meeting them there.”

Try it

Grab a free key and your stack's prompt is one copy away — paste it into your agent and watch it wire itself in. If you've built integration prompts for your own tool, we'd love to hear what you put in the "hard rules" section; that part taught us the most.