Traffic Controls
Memory
Memory in Arc is route-bound and client-scoped. It exists to rehydrate useful context before the provider request without making your app manually replay every prior turn.
Mental Model
A route can bind to zero or one memory pool. A memory pool can be shared by many routes in the same project. Client state then lives under that pool, keyed by X-Arc-Client-ID or the OpenAI user field.
Route binding
Routes store one memoryPoolId. Enabling memory on a route means selecting a single pool for that route.
Shared pool
Multiple routes can point at the same pool when they should share continuity, for example support and billing routes for the same user.
Client scope
Each client ID gets separate rolling turns, summary state, expiry, and token estimates inside the chosen pool.
What this means in practice
How Routes Relate To Pools
Route And Pool Relationship
Route A
Support route bound to one memory pool.
Route B
Billing or onboarding route using the same pool.
Shared Pool
One pool can be attached to many routes when they should share continuity.
Clients
user_123, user_456, and other client IDs each get separate windows and summaries.
Pool sharing is the mechanism Arc gives you for continuity across routes. If two routes attach to the same pool and the caller uses the same client ID, both routes contribute to and read from the same memory state.
route -> pool
Each route can have memory disabled or point to exactly one pool.
pool -> routes
A pool can be reused by multiple routes inside the same project when they should share context.
pool + clientId
Client memory is effectively partitioned by selected pool and client identifier.
pool deletion
Arc blocks deleting a pool while routes are still attached to it, so you cannot silently break bound routes.
Request Flow
Attach a memory pool to a route, then identify the user with X-Arc-Client-ID or the request body's user field. Arc uses that ID to fetch or create memory state for that route and client.
Memory Injection
Client ID
Passed via X-Arc-Client-ID or the OpenAI user field.
Memory Pool
Rolling turns plus a compressed summary for that client on that route.
Final Messages
System prompt, memory context, and your current messages assembled server-side.
Arc stores a rolling window of recent turns and a compressed summary. On each request, Arc assembles route system prompt, memory context, and current messages into one upstream payload.
Header precedence
X-Arc-Client-ID and the OpenAI user field are present, Arc uses the header as the canonical client identifier.Pool Settings
ttlDays
How long client memory lives before expiry. The pool detail page also shows per-client expiry dates.
maxWindowMessages
How many recent turns Arc keeps directly in the rolling window before relying more heavily on the summary.
summarizeAfterTokens
Token threshold after which Arc should compress accumulated context into summary form.
summarizeAfterTurns
Turn-count threshold for summarization, useful when sessions are long but not especially token-heavy.
summarizeAfterIdleHours
Idle threshold that lets Arc summarize older state after a quiet period instead of keeping only raw turns.
Users can create pools either from the dedicated Memory section or inline from a route when enabling memory for the first time.
What The Dashboard Lets You Do
From a route
Toggle memory on, select an existing pool, create a new pool inline, and jump to the pool management page.
From a pool
Inspect active clients, last active time, estimated tokens, expiry, and clear one client's memory without deleting the whole pool.
The pool detail page is where the state becomes concrete: you see which client IDs exist in that pool, how many turns Arc has stored, when they were last active, and when they will expire.
Operational Caveats
Memory changes prompt shape
Good fits are assistants, support flows, and continuity-heavy chat. Weak fits are one-shot extraction, deterministic transforms, and routes where you need tightly controlled input text.
Shared pools should be intentional. If two routes have different instructions or different safety posture, sharing one pool can create continuity that is technically correct but operationally confusing.