Getting started with Relay

Getting started with Relay

Place AnchorShell Relay between an application and supported OpenAI-compatible model paths.

Last updated July 10, 2026

The request path

AnchorShell Relay is an operational layer between an application and its configured model endpoints. Your application or agent framework still owns prompts, tools, workflows, and product behavior. Relay owns queueing, eligibility, pacing, route selection, failure handling, and request accounting.

Application or agent harness
            ↓
    AnchorShell Relay
            ↓
OpenAI-compatible endpoint

Before integrating

Choose whether you are using AnchorShell Relay — Managed through AnchorShell Platform or running AnchorShell Relay — Self-Hosted.

  • AnchorShell Relay — Managed receives authenticated organization and user context from AnchorShell Platform.
  • AnchorShell Relay — Self-Hosted is a single-node service with SQLite-backed configuration and local administration.

Both use the same queueing, pacing, lane, fallback, and accounting architecture.

Integration outline

  1. Configure an upstream provider base URL and credential.
  2. Add at least one enabled endpoint/model with the correct route kind.
  3. Create a Relay Lane or use a direct model match.
  4. Configure any resource or user policies required for the workload.
  5. Send supported requests through Relay’s /v1 interface.
  6. Review queue state, request logs, token usage, and configured cost data.

Current supported gateway surfaces include chat completions, responses, embeddings, and model listing. Upstreams must use compatible OpenAI-style request behavior; Relay does not claim every provider protocol.

Important operational boundary

The current request queue is in memory. Configuration and request logs are persisted, but queued work does not survive a Relay process restart.