Consola de solicitudes de TokenLab: depure llamadas a la API de IA desde un solo panel

Una llamada fallida a la API de IA rara vez se anuncia claramente. 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 estanca antes de empezar. Creamos la TokenLab Request Console para cerrar esa brecha al colocar los detalles a nivel de solicitud en una sola vista de panel. Muestra el modelo, la clave, el estado de la caché, el estado de facturación, el tiempo y una vista previa del payload redactado. En nuestro pipeline, tratamos el ID de solicitud como la primera clave de búsqueda.

Puntos clave

• La TokenLab Request Console 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. 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 únicos, usa la consola. Para la revisión de costos por lotes en rangos de tiempo, usa las exportaciones de uso.

Qué es la TokenLab Request Console

Puedes acceder a ella en /dashboard/api?tab=requestConsole, dentro de la sección de API del panel de TokenLab. El panel de la API en sí se encuentra en /dashboard/api. La consola se basa en 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 solo 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. Vemos que 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 de error vinculada a esa llamada específica. No estás haciendo referencias cruzadas 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ó. Esos cuatro estados son los más importantes 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, dándote forma y estructura sin exponer secretos sin procesar en el cuerpo.

Contexto del proveedor y clave del modelo. Qué proveedor y qué modelo específico manejaron la llamada. Esto es ú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 propio pipeline de registro sobre la API. Ya está expuesto 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, hay un orden natural para verificar las cosas. Saltar directamente a "¿está el modelo caído?" antes de confirmar que la solicitud llegó al endpoint correcto es una pérdida de tiempo.

El triaje de cinco campos

Verificación	Lo que te indica
Request ID	Confirma que estás viendo la llamada exacta en cuestión, no una similar
Estado	Facturado, pendiente, reembolsado o fallido: te indica si es una pregunta de costo 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é del prompt cambió el costo o la latencia
Fuente de la clave	Qué clave de API se utilizó, útil cuando múltiples claves o entornos comparten una integración

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

/dashboard/api?tab=requestConsole&requestId=%3Crequest_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 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é del prompt, fuente de la clave y estado. Por ejemplo, cuando una solicitud falla, filtra por estado "fallido" en la última hora, luego escanea la lista para encontrar 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 un error pero la solicitud aparece como facturada, vale la pena marcarlo por separado. 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 fue facturada.

Saber cuál de estos aplica antes de escalar ahorra una ronda de idas y vueltas con 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, confirma que la consola muestre 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. Busca una marca de tiempo, un campo reordenado o 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 la TokenLab Request Console con las exportaciones de uso

La Request Console y las exportaciones de uso resuelven problemas diferentes, por lo que ayuda ser explícito sobre el límite. 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 quieres 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 muestra 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. Verifica el campo de estado primero. 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. Verifica el estado de la caché. Un fallo de caché donde esperabas un acierto puede explicar una latencia o costo inesperado.
6. Verifica 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 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. Haz referencia cruzada con la referencia de la API si es necesario. La referencia de la API de chat completions de TokenLab en https://docs.tokenlab.sh/api-reference/chat/create-completion documenta las formas de solicitud y respuesta esperadas. Úsala para confirmar si un payload estaba mal formado en el lado del cliente.
10. Si es un patrón, no algo único, 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.

Preguntas frecuentes

¿Cómo encuentro una solicitud fallida sin un ID de solicitud?

Usa los filtros de vista de lista en la TokenLab Request Console. Limita por modelo, rango de tiempo, estado de la caché del prompt, fuente de la clave y estado. Por ejemplo, filtra por estado "fallido" en la última hora, luego escanea la llamada por la que pregunta un usuario. Una vez que la encuentres, abre el inspector y copia el ID de solicitud para registros futuros.

¿Por qué una solicitud aparecería como facturada cuando el cliente informa un error?

Facturado significa que la llamada se completó y consumió créditos. Si un usuario informa un error pero la solicitud aparece como facturada, el fallo probablemente ocurrió en el lado del cliente después de una respuesta exitosa. Marca ese caso por separado porque apunta a un camino de solución diferente al de una solicitud fallida o reembolsada.

¿Qué me dice un fallo de caché en el inspector?

Un fallo de caché significa que la solicitud no alcanzó la caché del prompt. Eso importa para el costo y la latencia. Un fallo donde esperabas un acierto generalmente significa que el prefijo del prompt cambió, incluso sutilmente. Busca una marca de tiempo, un campo reordenado o un carácter de espacio en blanco adicional.

¿Puedo compartir un enlace de solicitud con un compañero de equipo?

Sí, si sus permisos de membresía del panel lo permiten. Los datos de solicitud están limitados a tu organización. Usa el formato de enlace directo /dashboard/api?tab=requestConsole&requestId=<request_id> para abrir el inspector directamente. Los compañeros de equipo ven lo que su rol permite.

¿Cuándo debería cambiar de la consola a las exportaciones de uso?

Cambia cuando el problema sea un patrón, no algo único. 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. Usa las exportaciones para el gasto en un rango de tiempo, desgloses por modelo o clave y conciliación mensual.

Fuentes y frescura

• TokenLab Request Console — /dashboard/api?tab=requestConsole — observado 2026-07-09
• Referencia de la API de Chat Completions de TokenLab — https://docs.tokenlab.sh/api-reference/chat/create-completion — observado 2026-07-09
• Exportaciones de uso del panel de TokenLab — /blog/tokenlab-dashboard-usage-exports — observado 2026-07-09
• Directorio público de modelos de TokenLab — /models — observado 2026-07-09
• Panel de claves de API de TokenLab — /dashboard/api — observado 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 19-09-2026. La instantánea de origen para esta nota de la consola se observó el 09-07-2026; la fecha original del SSOT del modelo en la fuente fue el 07-07-2026.

Próximos pasos

Si actualmente depuras fallos de la API de IA buscando en los registros del lado del cliente y haciendo referencias cruzadas con un panel de facturación separado, la Request Console elimina un paso de ese bucle. La consola se encuentra en /dashboard/api?tab=requestConsole. El panel de claves de API está en tokenlab.sh/dashboard/api. La forma de solicitud/respuesta de chat completions está documentada en https://docs.tokenlab.sh/api-reference/chat/create-completion. Para la revisión de gasto agregado, usa exportaciones de uso. Para obtener detalles sobre precios de modelos y ventanas de contexto, consulta el directorio de modelos. Abre la consola y localiza una solicitud fallida reciente por ID.