Usage & Logs
Log fields explained, task logs, usage analytics and how to investigate unexpected costs.
The platform records full detail for every call. Once you understand this page you can answer "where did this money go" yourself.
Menu location: General → Usage Logs / Task Logs.
Usage logs
Each row is one API call. The core fields:
| Field | Description |
|---|---|
| Time | When the request happened |
| Token | Which API key was used — the most useful field for attributing spend |
| Model | The model actually called |
| Group | The supplier route the request took |
| Usage | Input and output tokens, plus cache read/write; per-call models show a count |
| Cost | The amount actually charged |
| Duration | Total request time; streaming requests also record first-token latency |
| Retry | Whether retries occurred and how many |
| Request ID | Unique identifier. Always provide this when reporting an issue — support can locate the exact request with it |
| Type | See log types below |
Click any row to expand full detail, including a prompt preview, the complete error message, and previews of generated images, audio or video.
Log types
Filter by type at the top:
| Type | Meaning |
|---|---|
| Consume | Normal API charges — what you look at day to day |
| Top-up | Credits added (payments, redemption codes) |
| Refund | Held amounts returned after a failed call |
| Error | Failed requests, with the reason |
| Manage | Administrator actions on the account, such as manual adjustments |
| System | System events |
Seeing Refund entries is normal, not a problem: an estimate is held when a request starts, and the difference is returned when the call fails or uses less than estimated.
Filtering
Filter by time range (24 hours / 7 / 14 days / custom), key, model and type.
The fastest diagnostic path is: narrow the time range, filter type to Error, then expand the specific row for the full message.
Task logs
Asynchronous work such as image and video generation does not appear in the synchronous logs — check Task Logs instead:
| Field | Description |
|---|---|
| Task ID | Unique task identifier |
| Submit time | When the task was created |
| Progress / status | Queued, running, succeeded, failed |
| Submit result | The upstream response at submission |
| Failure reason | The specific error when a task fails |
Asynchronous tasks settle when they complete; failed tasks refund the held amount.
Usage analytics
Besides per-call logs there are several aggregate views:
- Overview (General → Overview): balance, recent spend, daily call and cost trends, model mix.
- Dashboard (General → Dashboard): finer breakdown by model and over time.
- Cumulative spend per key: shown directly in the API Keys list.
Investigating cost
Costs higher than expected
Work through these in order:
- Filter logs by key — establish which key, and therefore which workload, is spending. A spike concentrated on one key often means misuse or a leak.
- Check the model — is it a higher-priced model? Prices are in the model catalog.
- Check input tokens — long context, whole documents in prompts, and accumulated conversation history push input volume far above expectations. This is the most common cause of overspend.
- Check retry counts — frequent retries mean an unstable upstream and amplify consumption.
- Check cache fields — cached portions are cheaper; misses are charged in full.
Failed calls
Rows of type Error record the exact reason. For insufficient quota, unavailable models, bad parameters, no available channel and similar, see Troubleshooting.
Reconciliation
For formal reconciliation, do not page through logs — use the monthly statement and daily reconciliation features on the Billing page, which export to CSV. See Billing & Reconciliation.