Machine-readable companion: /docs-for-robots

Arc/docs

Traffic Model

Routes

Routes are the main traffic entrypoint in Arc. They let you attach policy and observability to a named request path without changing your application protocol.

Route Key

Pass X-Arc-Route with a slug such as customer-support. Arc resolves that route and applies its configured model, prompt, rollout, and traffic control settings.

http
X-Arc-Route: customer-support

Request Path

Application

Your existing OpenAI-compatible request.

Arc key + optional route headers

Arc Proxy

Auth, route policy, logging, memory, limits, and routing.

Provider request

Provider

OpenAI, Anthropic, or another configured upstream.

What A Route Can Own

Primary model

string

The default model injected when the request body omits model.

Fallback models

string[]

Secondary model options if you want redundancy at the route level.

System prompt

string

A route-level prompt injected ahead of user messages unless bypassed.

Shadow mode

boolean

Background comparison traffic that does not affect the user-facing response.

Canary state

rollout

Controlled rollout of a candidate model to a small percentage of traffic.

Rate limit

policy

Warn or reject when a route exceeds the configured request window.

Memory pool

binding

Optional connection to long-lived conversation memory.

Smart tier

routing tiers

Complexity-based model selection for the route.

Direct Traffic

If a request does not include X-Arc-Route, Arc still proxies it. The request appears as Direct in logs and does not inherit route-level policy.

Practical recommendation

Use explicit routes for production traffic. Direct is useful for initial testing, but it leaves too much policy implicit once you start using prompts, memory, limits, or smart routing.