SwiftRelay

← All sprint notes

First Lap: Track Spend by API Key and Project

Cost per lapEN

A single account balance tells you what remains, not which project spent it. To make model costs actionable, connect each request to a project, identify the credential it used, and reconcile your records with billed usage. This first lap builds that trail without assuming a particular dashboard, reporting endpoint, or billing export exists.

1. Define the project boundary before creating keys

Start with the question your report must answer: which product, team, or customer workload generated this cost? Choose stable project identifiers such as support-assistant and document-search. Keep development, staging, and production separate when they have different owners or spending expectations.

Your first deliverable is a project register. Record the project identifier, environment, owner, and internal spending target. Treat that target as a planning threshold, not an automatic spending limit unless you have explicitly implemented enforcement.

2. Assign dedicated keys wherever practical

Use a dedicated API key for each project and environment wherever your account setup supports it. A shared key makes credential-level totals ambiguous: you cannot reliably infer project ownership from the key alone.

If workloads must share a key, capture the project identifier inside your application’s own request records. Do not assume arbitrary metadata sent to an API will appear in billing reports.

  • Give each credential an internal alias, such as support-production-primary.
  • Map that alias to exactly one project whenever possible.
  • Record activation and retirement dates so rotations preserve historical ownership.
  • Never put full API keys into logs, spreadsheets, or reports.

3. Route requests through a consistent client setup

SwiftRelay is a practical option when projects use different model providers but need a common relay. It offers pay-as-you-go, per-token billing and works with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs. Sign up for SwiftRelay to start connecting your project workloads.

The API host is https://api.fastapirelay.com. Claude Code and Gemini CLI use the bare host; OpenAI-compatible SDKs use the host with /v1 appended. Keep credentials in environment variables or a secrets manager, and select the correct project credential before sending a request.

4. Capture a usage record for every attempt

Instrument the point where your application sends model requests. Record one entry per attempt, including retries, rather than only one entry per completed user task. Otherwise, repeated attempts can disappear from your internal accounting.

  • Project identifier, environment, and credential alias.
  • Timestamp, internal operation identifier, and attempt number.
  • Requested model, such as Claude Sonnet 5.5.
  • Returned usage fields, where available, and request outcome.
  • Estimated cost, calculation method, and reconciliation status.

Preserve distinct token categories when returned. Do not assume every token has the same price. For streaming requests, verify that your integration captures final usage information; mark missing usage as unknown rather than recording zero.

5. Separate estimated spend from billed spend

Calculate estimates using the applicable rates and the usage categories you actually receive. Save the rate reference and effective date alongside the calculation. This makes historical estimates explainable when pricing changes.

An estimate is not a settled charge. Reconcile against the authoritative billing information available in your account. If it provides only aggregate totals, reconcile at that level instead of inventing request-level precision. Track unresolved differences explicitly, including missing usage, timing boundaries, and rounding.

6. Roll up costs by key, then by project

Build two views from the same ledger. The key view groups spending by credential alias and reveals unexpected activity or credentials that should have been retired. The project view combines all credentials belonging to a project, including keys replaced during rotation.

Use one reporting timezone and consistent date boundaries. Keep shared-key costs separate unless application records establish ownership. If you allocate unresolved shared costs using a business rule, label that allocation clearly rather than presenting it as measured consumption.

7. Review exceptions before expanding traffic

Before increasing usage, inspect unknown usage entries, unmapped credentials, reconciliation gaps, and projects approaching their internal targets. Assign an owner to each exception. Your first successful lap ends when every reported amount has a clear project mapping, an identified calculation source, and an honest distinction between estimated and billed spend.

Keep reading

Back for another lap?Log in