TokenLab Request Console: Debug AI API Calls from One Dashboard

A failed AI API call rarely announces itself clearly. You get a status code, maybe an error string, and a support channel where someone asks "what was the request ID?" If you don't have it handy, the investigation stalls before it starts.

The TokenLab Request Console exists to close that gap. It puts request-level detail — model, key, cache state, billing state, timing, and a redacted payload preview — into one dashboard view, so you can go from "this call failed" to "here's why" without stitching together logs from three different places.

This article walks through what the console shows, what to check first when something breaks, and how it fits alongside usage exports for teams that also need cost-level reporting.

Key Takeaways

What the Request Console Is

You reach it at https://tokenlab.sh/en/dashboard/api?tab=requestConsole, inside the API section of the TokenLab dashboard. It's built around one premise: when a request fails, the fastest fix comes from having its full context in front of you, not from guessing based on an error message alone.

The dashboard copy describes the console as an inspector for recent requests, covering routing, billing, request/response body, and model vendor context. In practice, that breaks down into a few working sections.

List view. A filterable table of recent requests. This is where you start when you don't yet have a specific request ID — you're scanning for the failed or unusual call.

Inspector panel. Once you select a request, the inspector opens with the full detail: which model served it, which API key was used, whether it hit cache, and what the final status was.

Error context. If the request failed, the console surfaces the error information tied to that specific call, so you're not cross-referencing a separate error log.

Route and billing state. Shows how the request was routed and whether it was billed, pending, refunded, or failed — the four states that matter most when a customer asks "was I charged for that error?"

Payload preview. Request and response bodies are shown as redacted previews when available, giving you shape and structure without exposing raw secrets in the body.

Model vendor and model key context. Which provider and which specific model handled the call — useful when you're running multiple models behind one integration and need to confirm the right one was invoked.

None of this requires you to build your own logging pipeline on top of the API. It's already surfaced per organization, filtered by dashboard membership permissions, so teammates with appropriate access see the same request data you do.

What to Inspect First

When an API call fails, there's a natural order to check things in. Jumping straight to "is the model down" before confirming the request even reached the right endpoint wastes time.

The five-field triage

Check	What it tells you
Request ID	Confirms you're looking at the exact call in question, not a similar one
Status	Billed, pending, refunded, or failed — tells you if this is a cost question or a technical one
Model	Which model actually served the request (useful if you route across multiple models)
Cache state	Whether a prompt cache hit or miss changed cost or latency
Key source	Which API key was used, useful when multiple keys or environments share an integration

Start with the request ID. If you have it from a client-side log, a support ticket, or an error report, use the deep-link pattern:

https://tokenlab.sh/en/dashboard/api?tab=requestConsole&requestId=<request_id>

That opens the inspector directly on the request in question, skipping the list view entirely. It's the fastest path when someone hands you an ID and asks "what happened here."

If you don't have a request ID yet, the console's filters let you narrow by model, time range, prompt cache state, key source, and status. A common pattern: filter by "failed" status within the last hour, then scan the list for the specific call a user is asking about.

Reading the status field correctly

The four states — billed, pending, refunded, failed — answer different questions:

• Billed means the call completed and consumed credits. If a user reports an error but the request shows billed, that's worth flagging separately, since it suggests the failure happened on the client side after a successful response.
• Pending means the request is still in flight or awaiting settlement. Don't treat this as a failure prematurely.
• Refunded means TokenLab reversed the charge, typically tied to a failure on the provider or routing side.
• Failed means the call did not complete successfully and wasn't billed.

Knowing which of these applies before you escalate saves a round of back-and-forth with support.

Confirming the model and cache state

If you're running requests against models like Claude Sonnet 5, DeepSeek V4 Pro, or Gemini 3.5 Flash through a shared integration, it's worth confirming the console shows the model you expected. A misconfigured client, a stale environment variable, or a routing override can send traffic to the wrong model without an obvious client-side error.

Cache state matters for two reasons: cost and latency. A cache miss where you expected a hit usually means the prompt prefix changed, even subtly — a timestamp, a reordered field, an extra whitespace character. The console's cache-state filter lets you compare hit and miss requests side by side.

How It Works with Usage Exports

