AI Gateway logs now show session affinity

A provider's prompt cache lives on the provider account that served a request, so when the next turn of a conversation goes to a different provider, that cache is cold and the whole prompt is billed at full price again. Vercel's AI Gateway, which can send a request for one model to any of several providers, handles this with session affinity: it groups related requests into a session, remembers which provider served the last one, and tries that provider first on the next turn. The new Sessions view in Gateway logs, announced in the changelog, lets users check whether that worked. Each row names the client that ran the session, such as Claude Code from Anthropic, Codex from OpenAI or Cursor, alongside its cost, models, providers and how much of its input was cached across turns. Opening a session shows its cache hit rate, duration and path, a turn-by-turn list of model and timing that names the provider now serving the session and any earlier ones. The changelog states the cost logic directly: a session that stays on one provider reads more of each prompt from cache.

The session affinity docs explain what the view is measuring. Affinity is on by default for text and chat requests and does not apply to embeddings, images or realtime sessions, which have no prompt cache to keep warm. Gateway takes the session from an ID the caller sends (the sessionId provider option or an x-session-id header, among a few accepted sources), then from the x-claude-code-session-id header that Claude Code sends automatically, and otherwise from a fingerprint: a hash of the conversation's opening system message, first other message and tool set, combined with the team ID. The docs warn that two conversations with the same opening share a fingerprint, so callers running many similar conversations should send an ID. Affinity runs after routing filters and only reorders providers already allowed; if the pinned provider fails, Gateway tries the next one as usual, and setting sessionAffinity to false keeps an explicit provider order exactly as written.

The routing problem is not unique to Vercel. OpenRouter describes a similar mechanism as sticky routing, keyed on a session_id when one is sent, because with many providers behind one model a second turn can land on an endpoint with no warm cache. What this changelog adds is a Gateway view, session by session, of whether pinning held. The changelog does not report any measured cache hit rates or cost savings for Gateway traffic.