TokenLab Request Console: Depura llamadas a la API de IA desde un solo panel

Una llamada fallida a la API de IA rara vez se anuncia con claridad. Obtienes un código de estado, quizás una cadena de error y un canal de soporte donde alguien pregunta "¿cuál fue el ID de la solicitud?". Si no lo tienes a mano, la investigación se detiene antes de empezar.

La Consola de solicitudes de TokenLab existe para cerrar esa brecha. Coloca los detalles a nivel de solicitud (modelo, clave, estado de caché, estado de facturación, tiempos y una vista previa del payload redactado) en una sola vista de panel, para que puedas pasar de "esta llamada falló" a "esta es la razón" sin tener que unir registros de tres lugares diferentes.

Este artículo explica qué muestra la consola, qué comprobar primero cuando algo falla y cómo encaja junto con las exportaciones de uso para los equipos que también necesitan informes a nivel de costos.

Puntos clave

• La Consola de solicitudes es una superficie de depuración a nivel de solicitud dentro del panel de la API de TokenLab, no un informe de facturación.
• Cada solicitud tiene un ID que puedes buscar directamente, y puedes crear un enlace directo a una solicitud específica con requestId en la URL.
• La consola muestra el enrutamiento, el estado de facturación, el estado de la caché, el contexto del modelo/clave y vistas previas del payload redactado para solicitudes recientes.
• El acceso está limitado a tu organización y se rige por los permisos de membresía del panel: los compañeros de equipo ven lo que su rol permite.
• Para la depuración de incidentes individuales, utiliza la consola. Para la revisión de costos por lotes en rangos de tiempo, utiliza las exportaciones de uso.

Qué es la Consola de solicitudes

Puedes acceder a ella en https://tokenlab.sh/en/dashboard/api?tab=requestConsole, dentro de la sección de API del panel de TokenLab. Está construida bajo una premisa: cuando una solicitud falla, la solución más rápida proviene de tener todo su contexto frente a ti, no de adivinar basándose únicamente en un mensaje de error.

La descripción del panel define la consola como un inspector para solicitudes recientes, que cubre el enrutamiento, la facturación, el cuerpo de la solicitud/respuesta y el contexto del proveedor del modelo. En la práctica, esto se divide en algunas secciones de trabajo.

Vista de lista. Una tabla filtrable de solicitudes recientes. Aquí es donde empiezas cuando aún no tienes un ID de solicitud específico; estás buscando la llamada fallida o inusual.

Panel del inspector. Una vez que seleccionas una solicitud, el inspector se abre con todos los detalles: qué modelo la atendió, qué clave de API se utilizó, si alcanzó la caché y cuál fue el estado final.

Contexto del error. Si la solicitud falló, la consola muestra la información del error vinculada a esa llamada específica, por lo que no tienes que cruzar referencias con un registro de errores separado.

Estado de ruta y facturación. Muestra cómo se enrutó la solicitud y si fue facturada, está pendiente, fue reembolsada o falló; los cuatro estados que más importan cuando un cliente pregunta "¿se me cobró por ese error?".

Vista previa del payload. Los cuerpos de solicitud y respuesta se muestran como vistas previas redactadas cuando están disponibles, lo que te da la forma y la estructura sin exponer secretos sin procesar en el cuerpo.

Contexto del proveedor y clave del modelo. Qué proveedor y qué modelo específico manejó la llamada; útil cuando ejecutas múltiples modelos detrás de una integración y necesitas confirmar que se invocó el correcto.

Nada de esto requiere que construyas tu propia canalización de registros sobre la API. Ya se muestra por organización, filtrado por los permisos de membresía del panel, por lo que los compañeros de equipo con el acceso adecuado ven los mismos datos de solicitud que tú.

Qué inspeccionar primero

Cuando una llamada a la API falla, existe un orden natural para comprobar las cosas. Saltar directamente a "¿el modelo está caído?" antes de confirmar que la solicitud llegó al endpoint correcto es una pérdida de tiempo.

El triaje de cinco campos

Comprobación	Qué te indica
ID de solicitud	Confirma que estás mirando la llamada exacta en cuestión, no una similar
Estado	Facturado, pendiente, reembolsado o fallido: te dice si es una pregunta de costos o técnica
Modelo	Qué modelo atendió realmente la solicitud (útil si enrutas a través de múltiples modelos)
Estado de la caché	Si un acierto o fallo en la caché de prompts cambió el costo o la latencia
Fuente de la clave	Qué clave de API se utilizó, útil cuando varias claves o entornos comparten una integración

