The log answers the question “who, what and for how much”. For every program and every person you can see which models they call, how much it costs and how long it takes. The log does not replace talking to people, but it removes the guesswork: instead of “it seems someone is spending a lot” you open the list and see exactly who.
What is recorded
- Time — when the request completed.
- Model — the public name the program specified.
- Key — whose access key was used.
- Channel — what the request went through, or the “direct” mark.
- Token volume — sent, received and reused.
- Duration — how many milliseconds the answer took.
- The two costs — “ours” and the one the vendor reported.
- The streaming flag — whether the reply arrived whole or in parts.
- The error text, when a request failed.
Every request also has its own card with the full set of fields — including error details that the list does not show.
What the log does not contain
The important and pleasant part: request and response texts are never stored. The product keeps them in memory exactly as long as it takes to count the tokens and extract the error, and writes nothing to the database. This means your conversations with the models do not pile up on the server, and the log cannot be “read” — it shows only that a call happened and how much it cost.
A separate word about license refusals. While the license is not in order, requests to the models are refused before ever reaching the vendor — they land in neither the request log nor the spending, simply because they went nowhere. A license refusal on a proxy service port, though, is visible in the “Proxy traffic” log as its own row with the reason.
How to search
- Filters — by model, key and channel; the values are offered from the rows already recorded.
- “Errors Only” — useful when something stopped working and you want to see for whom exactly.
- Date range — from yesterday to any arbitrary period.
- Sorting — by time, duration, token volume or model name; fresh rows go on top.
- Paged view — 50 rows per page, convenient for leafing through long periods.
- Auto-refresh — the list refreshes itself every 5 seconds while the tab is open and visible.
At the top sit summary tiles: how many requests in total, how many with errors, the average duration and the total volume. Some of the tiles follow the filters, some show all-time numbers — the captions tell you which.
The proxy service has its own log
Ordinary traffic — browsers, utility programs, bots — that goes through the proxy for ordinary traffic is written to its own log. It opens next to the model requests, on the “Proxy traffic” tab. The fields are different here: protocol, destination address, channel, how many bytes went out and came in, duration and error.
At the top you see the state of every channel that has a listen port: whether it listens, how many connections are active and whether the consumer is required to present an access key. If no channel is exposed, the tab says so plainly and hints at setting a listen port in the channel’s settings.
There is no money in this log at all: such traffic is counted in volume, but not in cost, and it does not touch the spending limits. So “heavy” ordinary traffic can never exhaust an AI key’s limits.
From here comes a separate summary too: how many connections there were today, how many bytes passed and which channels carried the most traffic.
Volume and retention
The log grows in your PostgreSQL database and never deletes itself. That is good for history and bad for disk space: with a heavy stream of requests the database keeps growing. The practical advice — back the database up and glance at its size from time to time; more on that in the Hosting & Data section.
Next: how to turn the log into numbers and charts — in the Analytics section.