Credits and cost

• Fresh fetches cost credits. Each platform page shows the starting price per op, live from the API. The price covers what was asked for; a listing that returns fewer rows than it could have is settled at what actually arrived.
• Anything already held is free.A subject measured recently — within the op's freshness window — is served from what is held, for you and for everyone, at no charge. provenance.source says which happened.
• History never bills. Every platform's history op reads the stored series of a subject already held.
• Failures are not charged. A subject the source could not answer is refunded before the response is sent and named in coverage.

Send the same call with estimateOnly: true. The response carries data.creditsNeeded and a per-item breakdown, spends nothing, and runs the very plan the real call would — so the number is exact, not indicative.

{
  "request": { "op": "profiles", "subjects": ["example"] },
  "estimateOnly": true
}

maxCredits caps one call. When the cap cannot cover everything asked, the least valuable items are left out and each is named in coverage.omitted as budget_exhausted. You are never charged past the cap and never left guessing what was skipped.

Every response also carries cost.creditsRemaining, so a loop can stop itself without a balance call. When the balance cannot cover a call at all, the answer is 402 with error.code = "insufficient_credits" — see Errors.

• estimate_only=true quotes the exact cost without spending
• anything already held serves free — the second viewer never pays
• one op per call; batch subjects inside the op
• ops are independent — send several as parallel tool calls
• a posts answer includes the author's profile; don't buy it twice
• max_credits caps a call; the least valuable items are omitted, named

Credits are bought and topped up in the dashboard under Billing. Spend per API key is listed under API keys, so what each integration costs is a line item, not a reconciliation.