The Request Console and usage exports solve different problems, and it's worth being explicit about the boundary so you don't reach for the wrong tool.

The console is built for single-request investigation: one call, one error, one billing question, answered in the inspector panel. It's what you open when a specific request fails and you need to know why, right now.

Usage exports are built for aggregate review: spend across a time range, breakdowns by model or key, and the kind of reporting you'd hand to a finance stakeholder or use for a monthly reconciliation. If you're trying to answer "how much did we spend on DeepSeek V4 Pro last week," that's an export question, not a console question. See the TokenLab dashboard usage exports guide for that workflow.

In short: console for incidents, exports for totals. Some teams use both in sequence — an export surfaces an anomaly in aggregate spend, and the console is where you drill into the specific requests that caused it.

A Practical Debugging Routine

Ad hoc debugging turns into guesswork under pressure. A repeatable routine keeps incidents from becoming longer than they need to be.

Checklist: when a request fails

1. Get the request ID. From your client logs, error response, or a user report. If you don't log request IDs on your end today, start now — it's the fastest lookup key you have.
2. Open the console with the deep link. Use the requestId query parameter to jump straight to the inspector.
3. Check the status field first. Billed, pending, refunded, or failed — this frames the rest of the investigation.
4. Confirm the model that actually served the request. Compare it against what you expected to send.
5. Check cache state. A cache miss where you expected a hit can explain unexpected latency or cost.
6. Check the key source. Confirm the right API key and environment were in use, especially in staging-vs-production setups.
7. Read the error context and route information. This is usually where the actual root cause becomes visible.
8. Review the redacted payload preview. Confirm the request shape matches what your client sent — malformed parameters often show up here before they show up anywhere else.
9. Cross-reference with the API reference if needed. The TokenLab chat completions API reference documents expected request and response shapes, useful for confirming whether a payload was malformed on the client side.
10. If it's a pattern, not a one-off, switch to usage exports. A single failed request is a console problem. Ten failed requests over an hour is a pattern worth exporting and reviewing in aggregate.

Following this order — ID, status, model, cache, key, error, payload — keeps you from skipping past the field that actually explains the failure.

Next Steps

If you're currently debugging AI API failures by grepping through your own client-side logs and cross-referencing a separate billing dashboard, the Request Console removes a step from that loop. Start by finding a recent failed request and opening it directly.

• Open the console and locate a request by ID: https://tokenlab.sh/en/dashboard/api?tab=requestConsole
• Create a TokenLab API key at tokenlab.sh/en/dashboard/api to start making requests from your own console or scripts.
• Check the chat completions request/response shape if you suspect a malformed payload: https://docs.tokenlab.sh/api-reference/chat/create-completion
• For aggregate spend review, use usage exports rather than the console: https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports
• If you're comparing models for cost or capability before switching, the model directory has current pricing and context window details: https://tokenlab.sh/en/models

FAQ

What is the TokenLab Request Console? It's a request-level debugging view inside the TokenLab API dashboard. It shows routing, billing state, cache state, model and key context, and redacted payload previews for recent requests, scoped to your organization.

Can I inspect a request by request ID? Yes. Use the deep-link format /dashboard/api?tab=requestConsole&requestId=<request_id> to open the inspector directly on a specific request, or search by request ID from the list view.

Does the console replace usage exports? No. The console is for investigating individual requests — one failure, one billing question. Usage exports are for aggregate spend review across a time range. Use both together when an export reveals a pattern you need to drill into.

What should I check first when an AI API request fails? Start with the request ID to confirm you're looking at the right call, then check the status field (billed, pending, refunded, failed), the model that actually served it, and the cache state. From there, the error context and payload preview usually make the root cause visible.

Sources and Freshness

• TokenLab Request Console — https://tokenlab.sh/en/dashboard/api?tab=requestConsole — observed 2026-07-09
• TokenLab Chat Completions API reference — https://docs.tokenlab.sh/api-reference/chat/create-completion — observed 2026-07-09
• TokenLab Dashboard Usage Exports — https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports — observed 2026-07-09
• TokenLab public model directory — https://tokenlab.sh/en/models — observed 2026-07-09

Model examples referenced (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) reflect the current model SSOT as of 2026-07-07. For exact current pricing and availability, verify against the model directory link above before making routing decisions.