Skip to content

Gateway overview and request log ​

This page explains every card, column, label and saving status on the gateway's Overview and Requests tabs, and which values mean the gateway is healthy. In Studio, open OpenViking Gateway and choose the Overview or Requests tab. Both tabs stay empty until a client sends its first request through the gateway; see Connect clients.

Who sees which requests ​

Both tabs read the gateway's request log: one record per model request that went through the gateway. Users see only their own requests; account admins and root see the whole account's. The Overview figures are computed from the same records, so they cover the same requests.

The log holds metadata only, never prompts, replies or memory text; see What request logs record. Records are kept for 30 days by default; see Retention.

Overview ​

The Overview tab summarizes the latest 10,000 requests in the request log. Until the first request arrives, it also shows the Get started checklist; see Get started checklist and Quick mode.

CardWhat it showsHealthy valueIf it looks wrong
RequestsThe number of model requests (background saving events, shown as Memory sync in the log, are not counted), when the last one arrived, and their output tokensGrows as clients send requestsCheck the connection
First-call cache hit rateThe share of input tokens the provider served from its prompt cache on the first model call of each new user messageClose to what the provider reaches without the gateway. This is the most important sign of a healthy gateway.The first-call cache hit rate dropped
Within-turn cache hit rateThe same share for later calls in a turn, such as tool steps and OpenViking tool roundsUsually high—
Memory entries recalledMemory entries added to new messages, and how long an OpenViking search took on average (counting only messages that searched)Grows once the user has memories in OpenViking; 0 is expected on a brand-new accountNo memory is added
OpenVikingConnected, Degraded or Starting, the OpenViking version, and the reason when degraded. Its Saving conversations part counts conversations that are retrying or have paused saving.Connected, and no saving problems in recent requestsOpenViking is degraded, Conversations do not appear in OpenViking
Degraded requestsHow often each issue occurred, with an explanation and a suggested actionNo degraded requestsIssues on degraded requests
Recent requestsThe latest requests, with a link to the Requests tab—Requests

A clear drop in the first-call rate usually means the history the gateway sends no longer matches the previous request. While OpenViking is unreachable, requests still reach the model, just without memory, and saving is retried until OpenViking is back. When the Saving conversations part or the Degraded requests card reports a problem, Show in Requests opens the Requests tab filtered to Issues.

Long conversations missing the cache ​

A warning such as "2 long conversations keep missing the prompt cache" appears below the four number cards at the top (Requests, First-call cache hit rate, Within-turn cache hit rate and Memory entries recalled) when a conversation's last 3 model calls each sent at least 32,000 input tokens, less than 5 minutes apart, and the provider reported 0 cached tokens every time. It lists the model, upstream and streak of each conversation. When they are all Anthropic conversations whose upstream never wrote the cache either, the warning suggests checking that the client sets cache_control.

The cache cannot hit across these changes, so a streak starts over at each of them:

  • a compaction, or the model starting a new context window
  • a switch to another model or upstream
  • gateway tools appearing in or disappearing from the requests

When an upstream has not reported any cache hit lately, you see a note instead: long conversations through that upstream keep showing a 0% cache hit rate. For causes and fixes, see The first-call cache hit rate dropped.

Requests ​

The Requests tab lists the latest 1,000 records of the request log, newest first, and refreshes every 30 seconds while you are on the first page. Filters and search cover those 1,000 records.

Only requests that reached a model provider are logged. Requests the gateway rejects first are not, such as an invalid key, a model the key does not allow, no matching upstream or a body over the size limit; the client receives the error directly. See Clients get an error from the gateway.

FilterShows
AllEvery record
New messagesRequests that start a turn with a new user message
Tool stepsRequests that continue a turn, for example with tool results
IssuesDegraded requests, requests whose conversation saving is Retrying or Paused, and requests where the provider returned HTTP 400 or above (see The upstream returned an error)
Request typeOne of the request types

Search matches the model, conversation ID, request ID, key name or prefix, and upstream name. The log stores only a hash of the conversation ID, so Studio hashes a pasted conversation ID in the browser before matching. This works only when Studio is opened over HTTPS or on localhost; over plain HTTP, searching by conversation ID finds nothing.

Columns ​

ColumnShows
TimeWhen the request arrived
TypeThe request type
ModelThe model name the client sent
StatusThe HTTP status the provider returned
TokensInput tokens, the cached share and output tokens
MemoryWhat recall did in this request (see below)
SavingThe conversation's saving status; hover for the reason
IssueThe issue, for a degraded request

