Which API key spent the money? Sume's by-key usage view

Sume records which API key started a paid call. Format, Action and Agent Completion runs persist the developer key id and public prefix, separate from caller input, and the Usage dashboard sums captured wallet charges by key for the month to date. Spend with no recorded origin stays visible as a residual caption instead of being guessed onto a key.

What gets the key stamped

From docs/operations/api-key-spend-attribution.md (#6623): the authenticated API account sends its key id and prefix over the internal hop. Format, Action and Agent Completion runs store that origin. Bulk queues keep the origin of the queue creator, even when another process dispatches later items. The agent's LLM reserve and per-turn MCP credential carry the same key, and usage writes stamp the key id even though MCP authentication keeps authSource = mcp_oauth.

How the numbers are built

API Keys monthly spend and the by-key table in Usage sum captured wallet charges with the same half-up per-row cents as the usage event serializer, in the same month-to-date window. Model price, discount and Agent Fee calculations do not change. Synthetic ids stay unattributed, and if an id is present the system never uses the prefix to guess it again.

Programmatic reads

For one run, thread or job, ask the usage API for the exact figure instead of adding rows yourself:

curl "https://api.sume.com/v1/usage?run_id=arun_...&limit=50" \
  -H "Authorization: Bearer $SUME_API_KEY"

Reading the residual

When unattributed spend exists, the residual caption stays visible. Historical MCP jobs and runs contain no exact origin key id, so their spend remains in the residual; Sume did not try to backfill them from key names, actor labels or prefixes. New usage can make the by-key counts grow.

Practical use

• Give each integration or automation its own key so the table answers who spent what
• Check the residual before you blame a key
• Use summary.debited_usd from /v1/usage when you quote a cost for one run

Set up for clean attribution

Create separate keys for separate automations before you start the month, because attribution is stamped at call time and not reconstructed later. Name each key after its job. Then compare the by-key table with /v1/usage for a sample run to confirm the numbers match what your automation expects.

If a key is shared by many callers, the table still works, but it answers only which key, not which caller.