Session affinity
Prefer a cache-eligible route across calls in one session.
Session affinity lets later requests in a session prefer a previously successful route when conditions allow. It is a routing preference, not a supplier lock or storage for your conversation history.
Why it helps
Multi-turn conversations often repeat system prompts, tool definitions, and earlier messages. Keeping repeated prefixes on a cache-capable route improves the chance of upstream cache hits, reducing repeated-input cost and latency. The same session ID does not guarantee a hit: content changes, cache expiry, or failover can prevent it.
Identifying a session
Clients can identify a session with body session_id or header x-session-id; the body takes precedence when both exist. Without an explicit session ID, prompt_cache_key or a derived conversation-prefix identity may be used. Content changes affect derived identities. Keep an explicit ID stable for a long conversation, and use different IDs for different conversations.
When it applies
Cache affinity requires a route supporting the model and protocol, preserved input, and a cache-read price below the ordinary input price. Only successfully completed calls update affinity. Later calls must still pass current health and capability checks.
Affinity reorders routes only within the same priority; it cannot bypass cooldowns or parameter requirements. Normal routing applies after 10 idle minutes since the last success, when the previous route becomes ineligible, or when the affinity record is unavailable. Applications cannot rely on permanent upstream state placement.
Chat requests must still include the required message history. Stateful Responses continuation is a separate protocol capability; a session ID does not replace previous_response_id. See Chat API and Responses API for parameters.