​

Production outcomes, cost and retries

A failed client command does not prove that inference failed or that no charge occurred. Keep completion, billability and the next permitted action separate. Use the complete JavaScript or Python examples as the conservative starting point: each command sends at most one compute request, omits optional paid priority and never automatically replays a failed or uncertain response. Use only permitted inputs and authorized compute. Configure credentials in your backend; do not put keys, images, embeddings or signed image URLs in logs, chat or command arguments. Prepare code while an owner completes the existing account/key step. Missing credentials mean preparation is blocked, not that an integration has completed.

​

Interpret the outcome before retrying

The table assumes a trusted response from the named layer and the corresponding endpoint contract. A status number, HTML proxy page or Retry-After header alone cannot establish when work stopped. An ordinary example exit code of 1 includes no-face, pending and unknown outcomes. Its retryable: false means the example will not replay compute; it is not a statement that the request was unbilled. The public gateway preserves legacy no-face HTTP 422 even when the private model reports a no-face success. See error details for the exact codes and boundaries.

​

Preserve the original attempt

Before dispatch, persist your own job/attempt state in private application storage. If your client owns request-ID generation, persist its normalized UUID before the call. The provided examples generate an ID inside the compute helper and return it with a completed result or error; they do not implement a durable job store. Capture that ID when available. If the process loses the ID, keep the job unresolved; a missing ID does not prove no inference ran. Retain the operation, time, symbolic outcome and explicit retry delay, without sensitive payloads in operational logs. For an unknown outcome:

1. Mark the original job unresolved and stop automatic compute retries, including retries hidden in HTTP middleware, SDK wrappers, worker redelivery or an agent.
2. Keep the original request ID. Do not resubmit under a new ID, another key or another adapter as a way to get a result.
3. Have an authorized operator reconcile the request record, result if available, account usage and billing receipt. Send only the minimum permitted diagnostic context through the owner’s normal support process.
4. Resume only after the outcome is understood and another action is authorized. If a known completed result was retained securely, reuse it rather than rerunning inference to repair a local export or database write.

Request IDs support tracing and replay-conflict detection; they are not a universal idempotency key, stored-result lookup or exactly-once guarantee. Do not rely on replay protection being active for every account/deployed revision. Reusing an ID may return a conflict rather than a result. A separately authorized new attempt after a confirmed precompute rejection needs its own application attempt record and must follow the endpoint’s ID contract; preserve the earlier ID in its history. This never authorizes changing an unresolved ID. If your application persists embeddings or enrollments, keep its storage state separate from compute completion. A lost database acknowledgement can follow successful inference. Use a durable pending/reservation state so worker retries do not silently issue the same paid computation again. The customer-owned search pattern has additional storage and isolation requirements; no hosted result-retrieval endpoint is implied here.

​

Bound a deliberate retry policy

For a confirmed precompute rejection, an application may implement a policy with an explicit attempt ceiling, total deadline and owner-approved cost limit. Honor Retry-After, use bounded backoff with jitter, and stop on an unknown outcome or a terminal configuration/authorization error. A retry is a new HTTP attempt that can pass through rate limiting/admission again. Do not assume it is free or exempt from the account’s limits. Only the exact documented model admission rejections are retried by the gateway within its upstream deadline. Those internal admission retries retain one normalized request UUID and settle one final request outcome. A second client POST is different. Generic 502/504 responses and lost connections are not proof that model admission rejected the work. Avoid a blanket “retry all 5xx” policy. MCP and gateway time budgets are different: the MCP compute wait is 120 seconds; the gateway’s documented upstream budget is 240 seconds. An earlier caller abort does not prove the gateway cancelled work. Increasing a local timeout does not make an already-unknown attempt safe to replay. See limits and admission behavior.

​

Keep billing separate from transport success

Under the public contract, completed processing includes a non-match and no-face. Other final gateway non-2xx failures are uncharged. A timeout or malformed response observed at another layer does not establish that final gateway outcome. Retain an unresolved charge state until it is reconciled; do not label it zero-cost merely because your client exited with an error. A billable completion does not necessarily debit a paid balance: free allowance, active discounts and the account’s agreed contract affect settlement. Use actual account usage/receipts for the amount. This guide does not activate a tariff or promise a fixed price. See current pricing and governance. Default requests should omit X-Request-Priority and MCP priority. Omitted, null and zero mean normal own-account order, with no per-request priority surcharge. Any explicitly positive priority can double completed-call pricing, even when the queue is idle. A value such as 0.79 is positive too. Under the default policy, enterprise lane treatment can also select 2× pricing; both privileges together apply 2× once, not 4×. Agreed contracts can differ. Omission does not override the account’s enterprise/contract policy. Do not enable priority to recover from a capacity rejection without intentional owner authority for its billing effect. Priority does not preempt active work, bypass limits, reserve capacity or guarantee latency. Experimental async compare rejects positive priority. Review priority and receipt semantics before changing it.

​

What the local examples establish

The maintained failure fixture executes all six JS/Python commands against a loopback server across invalid credentials, explicit admission failures, no-face, conflicting IDs, ambiguous transport/parse outcomes, pending responses and redirects. It checks one compute POST per failing command, no paid priority, preserved IDs and no sensitive output. Missing credentials cause no network request. Separate checks exercise the gateway’s source billing/no-face/priority rules and both MCP adapters’ unknown-outcome handling. These are synthetic transport and source-contract checks. They do not run face models, inspect a customer’s ledger, certify deployed billing, or prove a real client cancelled in-flight inference. A deployment and permitted configured-key acceptance test remain separate evidence.