OpenClaw OAuth or API key: which costs belong in an API estimate?

Answer: first identify how each request authenticates

A token-priced API estimate describes usage at a selected rate. It is not necessarily what you pay for an OpenClaw agent. OpenClaw supports both API keys and provider-supported OAuth or subscription authentication. A model name alone does not tell you which account or billing arrangement handled a request. If an agent mixes routes, separate them before comparing a calculator total with an invoice or subscription statement.

Why the same model label can mislead you

OpenClaw's model authentication guide documents API keys and OAuth as distinct ways to connect a model provider. Its OAuth guide describes provider-supported subscription authentication and multiple profiles. The model-provider rules also say that adding provider authentication does not automatically switch the primary model. A provider/model label therefore cannot serve as a receipt for how every run was paid for.

Clawback's free calculator asks for model, message and heartbeat frequency, child-agent frequency, token assumptions, and channel count. Its model menu contains fixed prices per million input and output tokens. There is no auth-mode selector, provider invoice import, subscription fee field, or usage-cap ledger. Its projected dollars are a scenario using those menu prices, not an audit of the account that actually served the requests.

A reconciliation sheet for mixed agents

Take one billing period and inventory requests by the credential path that actually served them. Keep the credential itself private. Use local model/auth status and provider usage records to investigate the route; check the applicable provider terms and statement for the charge. If a fallback changes credentials, attribute the resulting request to the credential that handled it, not the one you intended to use.

Route	Record for this period	Compare with
API-key requests	Actual billable token categories and applicable rate	Provider API usage and invoice for the same account and dates
OAuth or subscription requests	Provider, account, plan fee, usage limits, and any separately billed usage	That provider's plan terms and statement, not an assumed per-token invoice
Unknown or switched route	Request and run identifiers without secrets	Provider records before allocating spend

For example, imagine an interactive agent using an API key while a scheduled child job uses a provider-supported subscription login. This is a hypothetical configuration, not a customer bill. Pricing every call at the calculator's API rates would produce a useful replacement-cost scenario, but not necessarily the paid total. Calling the child job free would also be wrong: plans can have fees, limits, or terms specific to that provider. Keep the two questions separate: what did this period cost under the actual arrangement, and what might the same measured workload cost if moved to metered API billing?

Use the calculator for the question it can answer

For a key-backed route, put its approximate message and scheduled-work frequencies into the calculator with the relevant model. Check the displayed menu rate against your provider's current rate and account terms before using the output. For a mixed route, calculate only the workload that fits its assumptions, then reconcile the other route against its own statement. The tool does not read live token usage, cache discounts, or auth profiles; do not treat a difference from the provider total as proven waste.

Keep this worksheet local. You need the route and usage totals, not an API key, OAuth token, private prompt, or full configuration pasted into a web form. The useful result is a comparison with an explicit boundary and an honest unknown bucket, not a deceptively precise savings number.