Access and release status
Public access is not open. A provider, named model version, processing boundary, data terms, billing arrangement and exact deployment must pass offer qualification and production acceptance before activation. A catalog entry or this documentation does not establish availability.
Use your own model-provider accounts, with usage billed directly by the provider, or buy access through AAES. AAES company billing includes prepaid funding and approved invoice accounts. Invoice-funded inference is not available in the current release. All live inference requires separate activation.
Download the Infer OpenAPI 3.1 contract. It includes the inference routes and separately authorized company-billing and operator routes. Operate and Govern credentials and contracts are separate.
Before deployment, review provider-account acceptance, release authorization and, for hosted tools, independent execution enforcement.
Hosting and provider-account ownership
Infer supports customer hosting and AAES hosting. Each deployment also selects customer-owned provider accounts or model access bought through AAES. Hosting does not remove provider, jurisdiction or privacy qualification requirements.
For customer-owned accounts, use model_access: customer and billing_mode: customer_account. The provider bills the customer directly. Company administrators manage a usage budget through /infer/v1/provider-budget and project spending limits through the existing company login. This budget represents permitted provider usage, not paid AAES funds.
A customer-hosted installation buying AAES access uses the relay deployment manifest. It holds project-scoped AAES access credentials and forwards calls to a fixed AAES endpoint in the approved jurisdiction. Funding, approved credit and project limits remain authoritative at AAES. Local payment assertions and billing mutations cannot authorize AAES spending.
The relay exposes text completions, an authenticated model list and /infer/v1/deployment metadata. It does not expose the company billing or operator APIs. Model lists remain empty while inference is disabled. The direct gateway exposes the broader contract where configured.
Project credentials and jurisdiction
Use the HTTPS endpoint and project-scoped bearer key provided for your accepted offer. A project key cannot administer company billing. Billing service credentials stay on the server; company administrators use the existing AAES sign-in and its current role and CSRF checks.
GET /v1/models lists currently qualified offers in that cell, or an empty list while dispatch is disabled. GET /infer/v1/catalog describes the jurisdiction and model catalog with qualification status. A catalog entry is not a promise of a live model.
Every completion requires exactly one X-AAES-Jurisdiction header matching the selected cell: AU, HK, JP, SG, CH, AE, GB, US or EU. The gateway refuses a different jurisdiction without forwarding the request elsewhere. An EU boundary can include several member states.
Production acceptance
Provider-account acceptance
Local PostgreSQL, browser and SDK tests use synthetic suppliers. An actual AWS account is needed when inspecting a Bedrock offer's account, model profile, destinations, retention and logging settings. That inspection uses a restricted read-only identity, separate from the model-invocation identity. An AAES-supplied offer uses the accepted AAES account; a customer-owned offer uses the customer's authorized account. Account access alone does not establish model eligibility or accepted privacy terms.
Release authorization
Dispatch stays disabled during setup. A future enabled deployment requires a short, independently signed authorization bound to its exact configuration and activation generation, alongside current provider qualification and company/project spending authority. Publishing an authorization does not change the dispatch switch. Expiry blocks new requests; an observed revocation durably fences the generation and requires reconciled recovery.
Independent execution enforcement
Provider-hosted code execution, image generation and read-only MCP require an accepted authority that can enforce actual spending, execution limits, resource termination and deletion, approved network paths and complete billing. Infer's bridge exchanges request-bound permits and signed completion evidence with that authority. A signature identifies the signer and protects integrity; supplier enforcement and the completeness of its observations require separate acceptance. Missing final proof retains the financial hold and prevents terminal success.
Text chat requests
POST /v1/chat/completions accepts the fields below. This is a restricted OpenAI-shaped interface; it does not implement the full OpenAI API. Unknown fields are refused.
| Field | Accepted values |
|---|---|
model | A named model ID from your qualified offer. |
messages | 1–32 messages with system, user or assistant roles and nonempty string content. Each content value is limited to 16,384 UTF-8 bytes; the complete request is limited to 32 KiB. |
max_completion_tokens | Required integer from 1 to 4,096. The maximum charge is reserved before provider dispatch. |
stream | Omitted or false for JSON; true requests SSE when the signed offer includes streaming. |
The example uses the plain text chat contract. Native POST /v1/messages and POST /v1/responses accept supported client tools and their results, with optional streaming. Native requests have a 16 MiB body ceiling, a separate 256 KiB text budget and a 65,536 output-token cap; an omitted output cap defaults to 4,096. Each feature must be listed in the signed offer. Qualified native routes can accept bounded inline images, audio, PDFs and video frames, plus exact hosted search definitions with signed billing meters. Provider-hosted code execution, image generation and read-only MCP tools have conditional profiles: they require independent spending and egress enforcement, complete disjoint billing, a funded permit and a signed completion receipt. A fixture or configuration flag does not establish provider acceptance. Remote assets, provider file references, background work and stored conversations are refused. Tools with unaccounted session, storage or generation charges cannot qualify.
Every request also needs an Idempotency-Key of 8–128 characters using letters, digits, underscores, periods or hyphens. The example assumes an accepted SG offer and uses a placeholder model ID; it is not an available public endpoint.
curl --request POST "$AAES_INFER_ENDPOINT/v1/chat/completions" \
--header "Authorization: Bearer $AAES_INFER_PROJECT_KEY" \
--header "X-AAES-Jurisdiction: SG" \
--header "Idempotency-Key: example-request-0001" \
--header "Content-Type: application/json" \
--data '{"model":"MODEL_FROM_YOUR_OFFER","messages":[{"role":"user","content":"Summarize this synthetic example."}],"max_completion_tokens":256,"stream":false}'Errors, settlement and retries
An admitted completion carries X-AAES-Request-Id for settlement metadata. Stream success termination is sent only after settlement commits. If the caller disconnects, Infer continues reading under a bounded deadline so complete measured usage can settle. Interrupted or missing usage retains the reservation for reconciliation. Prompt and output bodies are not retained for replay. Reusing an idempotency key returns 409; it does not replay a response.
400: invalid or unsupported request; no dispatch.401or403: invalid credentials, unavailable jurisdiction or restricted company account.429: a funding, project-spend or concurrency limit prevents dispatch.502: a provider outcome needs reconciliation; the financial hold is retained.503: dispatch is disabled, qualification is missing or accounting is unavailable.
After a timeout or uncertain result, check the request with the operator before creating a new request key. A lost response does not prove the provider performed no work. Use the same key for an attempted repeat; never rotate it automatically to bypass a conflict.
Operate and Govern compatibility
Infer has native Messages and Responses routes for Claude and Codex clients. Bedrock Messages and Azure Responses preserve their native request shapes. Other providers use the supported subset of the reviewed chat translators; unsupported fields are refused before spending is reserved.
For native clients, use the explicit /agent ingress: Claude appends /v1/messages, while Codex uses a base ending in /agent/v1 and wire_api = "responses". The cell supplies a missing jurisdiction and request identity. Disable request and stream retries unless they preserve a stable request identity. Streaming uses SSE. Signed WebSocket offers also accept GET /agent/v1/responses with connection-local continuation, bounded parallel lanes and per-turn settlement. Warmup creates no supplier request; disconnect removes local history and never replays a billable operation. Direct and governed connections still require acceptance of the exact model, provider and deployment.
Read the Infer privacy requirements, provider disclosures and security scope, or discuss your model and jurisdiction requirements.