Una consola para programación y aplicaciones de IA: qué ha cambiado y cómo trabajar con ella

La consola de TokenLab dejó de sentirse como un simple panel de control para nosotros cuando el modo de asistente de programación y el modo de aplicación de IA se fusionaron en una sola superficie de trabajo. En nuestro flujo de trabajo, la solicitud, la respuesta y el estado de la cuenta ahora se encuentran juntos. Esto elimina un cambio de contexto en cada sesión y cambia la forma en que leemos una respuesta lenta.

Puntos clave

• El modo de asistente de programación y el modo de aplicación de IA ahora conviven en la consola de TokenLab; los dos puntos de entrada anteriores se han fusionado en ella.
• Los enlaces existentes siguen funcionando y las conversaciones previas siguen ahí. No hay nada que migrar manualmente.
• Las respuestas se transmiten (stream) a medida que el modelo las genera, en lugar de aparecer solo al final. La interfaz muestra el tiempo del primer token.
• La latencia del primer token es una señal de solicitud registrada (ttft_ms en el registro de solicitudes), no solo una decoración de la interfaz.
• Cuando el saldo es bajo a mitad de una conversación, la opción de recarga aparece junto a la conversación en lugar de en una página de facturación separada.
• La elección de modelos de la consola sigue el catálogo público; consulte el directorio de modelos para ver las opciones actuales. Los ejemplos del catálogo actual incluyen Claude Sonnet 5 y DeepSeek V4 Pro.

Qué cambió en la consola de TokenLab y qué no

El cambio se lanzó en dos entradas del registro de cambios. La convergencia de la consola (2026-08-04) trasladó los dos puntos de entrada antiguos a una sola consola. La transmisión de chat en la consola (2026-08-18) añadió la transmisión al chat. Los dos cambios llegaron con un mes de diferencia, por lo que los equipos que se perdieron la primera entrada obtienen la segunda de forma gratuita.

Este es un cambio de superficie, no de comportamiento. Las llamadas a modelos, las claves y la facturación no han cambiado. Los enlaces antiguos siguen funcionando y las conversaciones existentes se conservaron durante la fusión. No hay ningún paso de migración manual.

El paso de convergencia trata sobre los puntos de entrada, no sobre el acceso a los modelos. El paso de transmisión trata sobre cómo aparece una respuesta, no sobre qué tokens se facturan. Eso es importante porque un cambio en la superficie del producto puede ocultar un cambio de comportamiento, y este no lo hizo. El modo de asistente de programación y el modo de aplicación de IA ahora comparten un mismo lugar, por lo que la primera decisión en una sesión ya no es qué punto de entrada abrir.

Si su equipo tiene manuales operativos (runbooks) que apuntan a los puntos de entrada antiguos, actualice las etiquetas cuando pueda. Los enlaces antiguos siguen funcionando, por lo que el manual no se romperá. La consola es el lugar para marcar como favorito para el trabajo nuevo. Cuando elija un modelo en cualquiera de los modos, la elección sigue el catálogo público, así que consulte el directorio de modelos. Los ejemplos del catálogo actual incluyen Claude Sonnet 5 y DeepSeek V4 Pro.

La transmisión en la consola de TokenLab cambia la forma de leer una sesión

La transmisión cambia el momento en que sabes que algo está sucediendo. En nuestro flujo de trabajo, el cliente de puerta de enlace de la consola crea solicitudes de chat con transmisión y la respuesta se renderiza de forma incremental. La interfaz muestra el tiempo del primer token, por lo que puedes ver cuándo el modelo comienza a responder. La consola también registra esa señal como ttft_ms, una columna opcional en el registro de solicitudes.

El tiempo del primer token te indica cuándo llegó el primer token, mientras que la latencia total te indica cuándo terminó toda la respuesta. Son preguntas diferentes, así que cuando una respuesta se sienta lenta, revisa primero ttft_ms. Si el primer token llega tarde, la espera es antes de la generación. Si el primer token llega pronto y la respuesta se arrastra, la espera está en el resto de la transmisión.

Cuando observamos una sesión lenta, comparamos ttft_ms con el resto de la evidencia de la solicitud en lugar de adivinar a partir del indicador de carga. La evidencia a nivel de solicitud está limitada a la organización y cubre el enrutamiento, el estado de facturación, el estado de la caché y el contexto del modelo y la clave detrás de una solicitud. La consola expone el mismo registro de solicitud que de otro modo tendrías que buscar en los registros.

Un ejemplo práctico de cómo leer la señal del primer token:

# El registro de solicitudes de la consola expone `ttft_ms` como una columna opcional.
# 1. Filtra el registro de solicitudes para la solicitud que estás comprobando.
# 2. Lee `ttft_ms`.
# 3. Compara `ttft_ms` con la latencia total de la solicitud en la misma fila.

Para conocer la forma exacta de la solicitud de transmisión, utiliza la documentación actual de la API de TokenLab. Un ejemplo de solicitud copiado con campos inventados sería menos útil que la página de documentación que posee esos nombres.

La transmisión no cambia lo que se te factura, porque se producen los mismos tokens, pero son visibles a medida que llegan. Debido a que las respuestas ahora se transmiten, una sesión interrumpida aún muestra la respuesta parcial en lugar de nada. Eso cambia la forma en que diagnosticas un fallo a mitad de sesión. Para trabajos de larga duración que una transmisión de chat no cubre, consulta la guía de tareas de generación de imágenes asíncronas.