Empieza con el ID de solicitud. Si lo tienes desde un registro del lado del cliente, un ticket de soporte o un informe de error, utiliza el patrón de enlace directo:

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

Eso abre el inspector directamente en la solicitud en cuestión, omitiendo la vista de lista por completo. Es el camino más rápido cuando alguien te entrega un ID y te pregunta "¿qué pasó aquí?".

Si aún no tienes un ID de solicitud, los filtros de la consola te permiten limitar por modelo, rango de tiempo, estado de la caché de prompts, fuente de la clave y estado. Un patrón común: filtrar por estado "fallido" en la última hora, luego escanear la lista en busca de la llamada específica por la que pregunta un usuario.

Leer el campo de estado correctamente

Los cuatro estados (facturado, pendiente, reembolsado, fallido) responden a diferentes preguntas:

• Facturado significa que la llamada se completó y consumió créditos. Si un usuario informa de un error pero la solicitud aparece como facturada, vale la pena marcarlo por separado, ya que sugiere que el fallo ocurrió en el lado del cliente después de una respuesta exitosa.
• Pendiente significa que la solicitud aún está en curso o esperando liquidación. No trates esto como un fallo prematuramente.
• Reembolsado significa que TokenLab revirtió el cargo, generalmente vinculado a un fallo en el lado del proveedor o del enrutamiento.
• Fallido significa que la llamada no se completó con éxito y no se facturó.

Saber cuál de estos aplica antes de escalar ahorra una ronda de idas y vueltas con el soporte.

Confirmar el modelo y el estado de la caché

Si estás ejecutando solicitudes contra modelos como Claude Sonnet 5, DeepSeek V4 Pro o Gemini 3.5 Flash a través de una integración compartida, vale la pena confirmar que la consola muestra el modelo que esperabas. Un cliente mal configurado, una variable de entorno obsoleta o una anulación de enrutamiento pueden enviar tráfico al modelo incorrecto sin un error obvio del lado del cliente.

El estado de la caché importa por dos razones: costo y latencia. Un fallo de caché donde esperabas un acierto generalmente significa que el prefijo del prompt cambió, incluso sutilmente: una marca de tiempo, un campo reordenado, un carácter de espacio en blanco adicional. El filtro de estado de caché de la consola te permite comparar solicitudes de acierto y fallo una al lado de la otra.

Cómo funciona con las exportaciones de uso

La Consola de solicitudes y las exportaciones de uso resuelven problemas diferentes, y vale la pena ser explícito sobre el límite para que no utilices la herramienta incorrecta.

La consola está diseñada para la investigación de una sola solicitud: una llamada, un error, una pregunta de facturación, respondida en el panel del inspector. Es lo que abres cuando una solicitud específica falla y necesitas saber por qué, ahora mismo.

Las exportaciones de uso están diseñadas para la revisión agregada: gasto en un rango de tiempo, desgloses por modelo o clave, y el tipo de informes que entregarías a un interesado financiero o usarías para una conciliación mensual. Si intentas responder "¿cuánto gastamos en DeepSeek V4 Pro la semana pasada?", esa es una pregunta de exportación, no de consola. Consulta la guía de exportaciones de uso del panel de TokenLab para ese flujo de trabajo.

En resumen: consola para incidentes, exportaciones para totales. Algunos equipos usan ambos en secuencia: una exportación revela una anomalía en el gasto agregado, y la consola es donde profundizas en las solicitudes específicas que la causaron.

Una rutina de depuración práctica

La depuración ad hoc se convierte en conjeturas bajo presión. Una rutina repetible evita que los incidentes duren más de lo necesario.

Lista de verificación: cuando una solicitud falla

