Standalone gateway

Two deployment modes

The hosted account service enables account signup, prepaid credit billing, and customer BYOK. Its current billing middleware permits supported text inference and embeddings but rejects tools, media inputs, stored response continuation, background work, and unmetered routes.

The standalone gateway can serve provider-supported tools through its compatibility APIs. It uses operator-managed provider connections and managed gateway keys. It does not provide the prepaid credit guarantees of a prepaid account. Full client compatibility still depends on the provider, model, translation path, and client version.

Prepare a separate deployment

This is an operator task. Use a separate environment, configuration, storage, port, and provider credentials. Do not disable billing on the live prepaid service to connect a coding agent. Customer account keys are not standalone managed keys.

1. Install or build the ZRouter executable in the separate environment.
2. Configure BILLING_ENABLED=false there. The marketing/account flow is not enabled in that mode.
3. Protect operator access using AIGATEWAY_MASTER_KEY or the configured admin login. Do not expose an unprotected gateway.
4. Enable the required provider using the documented environment or YAML configuration. Use a provider API credential with access to the intended models and sufficient provider quota.
5. Configure storage and the managed API key service. From the operator dashboard, create a dedicated key for each client with appropriate model/endpoint access, budget, and rate limits when enabled.
6. Expose HTTPS for remote use. Cursor requires a public endpoint reachable by its backend. Local CLI clients may use loopback HTTP during development.

The environment variable names are available in .env.template; provider configuration is documented in config/config.example.yaml. A standalone instance should not share the paid service's account database or provider secrets accidentally.

Check models and capabilities

export ZROUTER_URL="https://YOUR_STANDALONE_GATEWAY_HOST"
export ZROUTER_API_KEY="YOUR_MANAGED_GATEWAY_KEY"
curl "$ZROUTER_URL/v1/models" \
  -H "Authorization: Bearer $ZROUTER_API_KEY"

Give users the gateway URL, a dedicated managed key, and exact enabled model IDs. Configure aliases if a client sends fixed helper-model names. Never distribute the operator master key as an integration credential.

Connect and validate a client

• Claude Code uses the gateway root and Anthropic Messages.
• Codex uses /v1 and Responses over HTTP/SSE.
• Cursor, Cline, and OpenCode use their documented custom-provider settings.

Run a short text request, then a small tool-using task. Check authentication, model routing, streaming, tool input/output normalization, and provider errors. These guides do not claim every client feature has been verified against every provider.

Billing and key ownership

Upstream model usage is billed to the configured provider account. Managed-key budgets and usage reports are operational controls, not Stripe-funded customer balances. ChatGPT, Claude, or editor subscriptions do not automatically transfer their allowances to a gateway API connection.

Customer BYOK's encrypted account storage and X-ZRouter-BYOK selection belong to the prepaid account flow. Standalone integrations use provider connections configured by the operator instead. See shared troubleshooting when a client fails.