Every way in, on one page

Every way into Autonomous Relay Agents: the OpenAI SDK, Vercel AI SDK, LangChain, n8n, Cursor, Cline, Continue, the relay launcher, MCP, and the OpenAPI and ARD documents.

Autonomous Relay Agents speaks OpenAI’s Chat Completions format at one base URL, so the clients, editors and frameworks you already use connect with a key and an address. The guides below are each checked against the gateway; the machine-readable documents are the ones agents and registries read.

Two lines move an OpenAI client here

export OPENAI_BASE_URL="https://autonomousrelay.com/v1"
export OPENAI_API_KEY="$AUTONOMOUSRELAY_API_KEY"

OpenAI’s official Python and Node SDKs read both variables when the client is created without arguments. There is no separate SDK to install: they are the supported client libraries.

Client libraries and frameworks

• OpenAI SDK: Python and Node, unchanged: point the base URL at /v1, use an inference key, and name any model in the catalogue by its author/slug id.
• Vercel AI SDK: The AI SDK’s OpenAI-compatible provider, created once with our base URL; streaming, tools and structured output work as they do against OpenAI.
• LangChain: ChatOpenAI in Python or JavaScript, with the base URL and key set on the client; the rest of the chain is untouched.
• n8n: One OpenAI credential with our base URL, then the chat model node picks any model in the catalogue.

Coding agents, editors and MCP

• relay launcher: One command starts Claude Code on your own provider keys, signed in through the browser, with every request tagged in Activity. Not on npm yet.
• Cursor: Any model in the catalogue from Cursor’s chat and agent, on your own provider keys, by overriding the OpenAI base URL.
• Cline: An OpenAI-compatible provider in Cline’s settings: the base URL, a key and a model id.
• Continue: A model block in config.yaml with the base URL and key; one block per model you want in the list.
• MCP servers as tools: Register your organisation’s MCP servers once, then offer their tools to any model in a request with {"type": "autonomousrelay:mcp", "server": "<name>"}.
• MCP server card: Public discovery metadata for the gateway’s own MCP server, at /v1/mcp/server-card as the MCP server-card extension (SEP-2127) specifies.

What the gateway does for every request

• Routing: Provider preferences reorder, constraints reject, and autonomousrelay/auto picks a model that fits the request by price tier.
• Failover: A models list of fallbacks, tried in order when the first is down or rate-limited, so one endpoint stays up when a provider does not.
• Bring your own key: Requests run on your own provider keys at the provider’s list price, with a 0% fee; the key is stored encrypted.
• Guardrails: PII redaction, model and provider allowlists and region constraints, set per organisation and applied before any provider sees the request.
• Spend limits: A ceiling per key, per agent or per workspace, announced as it crosses 50%, 80% and 100%, with a ledger that reconciles every request to the cent.
• Observability export: A metadata record of every request broadcast to a webhook, OTLP, S3, Langfuse or Datadog; prompts and answers are never included.
• Batch API: POST /v1/batches submits chat requests to the provider’s own batch endpoint at half the synchronous price, with results read back when the batch ends.
• Response cache: An exact-match cache of non-streaming completions, turned on per inference key; a hit is answered with no provider call and no charge, and says so in x-cache.
• Structured outputs: response_format with json_object or json_schema passes through to the model, and the response-healing plugin repairs a reply that should have been JSON.
• SSO and SCIM: Sign-in through your identity provider with OIDC or SAML 2, and seats provisioned from your directory, on the Business plan and above.
• Self-hosted deployment: Run the gateway inside your own network or cloud account, with no telemetry back to us.
• Workload identity federation: An automated job exchanges its platform’s OIDC token for a short-lived key, so nothing long-lived is stored in CI.

Machine-readable, and what changed

• OpenAPI: The public API as a document, at /openapi.json and /openapi.yaml, generated from the same definitions the gateway validates against.
• ARD manifest: The Agentic Resource Discovery manifest at /.well-known/ard.json lists the API, the MCP server card and the documentation for agents and registries.
• llms.txt: A plain-text index of the site for language models, with every documentation section and its one-line description.
• Status: Uptime and incidents, per provider, with incidents available by email.
• Changelog: Dated changes to the API and the dashboard, with an RSS feed.