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 endpointBefore 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
- Configure an upstream provider base URL and credential.
- Add at least one enabled endpoint/model with the correct route kind.
- Create a Relay Lane or use a direct model match.
- Configure any resource or user policies required for the workload.
- Send supported requests through Relay’s
/v1interface. - 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.