Skip to content
Olympusx AIOlympusx AIOlympusx AI documentation

The gateway

The gateway is the address applications, editors and agents call to reach a model. It speaks the OpenAI API, so any client written for OpenAI works by changing two settings: the base URL and the key. This page explains what the gateway does with a request and what that guarantees. The endpoint reference is in the API overview.

What happens to a request

Section titled “What happens to a request”

Every request passes the same checks, in this order. The first one that fails answers, and nothing after it runs.

  1. Credential. The gateway reads the Olympusx AI API key from Authorization: Bearer or x-api-key, and checks that the key exists, is active and has not expired. A sign-in token from the console is refused: the gateway takes keys only.
  2. Model. It reads the model from the request body, not from any header the client sends, so the model checked is the model that will answer. The tenant must be granted the model, and the key’s allow-list, if it has one, must include it.
  3. Budgets. The key’s, the project’s and the tenant’s daily and monthly token budgets, and the tenant’s budget for that model, must not be spent.
  4. Rate limit. If the tenant has a rate limit, the request must be within it.
  5. Guardrails. The tenant’s guardrail policy scans the prompt. In Enforce mode a finding can redact the prompt or block the request.
  6. Route. The request goes to the model server deployed for that tenant and that model, or to the cloud provider that serves an external model. The caller’s key is removed first.
  7. Answer. If the tenant’s policy scans answers, the answer is scanned on the way back. The token counts are recorded against the key, project and tenant.

The decision in steps 1 to 4 is made by the control plane. The gateway holds no state of its own, and if it cannot get a decision it refuses the request with 503: it does not let traffic through unchecked.

What it guarantees

Section titled “What it guarantees”
  • One tenant’s key cannot reach another tenant’s model. Routing uses the tenant the key belongs to, set by the platform after the check, never a value the client sent.
  • Your key does not travel. No model server and no cloud provider receives the caller’s Olympusx AI key.
  • Every answered request is metered. Streamed answers included: for a request with stream: true, Olympusx AI asks the model to end the stream with a usage chunk, and records its counts.
  • Every refusal has one shape. Whatever layer refuses, the body is the OpenAI error object with a specific code. See Errors.
  • It fails closed. A gateway that has not yet received its routes answers 404 to every model; a missing decision answers 503. A guardrails scanner that errors refuses the request unless the platform is set to fail open.

The console’s own features

Section titled “The console’s own features”

The Playground, assistant chat, knowledge queries, the Code Assistant’s Ask and agent runs are started from the console and call models from the control plane. They apply the same rules: model grant, budgets, guardrails and metering. An agent run calls models through the gateway with a key Olympusx AI issues for that run.

Developer keys and the code tools

Section titled “Developer keys and the code tools”

A developer key, minted on the Code Assistant page, is an API key for one person’s editor. The gateway treats it as any key for model calls, and applies the tenant’s guardrail policy under a code profile that does not rewrite personal data in code. Traffic from developer keys is never captured for review.

The same gateway serves the codebase tools at /mcp, to developer keys only. See Code tools.

Section titled “Related”