Cómo verificar una sesión lenta sin adivinar

Comienza con el registro de solicitudes, no con el indicador de carga, porque la columna ttft_ms te indica cuándo llegó el primer token. Si ese número es alto, el modelo aún no había comenzado a responder. Si ese número es bajo, el modelo comenzó temprano y el resto de la transmisión tomó el tiempo. Esa división evita que culpes a la parte incorrecta del proceso.

El registro de la solicitud está limitado a tu organización. Incluye la ruta que atendió la solicitud, el estado de facturación, el estado de la caché y el contexto del modelo y la clave. Esos campos están juntos, por lo que puedes leer la sesión como un solo evento en lugar de unir páginas separadas. El mismo registro de solicitud está disponible en el panel de control, lo que ayuda al comparar la vista de la consola con los datos a nivel de cuenta. La guía de la consola de solicitudes explica dónde vive esa evidencia.

Por ejemplo, si el primer token llega pronto y la respuesta se arrastra, ttft_ms no es la señal principal, porque el resto de la transmisión sí lo es. Puedes ver la ruta y el estado de la caché en el mismo registro de solicitud. Puedes comprobar si la solicitud alcanzó una caché o fue al modelo. Puedes ver qué clave y qué contexto de modelo estaban adjuntos.

Nada de eso te cuenta toda la historia por sí solo, pero juntos te dan un lugar donde buscar. Cuando observamos una sesión lenta, el registro de solicitudes tiene los detalles que necesitamos. Comparamos ttft_ms con la otra evidencia a nivel de solicitud antes de sacar una conclusión.

El mismo flujo de trabajo ayuda cuando una solicitud falla o se pausa debido al saldo. El registro de la solicitud incluye el estado de facturación, por lo que el fallo no es un misterio. La entrada de recarga está junto a la conversación, por lo que la solución permanece en la misma ventana. No necesitas abandonar la sesión para encontrar el siguiente paso, por lo que puedes recargar y luego continuar.

Si el saldo está bien, puedes pasar al enrutamiento, al estado de la caché o a la elección del modelo. El punto es leer la evidencia a nivel de solicitud en orden. Primero pregunta cuándo llegó el primer token, luego pregunta qué ruta lo atendió y luego pregunta qué más dice el registro sobre la facturación, la caché, el modelo y el contexto de la clave. Ese orden es simple y coincide con la forma en que la consola presenta los datos.

Limitaciones

La transmisión muestra el progreso, no el rendimiento (throughput), porque una transmisión puede comenzar rápidamente y aun así tardar mucho en terminar. Un primer token rápido no demuestra que toda la solicitud sea rápida. El tiempo del primer token también depende del modelo y de la ruta. Compara dentro de un mismo modelo en lugar de entre diferentes modelos.

Un cambio en ttft_ms puede reflejar el enrutamiento, el estado de la caché o la elección del modelo, no solo el prompt. Trata ttft_ms como una señal en el registro de solicitudes. Combínala con la otra evidencia a nivel de solicitud antes de sacar una conclusión. Esta es una superficie para leer una sesión, no un benchmark para clasificar modelos.

La consola no convierte una transmisión de chat en un ejecutor de trabajos. Si tienes una tarea de imagen de larga duración, utiliza la guía de tareas de generación de imágenes asíncronas en lugar de mantener abierta una transmisión de chat. La superficie de transmisión es para respuestas que llegan token a token. La guía asíncrona es para trabajos que se ejecutan fuera de una respuesta de chat.

Recuerda también que la evidencia a nivel de solicitud está limitada a la organización, lo que vincula una solicitud con el contexto de la cuenta que la rodea. También significa que no debes tratar una solicitud como un benchmark global. El registro cubre el enrutamiento, el estado de facturación, el estado de la caché y el contexto del modelo y la clave para esa solicitud. Es un lugar sólido para comenzar un diagnóstico. No es una clasificación de proveedores o modelos. Cuando comparamos sesiones, comparamos dentro del mismo modelo y la misma familia de rutas, lo que mantiene la comparación honesta.

Preguntas frecuentes

¿Mis enlaces antiguos de la consola siguen funcionando?

Sí. Los enlaces antiguos siguen funcionando y las conversaciones existentes se conservaron durante la fusión. No hay nada que migrar manualmente. Si marcaste una página de la consola como favorita, sigue funcionando.

¿Qué mide realmente el tiempo del primer token?

Mide cuándo llega el primer token en una respuesta de transmisión, y la consola lo muestra en la interfaz y lo registra como ttft_ms, una columna opcional en el registro de solicitudes. No mide la latencia total ni el rendimiento (throughput).

¿Dónde recargo cuando una conversación se queda sin saldo?

Utiliza la entrada de recarga junto a la conversación, que aparece cuando el saldo es bajo a mitad de la conversación, para que puedas gestionar el saldo sin abandonar la sesión. La página de facturación en el panel de control sigue siendo el lugar para el trabajo general de la cuenta.

¿Puedo comparar el tiempo del primer token entre diferentes modelos?

No, no como una comparación limpia. El tiempo del primer token depende del modelo y de la ruta, así que compara dentro de un mismo modelo en lugar de entre diferentes modelos. Utiliza ttft_ms como una señal a nivel de solicitud, no como una clasificación de modelos.

Crea una clave API y ejecuta una sesión en la nueva consola en el panel de control.