How to attribute OpenRouter spend to the right project
Use the billed key and recorded ownership, while preserving account-level totals and unresolved usage.
The same model can serve a support bot, a code migration, and an internal search tool. A model name tells you what ran. It does not tell you which project should receive the cost.
For OpenRouter attribution, the useful starting point is the account and API key used for the request, followed by an explicit mapping from that key to the work.
Understand the imported grain
OpenRouter's Activity API reports aggregates for the last 30 completed UTC days, grouped by endpoint. It accepts an API-key hash filter. Its key-listing API supplies key identities and names. These are reporting interfaces, not a stream of individual live requests.
That distinction affects the interface. A daily aggregate should not appear as if it happened at one precise request time. A row lacking a key identifier in an account-wide response should remain unresolved until a more specific query or another record supplies that identity.
Reference: OpenRouter: activity by endpoint
Reference: OpenRouter: list API keys
Map a key to an owner
Give a project its own key when that matches the access model, and record the mapping deliberately. If a key serves one named Agent, its project can provide the attribution. If several Agents share the key within one project, a project-level mapping may be sufficient while an Agent-level split remains unknown.
An illustrative key named support-prod is useful evidence only after the owner confirms what uses it. Names can become stale. Keep the vendor's stable identifier with the mapping and review it after credential rotation or a change of project ownership.
Reconcile before adding detail
An account total and a breakdown by keys can describe the same underlying charges. Adding both counts the work twice. A sound importer reconciles the breakdown against the account total for the same period and model dimensions, retaining a clearly identified remainder where attribution is incomplete.
This is also why fetching more detail should be a controlled backfill. Replacing a coarse aggregate with attributed components must preserve the amount represented by the original record. A rounding difference should be explained rather than hidden in whichever project happens to be last in the list.
Know the current FlockTab boundary
FlockTab supports OpenRouter key-to-Agent links and resource-to-project attribution. With the key list available, its connector reads activity per key and reconciles that breakdown against account activity. Costs the listed keys do not explain remain on the account resource. Deleted keys, reporting lag, or an incomplete key read can still leave ownership unresolved.
In Outside spend, assign a known key resource to its project. Only assign the whole account resource when all usage represented by it genuinely has that owner. For a mixed account, preserve the unresolved amount and investigate the key breakdown. The important result is a project total you can defend, even when that leaves a visible remainder.
Sources checked 23 September 2026. Numerical scenarios are illustrative unless explicitly identified as provider data. Vendor limits and interfaces can change; consult the linked documentation for current details.