> ## Documentation Index > Fetch the complete documentation index at: https://docs.anchorage.com/llms.txt > Use this file to discover all available pages before exploring further. # Paid inference > An OpenAI-compatible completions endpoint billed through Anchorage's Agentic Banking Platform. ## Running inference through Anchorage's Agentic Banking Platform `POST /v1/chat/completions` speaks the same request shape as OpenAI's own chat completions API. Point any OpenAI-compatible SDK's `base_url` at it and it works as a drop-in swap, except streaming: send `"stream": false` or omit the field, since a `"stream": true` request is rejected today. ## Why run inference here * **Nothing to set up.** No account with the provider, no invoice, no separate billing relationship. Anchorage handles payment on the agent's behalf and sends the request straight to the provider — point `base_url` at the endpoint and go. * **Settles instantly.** No waiting on an external biller; the call completes as soon as it's paid. * **Anchorage carries the payment infrastructure.** Your organization never has to hold, manage, or expose any payment credentials of its own to use this. * **The same budget.** The budget that pays for other purchases on this platform pays for inference too, drawn from the agent's identity here rather than a separate balance held with the provider. * **The same governance controls.** The org's budget cap, the [per-agent daily cap](/agentic-banking/concepts/agents#stopping-a-runaway-agent), and instant revocation all apply to inference spend exactly as they do to any other agent payment, approved and reconciled the same way. A budget with the default allow-all merchant setting needs no extra configuration; one restricted to a specific allowlist needs the inference provider added to it (see [prerequisites](/agentic-banking/guides/call-a-model#prerequisites)). * **Drop-in for existing code.** Point an existing OpenAI-compatible integration at this endpoint and swap the API key. The request and response shapes don't change, other than the streaming exception above. ## How a call is billed The agent's API key authenticates the call (see [Agents](/agentic-banking/concepts/agents#authorization-model); no OAuth session works here). Anchorage bills the charge to the agent's primary budget, gated by the same compliance and spending checks as any other agent payment. A charge over the budget cap waits for an org admin to approve it instead of completing; retry with the same request once it's approved (see [Approvals](/agentic-banking/concepts/payments#approvals)). On success, the provider's response passes through, and a charged response carries `X-Transaction-ID`. ## Managing idempotency keys To avoid multiple charges on retries, every request carries an idempotency key. If you don't send an `Idempotency-Key` header, we generate one from your agent and the request body, so sending the exact same request twice only charges you once. Send `Idempotency-Key` yourself to control this directly. Reuse the same key on a second request and you don't pay again, even if you changed the body: the key guarantees you're not charged twice, not that you get the exact same response back. Usually you get the first request's result again; on rare occasions the original response wasn't retained, and the provider is contacted again for a fresh one. Send a new key when you actually want to send a new request with the same body. This key isn't scoped to your agent, it's scoped to your whole account. If another agent on your account reuses the same key, they collide. Use something unique, like a UUID. ## Failure modes | Status | `error.code` | What it means | What to do | | ------ | ---------------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------- | | 401 | `invalid_api_key` | No usable agent API key. | Mint or check the key on the agent's page. | | 413 | `request_too_large` | Body over 1.5 MiB. Nothing charged. | Send a smaller request. | | 400 | `invalid_idempotency_key` | `Idempotency-Key` over 255 bytes. | Send a shorter key. | | 400 | `streaming_not_enabled` | Request sent `"stream": true`. Nothing charged. | Send `"stream": false`, or omit the field. | | 403 | `budget_not_configured` | No spend limit configured. | Configure a budget, then retry. | | 402 | `budget_approval_required` | Over budget cap, waiting on an admin. | Get it approved, then retry with the same body (and key, if one was sent). | | 403 | `payment_refused` | Compliance/spending check refused, or the provider was unreachable. Nothing charged. | See [Failure modes](/agentic-banking/concepts/payments#failure-modes). | | 502 | `upstream_error` | Provider server error before payment. Nothing charged. | Retry. | | 502 | `upstream_failed_after_payment` | Payment submitted, no completion came back. | Check that transaction before retrying. | | 422 | `response_truncated_after_payment` | Completion too large to record; payment submitted. | Check that transaction, then ask for a shorter completion with a new key. | A compliance check enforced before this endpoint's own error handling can return a plain-text 403 instead. Treat it the same as `payment_refused`. ## Related topics - [Changelog](/agentic-banking/changelog.md) - [Call a model](/agentic-banking/guides/call-a-model.md) - [Crypto payments](/agentic-banking/concepts/payments.md) - [Make a crypto payment](/agentic-banking/guides/make-a-crypto-payment.md) - [Settlement process](/knowledge-base/platform/developers/trading/settlement.md)