# Cost control, layer by layer
## The steps
1. Split work into projects: one project per environment (dev, staging, prod) and per major workload. Project-scoped API keys mean a leaked dev key cannot touch production spend.
2. Set a budget or spending limit per project in the dashboard before launch. The alert that fires at 80% of budget is worth more than the invoice review at 200%.
3. Watch the rate-limit headers, especially `x-ratelimit-limit-project-tokens`. Project-level token limits cap how fast one project can burn; treat a project hitting its limit as a signal to investigate, not just a limit to raise.
4. Scope every key to the minimum it needs. Keys used in browsers or client apps must be ephemeral session keys minted server-side, never long-lived secret keys shipped in a bundle.
5. Log token usage per feature, not just per project. Attribute spend to the feature that caused it: embeddings, batch jobs, realtime sessions, evals. The line item that surprises you is the one you were not tracking.
6. Review weekly for the first month, monthly after. Look for: token growth without traffic growth, a model upgrade that quietly doubled cost per request, batch jobs that should have been cached prompts.
## The trap
One org-wide key and no budgets. Everything works until a bug loops on a reasoning model overnight. By the time finance notices, the money is gone and nobody knows which feature spent it.
## Checklist
- Separate projects and keys per environment.
- Budgets or limits set before launch, alerts firing.
- Project token limits understood and monitored.
- No long-lived keys in client-side code.
- Spend attributed per feature and reviewed on a schedule.