1. Obtén el ID de solicitud. Desde tus registros de cliente, respuesta de error o un informe de usuario. Si no registras los IDs de solicitud por tu parte hoy, empieza ahora: es la clave de búsqueda más rápida que tienes.
2. Abre la consola con el enlace directo. Usa el parámetro de consulta requestId para saltar directamente al inspector.
3. Comprueba primero el campo de estado. Facturado, pendiente, reembolsado o fallido: esto enmarca el resto de la investigación.
4. Confirma el modelo que realmente atendió la solicitud. Compáralo con lo que esperabas enviar.
5. Comprueba el estado de la caché. Un fallo de caché donde esperabas un acierto puede explicar una latencia o costo inesperado.
6. Comprueba la fuente de la clave. Confirma que se estaban utilizando la clave de API y el entorno correctos, especialmente en configuraciones de staging vs. producción.
7. Lee el contexto del error y la información de la ruta. Aquí es donde suele hacerse visible la causa raíz real.
8. Revisa la vista previa del payload redactado. Confirma que la forma de la solicitud coincide con lo que envió tu cliente: los parámetros mal formados a menudo aparecen aquí antes de aparecer en cualquier otro lugar.
9. Cruza referencias con la referencia de la API si es necesario. La referencia de la API de chat completions de TokenLab documenta las formas de solicitud y respuesta esperadas, útil para confirmar si un payload estaba mal formado en el lado del cliente.
10. Si es un patrón, no algo puntual, cambia a las exportaciones de uso. Una sola solicitud fallida es un problema de consola. Diez solicitudes fallidas en una hora es un patrón que vale la pena exportar y revisar en conjunto.

Seguir este orden (ID, estado, modelo, caché, clave, error, payload) evita que pases por alto el campo que realmente explica el fallo.

Próximos pasos

Si actualmente estás depurando fallos de la API de IA buscando en tus propios registros del lado del cliente y cruzando referencias con un panel de facturación separado, la Consola de solicitudes elimina un paso de ese bucle. Empieza buscando una solicitud fallida reciente y abriéndola directamente.

• Abre la consola y localiza una solicitud por ID: https://tokenlab.sh/en/dashboard/api?tab=requestConsole
• Crea una clave de API de TokenLab en tokenlab.sh/en/dashboard/api para empezar a realizar solicitudes desde tu propia consola o scripts.
• Comprueba la forma de solicitud/respuesta de chat completions si sospechas de un payload mal formado: https://docs.tokenlab.sh/api-reference/chat/create-completion
• Para la revisión de gasto agregado, utiliza las exportaciones de uso en lugar de la consola: https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports
• Si estás comparando modelos por costo o capacidad antes de cambiar, el directorio de modelos tiene detalles actuales de precios y ventanas de contexto: https://tokenlab.sh/en/models

Preguntas frecuentes

¿Qué es la Consola de solicitudes de TokenLab? Es una vista de depuración a nivel de solicitud dentro del panel de la API de TokenLab. Muestra el enrutamiento, el estado de facturación, el estado de la caché, el contexto del modelo y la clave, y vistas previas del payload redactado para solicitudes recientes, limitadas a tu organización.

¿Puedo inspeccionar una solicitud por ID de solicitud? Sí. Utiliza el formato de enlace directo /dashboard/api?tab=requestConsole&requestId=<request_id> para abrir el inspector directamente en una solicitud específica, o busca por ID de solicitud desde la vista de lista.

¿La consola reemplaza a las exportaciones de uso? No. La consola es para investigar solicitudes individuales: un fallo, una pregunta de facturación. Las exportaciones de uso son para la revisión de gasto agregado en un rango de tiempo. Utiliza ambos juntos cuando una exportación revele un patrón en el que necesites profundizar.

¿Qué debo comprobar primero cuando falla una solicitud de la API de IA? Empieza con el ID de solicitud para confirmar que estás mirando la llamada correcta, luego comprueba el campo de estado (facturado, pendiente, reembolsado, fallido), el modelo que realmente la atendió y el estado de la caché. A partir de ahí, el contexto del error y la vista previa del payload suelen hacer visible la causa raíz.

Fuentes y frescura

• Consola de solicitudes de TokenLab — https://tokenlab.sh/en/dashboard/api?tab=requestConsole — observado el 2026-07-09
• Referencia de la API de Chat Completions de TokenLab — https://docs.tokenlab.sh/api-reference/chat/create-completion — observado el 2026-07-09
• Exportaciones de uso del panel de TokenLab — https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports — observado el 2026-07-09
• Directorio público de modelos de TokenLab — https://tokenlab.sh/en/models — observado el 2026-07-09

Los ejemplos de modelos referenciados (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) reflejan el SSOT actual del modelo al 2026-07-07. Para obtener los precios y la disponibilidad actuales exactos, verifica contra el enlace del directorio de modelos anterior antes de tomar decisiones de enrutamiento.