Request Logs
Request Logs records every API call, for reconciling costs, troubleshooting failed requests, and confirming which model and provider a call actually used.
Members see only their own logs; administrators see the logs of everyone in the current organization. Both entries show the same model call records; the difference is how much data you can see. Administrator permissions never bring other organizations' logs into the current organization's list.
| Entry | Scope | Main use |
|---|---|---|
| Member-side Request Logs | Your own call records | Checking personal costs, key usage, and why calls failed |
| Administrator-side Analytics → Request Logs | Call records of everyone in the current organization | Investigating member reports, reconciling organization costs, and locating the actual provider and request |
Entries appear in the list about two minutes after the call finishes. If a just-made request isn't there yet, wait a moment and refresh.
Finding Logs
The condition bar at the top shows the active filters; by default it covers only the last 7 days, and the member view is also limited to your own records.
The bottom of the list lets you change the page size and paginate. The list keeps only the last 30 days; for older calls, click History data at the bottom.
Administrator Logs
Administrator logs are the same feature as member logs, with identical list columns and details (see below); the only difference is the wider scope. After switching to the administrator role, open Analytics → Request Logs to see calls from everyone in the current organization.
- Filter by user: pick a user in the condition bar, then narrow down with time, API Key, model, or provider.
- Handle member reports: confirm the time and user first, then find the matching API Key or Request ID, and expand the entry to check the actual model, provider, latency, token usage, and billing breakdown.
- Reconcile costs: for cost disputes, check the user's quota and balance in Quotas & Redemption together with the key quota in Managing API Keys; for organization-wide trends and rankings, see Dashboard & Analytics.
Logs record only model calls and their usage. To find who changed configuration such as providers, pricing, or permissions, check the operation audit on the corresponding management page.
Reading the Log List
| Column | Meaning |
|---|---|
| Created time | When the call happened |
| Provider | The upstream provider that actually served the call |
| User | The account that made the call |
| API key | The API key used for the call |
| Group Pricing | The group pricing applied to the call |
| Model | The model used in the request |
| Timing | Total latency and time to first token; streaming requests carry a "streaming" tag |
| Input / output | Input and output token counts |
| Cost | Shows "Subscription" under quota management, meaning it was deducted from your periodic quota; under redemption-code top-up it shows the actual amount of this call |
| Details | The pricing ratio and prices applicable to this call |
Multiple entries at the same moment usually come from one application's consecutive requests; tell them apart by API key and model.
Viewing One Call's Details
Click the arrow at the start of a row to expand the full information of that call.
| Field | Meaning |
|---|---|
| Provider info | The ID and name of the provider that served the call |
| Request ID | Unique identifier of this request; providing it speeds up troubleshooting |
| Log details | A summary of the prices and pricing ratio applicable to the call |
| Cache tokens | Tokens that hit the upstream model's prompt cache |
| Cache creation tokens | Tokens written to the upstream model's prompt cache |
| Billing process | Itemized prices and the calculation steps |
| Request path | The API path the request hit |
| Stream status | How the streaming response ended |
| Request conversion | Protocol conversions the request went through in the gateway |
| Billing mode | Whether the charge comes from the upstream or is computed by the gateway from the price table |
Some fields appear only when the corresponding information exists, such as the model actually used upstream.
With Intelligent Routing enabled, the model in the logs is the model actually called after routing: calls to a virtual model such as og-auto are recorded as the rewritten model, and the virtual model name never appears. To check the model originally requested, look at the og-route-requested-model response header, or give the Request ID to an administrator to look up in the routing monitor. For overall spending and usage trends rather than individual calls, members can go to Personal Dashboard and administrators to Dashboard & Analytics.