The Memory column uses this notation:

ShownMeaning
+3This request's search added 3 memory entries; the search time is shown next to it.
↺ 4Memory added to 4 earlier messages was replayed unchanged.
Recall failedThis request's memory search did not finish, for example because OpenViking was unreachable, rejected the key, or did not answer within the context profile's Time limit. Hover for the reason, and see No memory is added.

Request details ​

Expand a row to see:

  • the conversation ID, upstream, gateway key and duration
  • the token breakdown
  • the memory search result
  • context window use, and whether the history was compacted or the model started a new window
  • the saving status, with the next retry time
  • OpenViking tool details, including why tools were not offered

For a request with an issue, the expanded row also explains what happened and what to do.

Request types ​

Every record has one type. The type decides whether the request searches memory and whether its turn is saved.

TypeMeaningMemory
New messageA request whose last message is a new user messageSearched once, earlier memory replayed; the turn is saved
Tool stepThe same turn continuing, for example with tool resultsEarlier memory replayed; saved with its turn
HousekeepingTitle, summary, compaction, suggestion and permission-check requests; once a conversation has sent client tools, a separate request in it with neither tools nor earlier replies, such as Claude Code summarizing a fetched pageEarlier memory replayed; never saved
Sub-agentRequests from a client's sub-agentsEarlier memory replayed; never saved
Token countToken-counting requests (/gateway/v1/messages/count_tokens)Earlier memory replayed, so the count matches what is actually sent
ForwardedRequests passed through unchanged, without memory: other endpoints, Responses requests that rely on provider-side state, compressed or unreadable bodiesNone
Memory syncBackground saving events, not model requests—

Saving status ​

The Saving column shows whether the gateway is saving a conversation's finished turns to OpenViking. Normally it shows On.

StatusMeaningWhat the gateway does
OnSaving works normally.—
OffThe conversation's context profile does not save.Nothing is saved.
RetryingOpenViking rejected a save or could not be reached.Retries after 10, 20, 40 and 80 seconds.
PausedFive attempts in a row failed.Retries every 5 minutes until it succeeds. Unsaved turns are kept until they are saved or the conversation expires.
Paused with the reason gateway_key_revokedThe conversation's gateway key was revoked or deleted.Stops retrying. Saving resumes when the user next sends a request in this conversation with a valid key.

The expanded row and the Saving badge's tooltip show the reason for the latest change:

Reason shownCodeMeaning
OpenViking rejected the key. It may be wrong or revoked.openviking_http_401The user's OpenViking key is no longer valid.
OpenViking is unreachable or didn't answer in timeopenviking_unavailableOpenViking is down, unreachable or too slow.
Saving to OpenViking faileddelivery_failedA save failed for another reason; the gateway retries as above.
Saving works againdelivery_recoveredA save succeeded after failures.
The conversation history changed, so saving continues in a new OpenViking sessionhistory_changedNormal: the client edited, regenerated or compacted the conversation, and the gateway continues saving the current history in a new OpenViking session.
The history changed while saving, so saving continues in a new OpenViking sessionhistory_changed_during_deliveryNormal: the same, while a save was in progress.
A saved turn continued after a pause, so saving continues in a new OpenViking sessioncontinued_after_idleNormal: a turn already saved after Save the latest reply after continued.
Resynced by an administratormanual_resetSomeone used Resync conversation… (see below).

Earlier turns stay in the older OpenViking session. If saving stays at Retrying or Paused, see Conversations do not appear in OpenViking.

Resync a conversation ​

Resync starts a new OpenViking session for a conversation, and the gateway writes the full history to it with the user's next message. Use it when a conversation stays paused after you fixed the cause, or when you want a clean copy of a conversation. What was already saved stays in the old session, so OpenViking may extract some memories twice.

  1. On the Requests tab, expand a record of the conversation. Resync needs the key shown on the record; if that key has been revoked, pick a newer record of the same conversation.
  2. Choose Resync conversation…, then Resync. You should see "The conversation will be saved again with its next message."
  3. Wait for the user's next message in that conversation. Nothing happens until it arrives; then the gateway saves the full history to the new session, and the conversation's records show the reason "Resynced by an administrator".

Next steps ​

Open source under the AGPL-3.0 License. Font licenses