At thinkapenny.ai/console, for administrators. What is running, what it is costing, what every request actually did, and who is allowed in. It refreshes itself every eight seconds.
Whether the service is answering, and what each backend is doing. Ready means at least one backend is serving — not all of them, which is normal: idle rented machines are supposed to be down.
Each row is one backend, with the models it is actually serving. Those are read live from the machine, so this is reality rather than what configuration hopes for. A row showing 530 is a backend with nothing running behind it.
Any rented vast.ai machine, its state and hourly cost. Empty is the normal, cheap state — machines are started on demand and destroyed when idle.
Destroys the machine immediately. Billing stops; anything mid-generation on it fails. The next request for a model it was serving starts a fresh one, so this is a safe way to stop a machine you did not expect to see — but it is instant and there is no undo.
The last 200 requests, newest first: time, model, backend, status, duration, size and origin. It is the first place to look when someone says an answer was wrong or slow.
Click a row to see exactly what happened, in four stages:
| Stage | Shows |
|---|---|
| 1 · Client → API | What was asked, headers and body, credentials redacted. |
| 2 · API → Backend | What was actually forwarded — including any rewritten model name, and any search results supplied to the model. |
| 3 · Backend → API | What the model returned, streamed replies reassembled. |
| 4 · API → Client | What the caller received. Headers the API changed are in red. |
Stage 2 is the one that answers most questions. If a search-backed answer was wrong, the search results the model was given are right there — and usually the answer was faithful to a source that was itself incomplete.
Every stored request includes the full text of what was asked and answered. They are readable only by administrators, kept outside the web root, and the last 500 are retained. Treat the console as you would the conversations themselves.
Who may use the service, and at what level. Adding an email makes that person a member — signed in, no usage limits. Ticking admin also grants the console.
Anyone not listed who signs in is a guest: chat only, 10 messages an hour and 40 in total. You do not need to add someone before they can try the service — you add them to take the limits off.
Changes take effect on that person's next page load. They do not need to sign out.
Nothing stops you removing your own admin rights, and the console is the only place to grant them. The bootstrap administrator in the server configuration is always restored, so recovery means editing that file — not a locked door, but not a click either.
| You see | It means |
|---|---|
| ready: true, some backends 530 | Normal. Idle rented machines are down and cost nothing. |
| A GPU box you did not expect | Someone asked for a model that was not running. It reaps itself when idle; Kill stops it now. |
| Requests at 200 but slow | Check the duration column, then stage 2 — a search adds several seconds. |
| 503 “starting up” | A model was requested that was not running; a machine is booting. Expected once, not repeatedly. |
| Log rows not loading | The console is admin-only. If your row was changed you may no longer be one. |