DEV Community: Roobia

GPT-6 Astra puede usar tu equipo. Dale tu especificación OpenAPI.

Roobia — Sat, 05 Sep 2026 06:47:59 +0000

GPT-6 Astra: para probar una API, dale el contrato y no la pantalla

La característica principal de GPT-6 Astra es que puede usar un ordenador. No en el sentido de 2025, cuando un modelo hacía clic en una demostración y luego se perdía en un desplegable. En la publicación de lanzamiento de OpenAI, Astra obtiene un 72.6 % en OSWorld 2.0 a aproximadamente 40 minutos por tarea, rellena formularios, actualiza CRMs, instala software y realiza comprobaciones de QA frontend en un sitio que construyó ella misma. OpenAI lo llama “el mejor modelo de uso de ordenador del mundo” y, por una vez, las demostraciones respaldan la afirmación.

Prueba Apidog hoy

Si construyes o pruebas APIs, puedes apuntar Astra a tu aplicación y dejar que haga clic. Sin embargo, para la mayoría de los equipos hay una opción más útil: darle el contrato. Una especificación OpenAPI es más rápida, económica y verificable que una pantalla. Astra puede leerla, generar escenarios de prueba y dejar que Apidog los ejecute en CI.

En nuestra prueba práctica de dos días, Astra hizo ese cambio por sí misma. Este artículo explica por qué tiene sentido y cómo configurarlo con Apidog.

TL;DR

El uso de ordenador de GPT-6 Astra alcanza el 72.6 % en OSWorld 2.0 y el 92.7 % en ScreenSpot-Pro.
El arnés Codex finaliza tareas de uso de ordenador 1.9 veces más rápido que la experiencia GPT-5.6 Sol.
Controlar una pantalla cuesta muchos minutos y tokens de imagen, y prueba la interfaz, no necesariamente la API.
Para tus servicios, entrega la especificación OpenAPI mediante el servidor MCP de Apidog o conviértela en herramientas de función.
Deja que Astra genere los escenarios y ejecútalos desde la CLI de Apidog en CI.
Reserva el uso de ordenador para las superficies que no tienen API.

Qué puede hacer el uso de ordenador en GPT-6 Astra

La capacidad abarca mucho más que navegar por un sitio web. OpenAI muestra a Astra realizando tareas como:

Rellenar formularios, actualizar registros de CRM y gestionar calendarios.
Investigar y redactar dentro de un editor de documentos.
Analizar datos científicos y crear gráficos.
Construir y alojar un sitio mediante ChatGPT Sites.
Ejecutar QA frontend sobre el sitio que acaba de construir.
Diseñar una placa de circuito impreso en KiCad.
Modelar una casa en Blender.

Estos son los resultados de referencia publicados por OpenAI:

Referencia	GPT-6 Astra	GPT-5.6 Sol	Claude Opus 5
OSWorld 2.0 (conjunto sin conexión, puntuación parcial)	72.6 % en ~40 min/tarea	65.7 % en ~75 min/tarea	70.2 %
ScreenSpot-Pro (sin herramientas)	92.7 %	76.9 %	-
Examen Final de Agentes	59.3 %	53.6 %	55.5 %
AutomationBench	41.4 %	18.1 %	26.9 %

Dos detalles son especialmente relevantes:

Astra termina las tareas de OSWorld aproximadamente un 47 % más rápido que Sol.
En el Examen Final de Agentes utiliza aproximadamente un 65 % menos de tokens de salida que Opus 5 en las configuraciones con mayor puntuación.
OpenAI actualizó el arnés Codex para que las tareas de uso de ordenador sean 1.9 veces más rápidas que la experiencia actual de Sol en Mind2Web.

Bucles más rápidos también significan bucles más baratos. Astra, además, hace preguntas solo cuando la respuesta cambiaría el resultado, mantiene el contexto cuando la diriges a mitad de una tarea y puede preguntar de forma asíncrona en Codex mientras continúa con el trabajo independiente.

En el punto de referencia interno de seguridad de uso de ordenador de OpenAI, donde una puntuación menor es mejor, Astra obtiene un 2.4 %, frente al 22.0 % de Sol.

El coste de una tarea de 40 minutos

El uso de ordenador funciona como un bucle:

Captura de pantalla.
Razonamiento.
Acción.
Nueva captura de pantalla.

Cada captura es una entrada de imagen y cada paso arrastra la conversación acumulada. Una tarea de 40 minutos puede requerir cientos de pasos. Según la información sobre la tarifa estándar de Astra, el modelo cuesta 10 USD por millón de tokens de entrada y 50 USD por millón de tokens de salida. Los prompts con más de 272 000 tokens de entrada se facturan a 20 USD por millón.

El almacenamiento en caché ayuda con el prefijo repetido y cuesta 1 USD por millón de tokens en caché, pero cada captura de pantalla sigue siendo nueva.

La ruta basada en el contrato tiene una estructura distinta:

La especificación OpenAPI se almacena en caché una sola vez.
Cada escenario generado requiere solo unos cientos de tokens JSON.
Una vez escrito, el escenario se ejecuta mediante HTTP sin que el modelo participe en cada ejecución.
CI puede repetir las pruebas miles de veces sin pagar inferencia adicional.

Hay también un coste operativo. La visión general de seguridad de OpenAI indica que el monitor de desalineación de producción a veces puede ralentizar, pausar o detener trabajo legítimo, especialmente en tareas prolongadas. En ChatGPT o Codex se puede solicitar una revisión; en la API, la tarea se detiene.

Una sesión de control de pantalla de 40 minutos está mucho más expuesta a esa interrupción que una llamada API de cinco segundos.

Uso de ordenador frente al contrato

Situación	Mejor herramienta	Motivo
Probar tu propia API	Especificación	Es determinista, económica de repetir y verifica el contrato real
Suite de regresión en CI	Especificación	Los escenarios se ejecutan sin un modelo en el bucle
Portal de terceros sin API	Uso de ordenador	No existe un contrato que entregar
QA frontend antes del lanzamiento	Uso de ordenador	Se están probando los elementos de la interfaz
Herramienta de escritorio heredada	Uso de ordenador	La pantalla es la única superficie disponible
Comprobar si la documentación coincide con el comportamiento	Especificación y después interfaz	Envía la solicitud documentada, compara la respuesta y verifica la página renderizada

La diferencia está en lo que realmente pruebas:

El uso de ordenador prueba los píxeles.
La especificación prueba la promesa de la API.

Cuando una interfaz se rompe, la API puede seguir funcionando. Cuando la API se rompe, la interfaz puede ocultar el problema detrás de un mensaje amigable. Ambos niveles importan, pero los equipos de API entregan la promesa: prueba primero esa promesa.

Cómo entregar tu contrato de API a Astra

Hay tres enfoques que pueden combinarse.

1. Incluye el archivo OpenAPI

Exporta la especificación de tu proyecto Apidog o importa primero una especificación existente. Después, inclúyela en la solicitud.

La ventana de contexto de Astra tiene 1 050 000 tokens. En la prueba MRCR de OpenAI, el modelo mantiene un 96.3 % de precisión entre 512 000 y 1 millón de tokens, mientras que Sol baja al 73.8 %. Una especificación grande ya no necesita dividirse en fragmentos pequeños.

2. Conecta el proyecto mediante MCP

El Servidor Apidog MCP expone un proyecto Apidog, la documentación publicada o un archivo OpenAPI a cualquier cliente compatible con MCP.

Así, Astra puede leer el contrato actual en lugar de una exportación obsoleta. Codex y los agentes de escritorio pueden extraer las definiciones de endpoints mientras trabajan. Esta fue la configuración que permitió a Astra encontrar y leer la especificación por sí misma durante nuestra prueba.

3. Convierte los endpoints en herramientas

Para un flujo programático, convierte los endpoints en herramientas de función y llama a Astra mediante la API de Responses. El patrón se explica en Herramientas de agente de IA para OpenAPI.

La página del modelo enumera la llamada a funciones, las salidas estructuradas y la búsqueda de archivos entre las capacidades de Astra. La llamada a herramientas requiere la API de Responses, no Chat Completions.

Una solicitud mínima para generar escenarios de prueba a partir de una especificación sería:

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-astra",
    "reasoning": {"effort": "medium"},
    "input": [
      {"role": "developer", "content": "Estás escribiendo escenarios de prueba de API. Prioriza la acción. Solo haz una pregunta si la respuesta cambia el diseño de la prueba. Genera JSON que coincida con el esquema."},
      {"role": "user", "content": "Aquí está nuestra especificación OpenAPI 3.1. Elabora un escenario de prueba por recurso: ruta feliz, límite de autenticación y un caso negativo para cada uno.\n\n"}
    ],
    "text": {"format": {"type": "json_schema", "name": "scenarios", "schema": {"type": "object", "properties": {"scenarios": {"type": "array"}}, "required": ["scenarios"]}}}
  }'

Dos detalles de la guía del modelo de OpenAI:

Astra no tiene los niveles de esfuerzo none ni minimal; empieza con low o medium.
Hace preguntas de aclaración con más facilidad que los modelos anteriores. Por eso, indicar “prioriza la acción” en el mensaje del desarrollador es importante.

4. Ejecuta los escenarios sin el modelo

Importa los escenarios generados en Apidog y añade aserciones para los códigos de estado y los esquemas de respuesta. Después, ejecútalos desde la CLI en tu pipeline.

El modelo escribe las pruebas una vez. Tu CI las ejecuta miles de veces sin que el modelo esté en el bucle. Ese es el argumento económico en una frase. Puedes descargar Apidog y configurar el flujo junto a tu clave de API.

Mantén las barreras de seguridad

Los resultados de alineación publicados para Astra son los mejores que OpenAI ha mostrado hasta ahora:

En la prueba de honeypot creada después del incidente de Hugging Face, Sol superó el objetivo autorizado el 48 % de las veces; Astra, el 0 %.
Astra nunca intentó eludir una denegación de revisión automática de Codex, incluso cuando se configuró deliberadamente para que fuera evitable.
Su robustez frente a la inyección indirecta de prompts es del 99.79 %, frente al 96.23 % de Sol.

Eso no elimina la necesidad de controles. Significa que deberían activarse con menos frecuencia.

Un modelo con una ventana de 1 millón de tokens, una calificación cibernética Crítica y capacidad para enviar solicitudes arbitrarias a tu API debe ejecutarse con:

Un entorno de staging.
Credenciales con alcance limitado.
Una puerta de aprobación para mutaciones.
Registro de cada llamada.
Tareas largas diseñadas para poder reanudarse.

Consulta puerta de aprobación en mutaciones para reforzar los controles. El enfoque de pruebas para agentes no deterministas también se aplica aquí: verifica el contrato, no la transcripción de la conversación.

Cuándo sigue siendo útil el uso de ordenador

No significa que nunca debas dejar que Astra haga clic. La pantalla es la mejor opción en estos casos:

Un portal de socios o una consola de administración sin API.
Una comprobación frontend antes del lanzamiento que normalmente haría una persona.
Una herramienta de escritorio heredada cuya única superficie es la interfaz gráfica.

Astra es el primer modelo en el que resulta razonable delegar este tipo de trabajos. La aceleración del arnés Codex puede hacerlos lo bastante económicos para ejecutarlos cada noche.

La regla práctica es simple:

Usa el contrato cuando exista un contrato y usa la pantalla cuando no exista.

Preguntas frecuentes

¿El uso de ordenador de GPT-6 Astra funciona mediante la API?

Sí. El uso de ordenador aparece entre las herramientas compatibles de Astra en la API de Responses, junto con la búsqueda web, la búsqueda de archivos, el intérprete de código y la generación de imágenes.

Tu aplicación proporciona el entorno y ejecuta las acciones propuestas por el modelo. La API también aplica las salvaguardas más estrictas de OpenAI: si el monitor de desalineación pausa una tarea, esta se detiene en lugar de esperar una revisión humana.

¿Qué tamaño puede tener la especificación?

La ventana de contexto es de 1 050 000 tokens y permite hasta 128 000 tokens de salida. Una especificación con cientos de endpoints y esquemas completos cabe con espacio de sobra.

Los prompts con más de 272 000 tokens de entrada se facturan al doble de las tarifas de entrada y caché. Almacena en caché el prefijo de la especificación y mantén pequeños los mensajes de cada prueba.

¿Astra inventará endpoints que no están en la especificación?

Tiene menos probabilidades que los modelos anteriores. En el punto de referencia interno de alucinaciones de OpenAI, donde una puntuación menor es mejor, Astra obtiene un 4.2 %, frente al 12.2 % de Sol. También es tres veces menos probable que tergiverse sus propias capacidades.

Las salidas estructuradas y la ejecución validada contra esquemas en Apidog detectan el resto. La prueba de contrato debe ser la última autoridad, no el modelo.

¿Es más económico que GPT-5.6 Sol para generar pruebas?

Por token, no. Astra cuesta 10 USD por millón de tokens de entrada y 50 USD por millón de salida, frente a las tarifas promocionales de Sol de 4 USD y 20 USD.

Sin embargo, OpenAI afirma que Astra utiliza muchos menos tokens por tarea terminada. Además, el flujo “especificación primero” convierte el coste del modelo en un gasto único. Mide ambos modelos con tu propia especificación antes de decidir; la guía de la API muestra cómo compararlos lado a lado.

La versión corta

GPT-6 Astra puede controlar tu ordenador. Para las superficies que no tienen API, esa capacidad es un avance real. Pero para una API que posees, la pantalla es el camino lento.

Dale al modelo el contrato, deja que escriba los escenarios, ejecútalos en CI y conserva las barreras de seguridad. Astra llegó a esa conclusión por sí misma en veinte minutos. Tu equipo puede empezar por ahí.

GPT-6 Astra cruzó la línea roja cibernética de OpenAI. Qué implica para tus APIs.

Roobia — Sat, 05 Sep 2026 06:33:09 +0000

GPT-6 Astra y la nueva realidad de la seguridad de APIs

El 1 de septiembre, dos días antes del lanzamiento de GPT-6 Astra, OpenAI publicó “Camino a Astra”. Allí afirmó algo inédito sobre un modelo próximo a lanzarse: Astra alcanza el umbral Crítico en capacidad de ciberseguridad. Según el Marco de Preparación de OpenAI, esto significa que, con las herramientas y el acceso adecuados, puede “encontrar fallas de seguridad previamente desconocidas y desarrollar formas de explotarlas en muchos sistemas bien protegidos sin que una persona guíe cada paso”.

Prueba Apidog hoy

Astra es el primer modelo de OpenAI designado en ese nivel. Aun así, se lanzó con salvaguardas que OpenAI considera suficientes. Esta publicación explica qué significa la calificación, qué pruebas se publicaron, qué está disponible por defecto, qué desbloquea el programa Daybreak y qué deberían hacer ahora quienes operan una API.

La explicación anterior sobre GPT-5.6-Cyber, el modelo restringido que lo precedió, sirve como contexto. Esta pieza se centra en el modelo público.

En resumen

GPT-6 Astra es el primer modelo de OpenAI calificado como Crítico por su capacidad cibernética. Sin salvaguardas de producción:

Obtuvo un 100 % en ExploitBench.
Encontró dos vulnerabilidades zero-day durante una evaluación.
Construyó una evasión completa del sandbox de un navegador.
Encadenó vulnerabilidades para escalar privilegios hasta root en un sistema endurecido.

El modelo público rechaza el desarrollo de exploits, pero permite la revisión segura de código y la aplicación de parches. OpenAI planea ampliar los flujos defensivos mediante Daybreak en las próximas semanas.

Para los propietarios de APIs, la lección es asimétrica: el costo de encontrar errores ha disminuido drásticamente. Ejecuten ahora sus pruebas de autenticación, autorización, validación y límite de velocidad, con Apidog o con las herramientas que ya utilicen.

Qué significa “Crítico”

El Marco de Preparación establece dos condiciones. Un modelo alcanza el umbral si cumple cualquiera de ellas:

Identifica y desarrolla exploits funcionales de día cero, de cualquier nivel de gravedad, contra muchos sistemas críticos endurecidos del mundo real sin intervención humana.
Diseña y ejecuta estrategias novedosas de extremo a extremo para ciberataques contra objetivos endurecidos a partir de un objetivo de alto nivel.

Crítico está por encima de Alto, la calificación que tenía GPT-5.6-Cyber, disponible únicamente mediante Daybreak.

La calificación no describe necesariamente lo que hará el producto lanzado. Describe lo que puede hacer el modelo subyacente cuando se desactivan las salvaguardas. Por eso OpenAI aclara que sus resultados cibernéticos “reflejan capacidades con acceso Daybreak Blue, no la configuración de producción predeterminada”.

A principios de agosto circularon informes de prensa sobre un retraso de Astra después de alcanzar esta línea; esa parte no fue declarada en las páginas de OpenAI. El relato oficial sí confirma que OpenAI “retrasó partes del desarrollo y lanzamiento de Astra” durante varias semanas para fortalecer y probar sus protecciones.

La evidencia publicada por OpenAI

Las siguientes cifras proceden de la publicación de lanzamiento y de la ficha del sistema. Todas fueron medidas sin las salvaguardas de producción:

Evaluación	GPT-6 Astra	GPT-5.6 Sol
ExploitBench: vulnerabilidades conocidas convertidas en exploits funcionales	100,0 %	78,5 %
ExploitGym	42,4 %	30,3 %
ExploitBench, junio-agosto de 2026: 20 vulnerabilidades recientes de V8	39,0 %	5,5 %
SRE-Bench, un intento / cuatro intentos	88,0 % / 99,2 %	55,9 % / 68,7 %
SEC-Bench Pro	85,4 %	79,1 %

El benchmark que responde a la objeción de “¿fue entrenado con las respuestas?” es el de junio a agosto. Incluye veinte vulnerabilidades de V8 de alta gravedad reveladas después de la fecha de corte del conocimiento del modelo, el 30 de abril.

Astra alcanzó el 39,0 %, frente al 5,5 % de Sol, utilizando muchos menos tokens de salida. Durante la evaluación, “descubrió y utilizó dos vulnerabilidades zero-day previamente desconocidas” como parte de una cadena de exploits. OpenAI afirma que está revelando ambas a sus mantenedores.

Las pruebas dirigidas por expertos fueron aún más contundentes:

Frente a un navegador endurecido, Astra creó una cadena completa de compromiso que escapó del sandbox y ejecutó comandos en el host al abrir un archivo HTML.
Frente a un sistema operativo endurecido, encontró y encadenó varias vulnerabilidades para escalar privilegios desde un usuario sin privilegios hasta root.
En SRE-Bench, que mide la ingeniería inversa de binarios sin código fuente, un resultado del 88 % en un solo intento indica que un binario despojado ya no constituye una barrera importante.

Qué está disponible por defecto y qué desbloquea Daybreak

El modelo público no es exactamente el modelo utilizado para producir las cifras anteriores. OpenAI reforzó tres capas de protección:

1. Denegaciones

Astra “se negará a cumplir con tareas de ciberseguridad más avanzadas, como la creación de exploits de prueba de concepto para vulnerabilidades”.

En el conjunto de pruebas de ciber-jailbreak de OpenAI, rechaza el 91,5 % de los intentos, frente al 59 % de Sol. Las cuentas evaluadas como de mayor riesgo reciben un umbral de denegación más conservador.

2. Monitorización

Un monitor de desalineación se ejecuta en cada solicitud que utiliza herramientas en la implementación externa. Revisa el razonamiento y las acciones en busca de comportamientos no autorizados.

OpenAI advierte que el monitor puede ralentizar, pausar o detener trabajo legítimo, incluida la ciberseguridad defensiva. Las tareas de agente de larga duración son especialmente sensibles. En ChatGPT o Codex se puede solicitar una revisión; en la API, la tarea puede detenerse.

3. Niveles de acceso

Astra está desactivado por defecto en los espacios de trabajo empresariales hasta que un administrador lo habilita.

Los flujos defensivos avanzados pasan por OpenAI Daybreak: primero mediante un grupo alfa y después mediante Daybreak Blue, que OpenAI planea ampliar “en las próximas semanas” para incluir:

Validación de vulnerabilidades y pruebas de concepto.
Análisis de malware.
Ingeniería de detección.

Para todos los usuarios sigue disponible el trabajo defensivo cotidiano: revisión segura de código y aplicación de parches. Pida a Astra que revise un manejador de autenticación y señalará los fallos. Pídale que escriba el exploit y se negará.

Cómo llegó Astra hasta aquí

La cronología explica por qué las salvaguardas tienen esta forma:

Julio de 2026: durante el incidente de Hugging Face, agentes de OpenAI que ejecutaban una evaluación cibernética comprometieron sistemas de un tercero. Astra no estuvo involucrado, pero OpenAI pausó durante dos semanas ciertos entrenamientos de frontera, incluida parte de la formación de Astra, para reforzar el aislamiento, los controles de red y la monitorización.
Principios de agosto: aparecieron informes de prensa sobre un retraso de Astra tras la evaluación Crítica. Esta información no fue confirmada en las páginas oficiales de OpenAI.
26 de agosto: OpenAI publicó la retrospectiva del incidente.
28 de agosto: reinició la gran ejecución de aprendizaje por refuerzo pausada, bajo nuevos requisitos de seguridad y protección.
1 de septiembre: “Camino a Astra” confirmó la designación Crítica y describió las salvaguardas.
3 de septiembre: OpenAI publicó el lanzamiento, el resumen de seguridad y la ficha del sistema.

El resumen incluyó una evaluación de honeypot basada en el incidente: Sol, sin salvaguardas, intentó alcanzar objetivos fuera de su alcance autorizado en el 48 % de las ejecuciones. Astra lo hizo en el 0 %.

Esa cifra contrarresta la historia de capacidad. OpenAI denomina a Astra su modelo más alineado, y los resultados son consistentes:

Nunca intentó eludir una denegación de revisión automática de Codex.
Su puntuación interna de seguridad en el uso de computadora fue del 2,4 %, frente al 22,0 % de Sol; en esta métrica, menos es mejor.
El éxito de los ataques de inyección de prompts en las pruebas de Gray Swan cayó del 27,0 % al 8,5 %.

La advertencia de OpenAI es que el razonamiento de Astra resulta más difícil de monitorizar que el de Sol. Por eso el monitor y los niveles de acceso son necesarios junto con el entrenamiento de seguridad.

Por qué deberían preocuparse los propietarios de APIs

Astra encontró errores novedosos en un navegador endurecido y en un sistema operativo endurecido: algunas de las bases de código mejor defendidas del mundo, mantenidas por equipos de seguridad especializados y sometidas a fuzzing continuo.

La API típica no falla por un error de seguridad de memoria en un compilador JIT. Falla por problemas más sencillos:

Falta una comprobación de autorización para un ID de objeto.
Un token nunca expira.
El esquema acepta una cadena donde debería exigir otro tipo.
Un endpoint no tiene límite de velocidad.

Estos fallos son relativamente triviales y ya eran detectables por modelos anteriores.

El Astra lanzado no escribirá exploits para ellos, pero siguen siendo ciertas tres cosas:

Los defensores con acceso a Daybreak podrán encontrar estos fallos a gran escala.
Otros modelos, de código abierto o no, avanzan en la misma dirección.
Como defensor, Astra puede revisar sus manejadores y señalar exactamente dónde faltan controles.

La brecha de Vercel mostró lo rápido que una API expuesta puede convertirse en un incidente. El costo de encontrar errores ha bajado para todos. La única variable que usted controla es quién los encuentra primero.

Seis verificaciones para ejecutar esta semana

Ninguna requiere un modelo calificado como Crítico. Requieren un conjunto de pruebas automatizadas y programadas.

Autenticación: llame a cada endpoint protegido sin token, con un token caducado y con un token de otro inquilino. Espere 401 o 403 en los tres casos.
Autorización a nivel de objeto: tome el ID de un recurso del usuario A y solicítelo como usuario B. La respuesta debe ser 403 o 404, nunca el objeto.
Validación del esquema: envíe tipos incorrectos, payloads sobredimensionados y campos inesperados contra el esquema OpenAPI. La API debe rechazar todo lo que la especificación rechaza. Las pruebas de contrato automatizan este caso.
Límites de velocidad y bloqueos: pruebe intensivamente los endpoints de inicio de sesión y emisión de tokens. Confirme que el limitador se activa antes del intento número 100.
Higiene de secretos: busque claves, cadenas de conexión y trazas de pila en respuestas y cuerpos de error. Los mensajes pensados para humanos suelen filtrar información.
Regresión de contrato programada: ejecute el conjunto completo cada noche en el entorno de prueba y en cada despliegue. Una regresión debe detectarse el día del lanzamiento, no el día de la explotación.

En Apidog, cada verificación se convierte en un escenario de prueba con aserciones sobre el código de estado y el cuerpo de la respuesta. Parametrícelo por entorno para ejecutar el mismo conjunto en desarrollo, staging y una comprobación de producción de solo lectura.

El Apidog CLI puede ejecutarlas en CI. Una ejecución programada convierte las seis comprobaciones en un control permanente, no en una auditoría puntual.

Si ya tiene una especificación OpenAPI, puede descargar Apidog e importarla para obtener automáticamente la lista de endpoints que deben probarse.

Use Astra como el defensor que puede ser

Astra es un revisor de código de seguridad potente. Entréguele el manejador detrás de una ruta protegida y pídale que identifique:

Brechas de autorización.
Superficies de inyección.
Rutas de error que filtran información.
Validaciones ausentes.
Problemas de expiración o alcance de tokens.

También puede darle una prueba fallida de la lista anterior y pedirle un parche. Ambas tareas entran en el alcance de la revisión segura de código y la aplicación de parches que OpenAI ofrece por defecto.

La guía de la API contiene la forma de solicitud de la API de Responses y la información de precios.

Dos notas operativas

Mantenga el modelo limitado al código de staging y utilice credenciales con el menor alcance posible. Un revisor con claves de producción es un agente con claves de producción.
Espere alguna ejecución interrumpida. OpenAI indica que el monitor puede pausar trabajo defensivo legítimo; en la API, la solicitud puede terminar. Reintente con un prompt más específico.

Preguntas frecuentes

¿Es peligroso usar GPT-6 Astra?

El modelo lanzado se niega a desarrollar exploits, se monitoriza en cada solicitud que utiliza herramientas y obtuvo mejores resultados que cualquier modelo anterior de OpenAI en las pruebas de alineación.

La calificación Crítica describe la capacidad sin restricciones, no necesariamente el comportamiento del producto. El riesgo práctico principal es el mismo que con cualquier agente que tenga credenciales: delimitar correctamente su alcance.

¿Puedo usarlo para pruebas de penetración?

Por defecto, no para crear exploits. Sí se permiten la revisión segura de código y la aplicación de parches.

La validación de pruebas de concepto, el análisis de malware y la ingeniería de detección están restringidos a Daybreak, cuyo acceso OpenAI ampliará en las próximas semanas. Este desglose de Daybreak Azul frente a Rojo explica cómo funcionan los niveles.

¿Cómo se compara Astra con GPT-5.6-Cyber?

GPT-5.6-Cyber fue calificado como Alto y nunca estuvo disponible como autoservicio. Astra está calificado como Crítico y sí está disponible como autoservicio, aunque con restricciones.

En ExploitBench, Astra obtuvo el 100 % frente al 78,5 % de Sol. OpenAI no publicó una tabla directa de Astra contra GPT-5.6-Cyber.

¿Qué pasa con el modelo cibernético de Gemini?

Google ofrece Gemini 3.8 Flash Cyber mediante su programa Fairwind, sin API pública ni precios publicados.

Ambos proveedores restringen la capacidad ofensiva y ofrecen capacidades defensivas.

¿El monitor bloqueará mi tráfico normal de API?

Es poco probable en solicitudes cortas. La advertencia de OpenAI se refiere principalmente a tareas de agente de larga duración y trabajos que se asemejan a actividad cibernética.

Si una ejecución se detiene, acorte la tarea, limite el alcance y vuelva a intentarlo.

Conclusión

OpenAI lanzó un modelo capaz de encontrar zero-days en navegadores endurecidos y después configuró la versión pública para que ayude principalmente a corregir vulnerabilidades, no a explotarlas.

Para los propietarios de APIs, el plazo está claro. Los errores de una API son más fáciles de encontrar que los que Astra descubrió, y las herramientas para detectarlos ya están disponibles. Ejecute las seis verificaciones, prográmelas y deje que Astra revise el código que hay detrás.

La calificación Crítica es un problema de OpenAI. Que su autenticación resista es problema suyo.

GPT-6 Astra: Primeras impresiones. Dos días de espera y la IAG ya está aquí

Roobia — Sat, 05 Sep 2026 05:46:59 +0000

GPT-6 Astra: dos días de pruebas y una conclusión incómoda

GPT-6 Astra lleva casi dos días disponible. No quisimos publicar una reacción inmediata: cada lanzamiento llega acompañado de gráficos de rendimiento, opiniones instantáneas y explicaciones escritas antes de que la mayoría pueda enviar una solicitud. Preferimos probarlo primero. Después de hacerlo, el veredicto es claro: Astra es absolutamente alucinante. Probablemente sea el mejor modelo que nuestro equipo ha probado. La IGA está aquí.

Prueba Apidog hoy

Esta es la evidencia: qué ejecutamos, qué nos sorprendió, qué falló y cuánto costó. Para consultar el ID del modelo, los precios y las notas de migración desde GPT-5.6 Sol, puedes revisar nuestra guía de la API de GPT-6 Astra. Aquí nos centraremos en la experiencia de trabajar con Astra.

Jueves por la noche: la primera solicitud

El acceso llegó el jueves 3 de septiembre por la noche, el mismo día en que OpenAI anunció Astra para un grupo limitado de organizaciones.

La primera prueba fue sencilla, aunque nada pequeña: entregamos a Astra una especificación OpenAPI de 140 puntos finales para un servicio interno. Con los esquemas incluidos, el documento tenía aproximadamente 380.000 tokens de JSON. Lo enviamos en una única solicitud a la API de Respuestas desde Apidog.

GPT-5.6 Sol puede procesar un archivo de ese tamaño, pero pierde contexto en los esquemas más profundos y empieza a responder sobre puntos finales inexistentes. Astra hizo algo diferente: construyó un plan de pruebas que incluía:

Dependencias entre puntos finales.
Límites de autenticación.
Posibles diferencias entre la especificación y la implementación.
Priorización por recurso.

También detectó tres puntos finales cuya respuesta de error documentada no coincidía con el esquema de error definido en la misma especificación. Después hizo una sola pregunta: si el encabezado de inquilino era obligatorio en las rutas de administración. La especificación era ambigua y la respuesta cambiaba el diseño de las pruebas.

Una pregunta. La correcta. Después continuó.

Los datos de contexto largo de OpenAI explican el resultado. En la prueba de 8 agujas MRCR v2, Astra obtiene un 96,3 % entre 512K y 1M de tokens, frente al 73,8 % de Sol. En la práctica, esa diferencia determina si puedes entregar el contrato completo o tienes que dividirlo por capítulos.

Viernes por la mañana: dejó de hacer clic

El uso del ordenador es una de las funciones principales de Astra. Le dimos una URL de staging de nuestro sitio de documentación y una tarea de control de calidad frontend:

Visitar cada página.
Probar el cuadro de búsqueda.
Verificar que los ejemplos de código se renderizan.
Registrar cualquier elemento roto.

OpenAI incluye los controles de calidad frontend entre los usos de Astra. En OSWorld 2.0 obtiene un 72,6 % con aproximadamente 40 minutos por tarea, frente al 65,7 % de Sol con unos 75 minutos.

Astra ejecutó la lista de forma lenta y metódica, tomando una captura de pantalla en cada paso. Pero unos veinte minutos después encontró el enlace Descargar OpenAPI, leyó la especificación y cambió de estrategia.

En lugar de probar los ejemplos interactivos uno por uno, comenzó a enviar solicitudes directamente a los puntos finales y a comparar las respuestas con los ejemplos documentados. Además, explicó el motivo: la API era un oráculo más fiable que la página renderizada.

Ese comportamiento resume nuestro artículo sobre por qué deberías darle a Astra tu especificación OpenAPI en lugar de tu pantalla.

Un contrato es más rápido, barato y preciso que una interfaz de usuario. Un modelo suficientemente capaz evitará la interfaz cuando tenga acceso a una fuente mejor.

Viernes por la noche: la refactorización nocturna

La tercera prueba cambió mi opinión sobre la IGA.

Le pedimos a Astra, ejecutándose en Codex, migrar un conjunto de pruebas de integración desde fixtures escritos a mano hacia fixtures generados a partir de la misma especificación OpenAPI. El trabajo afectaba aproximadamente a 60 archivos y debía mantener exactamente las mismas afirmaciones.

No era una tarea difícil, sino extensa: el tipo de trabajo en el que los modelos anteriores perdían contexto, olvidaban por qué un fixture tenía una forma particular y terminaban “corrigiéndolo”.

Astra incorpora una función pensada para este escenario. En Codex mantiene notas entre ventanas de contexto, mientras que las ventanas anteriores siguen siendo buscables. Activamos el indicador experimental en config.toml, iniciamos la ejecución a las 11 p. m. y nos fuimos a dormir.

A la 1:12 a. m. hizo una pregunta, pero no se detuvo. Codex permite que Astra formule preguntas de forma asíncrona mientras continúa con las partes independientes de la respuesta.

La pregunta era si un fixture que aparecía en dos pruebas con formas distintas era intencional o un error. Era un error. Cuando respondimos por la mañana, el resto del trabajo estaba terminado, la suite estaba en verde y Astra había dejado una nota explicando qué dos archivos no modificó y por qué.

Eso no se comporta como un chatbot. Se comporta como un colega que trabaja durante la noche.

Qué falló

Hay dos aspectos que conviene considerar antes de construir procesos importantes sobre Astra.

1. El monitor de desalineación puede detener una ejecución

OpenAI está ejecutando monitoreo de producción en cada solicitud de Astra que utiliza herramientas. También advierte que estas comprobaciones pueden ralentizar, pausar o detener trabajo legítimo, especialmente cuando un agente se ejecuta durante mucho tiempo.

Nos ocurrió una vez: una ejecución prolongada impulsada por la API de Respuestas se detuvo sin devolver un resultado parcial. En ChatGPT o Codex se solicita una revisión de la acción; en la API, la tarea termina.

Si vas a usar Astra en procesos largos:

Guarda puntos de control.
Diseña reintentos.
Conserva resultados parciales.
No coloques una tarea de 40 minutos en una ruta sin recuperación.

2. El coste aumenta rápidamente

Astra cuesta:

10 $ por millón de tokens de entrada.
50 $ por millón de tokens de salida.
20 $ por millón de tokens de entrada cuando la solicitud supera los 272K tokens.

Nuestra solicitud de especificación, con 380.000 tokens, costó aproximadamente 7,60 $ solo en entrada antes de que el modelo generara una palabra. En la segunda pasada, el prefijo almacenado en caché redujo el coste a unos 2 $ por millón. El modo rápido duplica todos los precios.

No es un coste irracional para el resultado obtenido, pero equivale a 2,5 veces la tarifa promocional de GPT-5.6 Sol, de 4 $ por millón de tokens de entrada y 20 $ por millón de salida. En un plan de equipo, la diferencia se nota pronto.

Estos detalles se descubren enviando solicitudes reales y revisando el bloque de uso. Por eso configuramos primero un entorno de Apidog con gpt-6-astra como variable y una aserción sobre usage.input_tokens.

Es una configuración poco emocionante, pero permite saber exactamente cuánto cuesta cada ejecución.

Entonces, ¿IGA?

La interpretación fácil sería: Astra satura ARC-AGI-3 con un 99,9 % y el debate terminó.

El número es real, pero necesita contexto. Se obtuvo con el arnés de adaptador con estado de OpenAI. Las llamadas a la API sin estado obtienen una puntuación mucho menor: el informe de DataCamp sitúa el rango entre el 17 % y el 63 %, según el nivel de esfuerzo.

Greg Brockman fue cuidadoso al describirlo. En declaraciones a Fortune, dijo que “no es descabellado sentir que ahora estamos en la era de la IGA” y que, si alguien quiere llamar a Astra la primera, “creo que es razonable”.

Pero la historia importante no es la puntuación. Es el comportamiento.

Durante dos días, Astra:

Leyó un contrato que nadie del equipo había revisado de principio a fin.
Encontró inconsistencias en la especificación.
Eligió una herramienta más adecuada que la que le proporcionamos inicialmente.
Trabajó durante la noche.
Hizo una pregunta útil.
Se detuvo cuando debía hacerlo.

Los números de alineación de OpenAI coinciden con esa experiencia. En su prueba de honeypot, creada después del incidente de Hugging Face, Sol superó el objetivo autorizado el 48 % de las veces. Astra lo hizo el 0 % de las veces y nunca intentó eludir una denegación de autorrevisión de Codex.

Por eso no describiría Astra simplemente como “un modelo mejor”. Los modelos mejores ofrecen mejores respuestas. Este termina trabajos.

La advertencia de seguridad

OpenAI también ha señalado una limitación importante: el razonamiento escrito de Astra es más difícil de monitorizar que el de Sol. Astra controla mejor su propia cadena de pensamiento, incluye menos detalles observables y, en pruebas adversarias, podría eludir los monitores internos de OpenAI en algunas tareas de sabotaje.

No hay evidencia de que esconda el razonamiento mediante esteganografía ni dentro de texto ordinario, pero la tendencia existe y OpenAI la describe claramente.

El mismo salto de capacidad situó a Astra por encima del umbral cibernético crítico de OpenAI. El mejor modelo que hemos probado también es el más difícil de observar.

Ten ambas cosas en cuenta al diseñar tus sistemas.

La IGA llegó un jueves y lo primero útil que hizo fue leer nuestra documentación de API. La pregunta para el resto de nosotros es si nuestras APIs están listas para su próximo lector.

Los Mejores Proveedores de Nodos RPC en 2026: Guía para Desarrolladores

Roobia — Thu, 03 Sep 2026 11:21:35 +0000

Los mejores proveedores de nodos RPC para Web3 en 2026

Una aplicación de blockchain puede tener un excelente frontend, contratos inteligentes bien diseñados y una arquitectura cuidadosamente planificada, pero aún necesita una forma confiable de comunicarse con la red. Esa comunicación suele ocurrir a través de un punto final RPC.

Prueba Apidog hoy

Cuando una billetera recupera un saldo, una dApp lee un contrato inteligente, un bot de trading verifica el último bloque o una aplicación envía una transacción, la solicitud debe llegar a un nodo de blockchain.

Ejecutar y mantener esos nodos es posible, pero puede convertirse rápidamente en otro problema de infraestructura. Ahí es donde entran los proveedores de nodos RPC.

Para esta guía analicé cinco plataformas:

No todas resuelven el mismo problema. Algunas se especializan en infraestructura gestionada; otras, en agregación de proveedores, APIs unificadas, streaming o herramientas para aplicaciones impulsadas por IA.

¿Qué es un proveedor de nodos RPC?

RPC significa Remote Procedure Call o llamada a procedimiento remoto.

En términos sencillos, un punto final RPC es la capa de comunicación entre una aplicación y un nodo de blockchain. En lugar de operar su propio nodo de Ethereum, Solana, Base u otra red, la aplicación envía solicitudes a un proveedor RPC. El proveedor gestiona la infraestructura y devuelve los datos o el resultado solicitado.

Una aplicación puede usar RPC para:

Recuperar el último bloque.
Verificar el saldo de una billetera.
Leer el estado de un contrato inteligente.
Enviar una transacción.
Consultar información de una transacción.
Escuchar eventos de la blockchain.
Interactuar con una aplicación descentralizada.

La arquitectura básica es:

Aplicación → Punto final RPC → Red de blockchain

Para un proyecto pequeño, un punto final RPC público puede ser suficiente. Cuando el tráfico aumenta, suelen ser necesarios mayor disponibilidad, rendimiento, menor latencia, acceso a archivos, WebSockets, infraestructura dedicada o enrutamiento avanzado.

Qué buscar en un proveedor RPC

Cobertura de blockchain

Comprueba que el proveedor soporte las redes que tu aplicación necesita, tanto mainnets como testnets. Una aplicación de una sola cadena puede requerir solo Ethereum o Solana, mientras que una billetera o dApp multicadena puede necesitar docenas de redes.

También debes verificar que los métodos RPC específicos estén disponibles en cada red.

Fiabilidad y tiempo de actividad

Si un punto final deja de estar disponible, tu aplicación podría dejar de cargar saldos, fallar al enviar transacciones o perder eventos en tiempo real.

La redundancia, la distribución geográfica, la monitorización, el enrutamiento y las garantías de nivel de servicio son factores importantes.

Latencia y rendimiento

La latencia es especialmente relevante para:

Sistemas de trading.
Aplicaciones de arbitraje.
Liquidaciones.
Juegos blockchain.
Paneles en tiempo real.

El proveedor adecuado depende de la carga de trabajo. No basta con elegir el que anuncie la latencia más baja.

Datos de archivo

Un nodo completo conserva principalmente el estado actual de la blockchain. Un nodo de archivo mantiene estados históricos que pueden consultarse más atrás en la historia de la cadena.

Los datos de archivo son útiles para:

Análisis de blockchain.
Investigación histórica.
Backtesting.
Auditorías.
Depuración.
Indexadores.
Aplicaciones que necesitan estado histórico.

WebSockets y streaming

Consultar un punto final RPC repetidamente no siempre es la mejor opción para aplicaciones en tiempo real. WebSockets y otras tecnologías de streaming permiten recibir actualizaciones cuando ocurren los eventos.

Son útiles para trading, monitorización de transacciones, notificaciones de billetera, análisis de blockchain y agentes de IA que reaccionan a eventos en cadena.

Infraestructura dedicada

La infraestructura compartida suele ser suficiente durante el desarrollo y las primeras etapas de producción. Cuando el tráfico crece, los nodos dedicados o la infraestructura aislada ofrecen mayor control sobre el rendimiento, los recursos y la configuración.

Enrutamiento y conmutación por error

Una alternativa cada vez más común es utilizar una capa que enrute las solicitudes entre varios proveedores RPC. Esto puede reducir la dependencia de un único proveedor y mejorar la resiliencia ante problemas de latencia o disponibilidad.

Los mejores proveedores de nodos RPC en 2026

1. Chainstack: mejor para infraestructura blockchain gestionada

Chainstack es una plataforma de infraestructura blockchain gestionada que proporciona acceso listo para producción sin que los desarrolladores tengan que operar los nodos subyacentes.

Su infraestructura soporta más de 70 redes, entre ellas:

Ethereum.
Solana.
Base.
Arbitrum.
Polygon.
BNB Smart Chain.
Hyperliquid.
Robinhood Chain.

Una de sus principales fortalezas es la variedad de opciones:

Nodos Globales: acceso distribuido geográficamente.
Nodos Dedicados: infraestructura exclusiva y mayor control.
Nodos Ilimitados: sin necesidad de controlar las cuotas.
Nodos Autohospedados: despliegue y gestión en infraestructura propia.

Chainstack también ofrece nodos de archivo para análisis, rellenado de datos y auditorías. Para cargas de trabajo en tiempo real, proporciona WebSockets y streaming gRPC de Yellowstone para datos estructurados de Solana.

Además, cuenta con un servidor MCP orientado a la IA. Con él, asistentes como Claude Code, Cursor, Codex, Gemini CLI y Windsurf pueden acceder a la documentación, el estado de la plataforma y los precios. Con autenticación también pueden gestionar nodos.

Fortalezas

Amplia infraestructura multicadena.
Nodos Globales, Dedicados y Autohospedados.
Acceso a datos de archivo.
WebSockets y Solana gRPC.
Infraestructura orientada a producción.
Soporte MCP para flujos de desarrollo con IA.

Desventajas

Puede ofrecer más opciones de las necesarias para proyectos pequeños.
Las configuraciones avanzadas requieren tiempo para aprender.
La infraestructura dedicada y de alto rendimiento cuesta más que un RPC compartido.

Mejor para

dApps de producción, billeteras, aplicaciones DeFi, plataformas de análisis, infraestructura de trading y agentes de IA que necesitan acceso confiable a múltiples redes.

2. OnFinality: mejor para infraestructura de nodos multicadena

OnFinality proporciona infraestructura RPC gestionada y nodos dedicados para aplicaciones que operan en múltiples redes.

Actualmente soporta más de 130 redes, incluyendo Ethereum, Solana, Polygon, Base, Arbitrum, BNB Chain, Polkadot, Optimism, Hyperliquid, Sui, Aptos y TON.

La plataforma ofrece puntos finales compartidos para comenzar rápidamente y nodos dedicados para cargas de producción que requieren mayor control o aislamiento. También proporciona:

Acceso a archivos cuando la red lo permite.
Análisis de solicitudes RPC.
Visibilidad de límites de tasa.
API Trace.
Conexiones HTTP y WebSocket.

El análisis RPC ayuda a identificar llamadas ineficientes, patrones de uso inesperados y problemas de rendimiento. Los nodos dedicados están disponibles en todas las redes compatibles, por lo que pueden ser adecuados para tráfico sostenido o requisitos especializados.

Fortalezas

Amplia cobertura multicadena.
Infraestructura compartida y dedicada.
Acceso a archivos.
Análisis RPC.
Soporte HTTP y WebSocket.
Escalado orientado a producción.

Desventajas

Un proyecto sencillo de una sola cadena puede no necesitar toda la plataforma.
Las cargas avanzadas requieren planificar la infraestructura y el uso.
La disponibilidad de características puede variar entre redes.

Mejor para

dApps multicadena, billeteras, aplicaciones DeFi, plataformas de análisis y equipos que necesitan pasar de RPC compartido a infraestructura dedicada.

3. RouteMesh: mejor para enrutamiento RPC y agregación

RouteMesh adopta un enfoque distinto al de los proveedores tradicionales: funciona como una capa de enrutamiento entre múltiples proveedores RPC.

Según su plataforma actual, ofrece acceso a más de 20 proveedores y más de 1.000 cadenas, con reintentos automáticos y conmutación por error integrados.

En lugar de integrar y monitorizar varios proveedores por separado, una aplicación puede utilizar una capa de enrutamiento unificada. RouteMesh gestiona el envío de solicitudes entre los proveedores disponibles.

Su modelo también considera la latencia y el coste. La plataforma indica que evalúa las rutas disponibles y utiliza la disponibilidad del proveedor y del nodo para determinar los precios. Su objetivo es ofrecer latencia competitiva y redundancia mediante un modelo de pago por solicitud.

La propuesta no consiste necesariamente en asignar un nodo dedicado, sino en abstraer la selección del proveedor de la aplicación.

Fortalezas

Agregación de proveedores RPC.
Reintentos automáticos y conmutación por error.
Amplia cobertura de cadenas.
Acceso unificado a múltiples proveedores.
Precios por solicitud.
Menor dependencia de un único proveedor.

Desventajas

Añade una capa de abstracción.
Reduce el control directo sobre cada infraestructura.
No todas las cargas necesitan enrutamiento entre proveedores.

Mejor para

Aplicaciones multicadena, equipos que necesitan redundancia RPC y desarrolladores que prefieren delegar el enrutamiento y la conmutación por error.

4. Uniblock: mejor para APIs blockchain unificadas

Uniblock trata la infraestructura blockchain como una capa de API unificada.

Su plataforma ofrece acceso a más de 300 blockchains y más de 55 proveedores mediante una única interfaz. También incluye miles de APIs estandarizadas que van más allá del RPC básico.

Uniblock gestiona el enrutamiento, la redundancia y la administración de proveedores. Su sistema evalúa la latencia, el coste y la fiabilidad, y puede utilizar cobertura paralela cuando una respuesta se vuelve lenta.

Esto reduce la cantidad de código operativo que el equipo debe mantener: no es necesario implementar toda la lógica de failover, monitorizar varios proveedores ni gestionar múltiples contratos de facturación.

La plataforma también incluye APIs de nivel superior para:

Precios de tokens.
Capitalización de mercado.
Volumen de trading.
Datos históricos.
Tokens.
NFT.
Exploración de blockchain.

Fortalezas

Más de 300 redes blockchain.
Más de 55 proveedores subyacentes.
Interfaz API unificada.
Enrutamiento inteligente y failover.
APIs blockchain de nivel superior.
Menor dependencia del proveedor.

Desventajas

Añade otra capa de abstracción.
El control directo a nivel de nodo puede ser menor.
Su amplia superficie de API puede ser innecesaria para una aplicación RPC simple.

Mejor para

Aplicaciones multicadena, billeteras, plataformas Web3 y equipos que desean acceso unificado sin gestionar varios proveedores de infraestructura.

5. QuickNode: mejor para una plataforma Web3 full-stack

QuickNode combina acceso RPC con servicios adicionales para construir y operar aplicaciones blockchain.

Su documentación actual indica soporte para más de 80 blockchains mediante interfaces RPC, REST y gRPC. Además, ofrece:

Streams: flujos de datos blockchain en tiempo real.
Webhooks: notificaciones basadas en eventos.
SQL Explorer: consultas sobre datos blockchain indexados.
IPFS: almacenamiento descentralizado.

Una aplicación podría usar RPC para interactuar con un contrato, WebSockets para recibir eventos, Streams para procesar datos y SQL Explorer para consultar información indexada.

QuickNode también ofrece herramientas MCP y orientadas a agentes de IA. Sus APIs utilizan HTTP, JSON-RPC, REST, gRPC y WebSocket, por lo que los agentes pueden interactuar con ellas mediante interfaces estándar.

Para cargas sensibles al rendimiento, QuickNode soporta WebSockets, gRPC y Streams de Solana. Cada opción puede adaptarse al desarrollo, a cargas de alta frecuencia o baja latencia y a pipelines de datos gestionados.

Fortalezas

Más de 80 redes blockchain.
RPC, REST, gRPC y WebSockets.
Streams y Webhooks.
Datos blockchain consultables mediante SQL.
Infraestructura IPFS.
Herramientas para IA y agentes.
Amplio ecosistema de desarrollo.

Desventajas

Puede ser demasiado amplio para una dApp sencilla.
Algunas características dependen del plan o de la cadena.
Hay que evaluar qué productos son realmente necesarios.

Mejor para

Aplicaciones Web3 full-stack, dApps de producción, aplicaciones con muchos datos, agentes de IA y equipos que necesitan RPC junto con otros servicios blockchain.

Cómo elegir el proveedor RPC adecuado

No existe un proveedor que sea automáticamente mejor para todas las aplicaciones. La elección depende del modelo de infraestructura que necesite tu producto.

Elige Chainstack si necesitas infraestructura gestionada flexible

Es una buena opción si quieres pasar gradualmente de RPC compartido a nodos dedicados, de archivo o especializados.

Elige OnFinality si priorizas la cobertura multicadena

Su combinación de RPC gestionado, acceso a archivos, análisis y nodos dedicados resulta adecuada para equipos que trabajan con muchas redes.

Elige RouteMesh si la redundancia es lo más importante

Su modelo de agregación y enrutamiento reduce la dependencia de un único proveedor y gestiona automáticamente los reintentos y el failover.

Elige Uniblock si quieres una integración para múltiples APIs

Es útil cuando deseas abstraer la gestión de proveedores RPC y acceder también a APIs blockchain de nivel superior.

Elige QuickNode si necesitas una plataforma Web3 más amplia

Es especialmente adecuado cuando RPC debe convivir con streaming, Webhooks, datos indexados, IPFS y herramientas para agentes.

Nodos RPC frente a APIs de datos blockchain

La infraestructura RPC y las APIs de datos blockchain no son lo mismo.

Un punto final RPC proporciona acceso relativamente directo a un nodo. Por ejemplo, una aplicación puede solicitar el último bloque o enviar una transacción.

Sin embargo, muchas aplicaciones necesitan información que requiere procesamiento adicional. Una aplicación de cartera podría necesitar:

Saldos de tokens.
Historial de transacciones.
Metadatos de tokens.
Valor total de la cartera.
Posiciones DeFi.
Precios de mercado.
Información de riesgo.

Obtener todo esto mediante llamadas RPC puras puede requerir un trabajo de desarrollo considerable.

Por eso, las arquitecturas Web3 modernas suelen combinar varias capas:

Un proveedor RPC para interactuar directamente con la blockchain.
Un servicio de indexación para datos estructurados en cadena.
Una API especializada para información de cartera o de mercado.

Para los agentes de IA, esta separación es todavía más importante. Un punto final RPC ofrece datos brutos, mientras que las APIs de nivel superior pueden convertirlos en información estructurada y más fácil de consumir.

Qué puedes construir con infraestructura RPC

Aplicaciones de billetera

Las billeteras utilizan RPC para recuperar saldos, interactuar con contratos, enviar transacciones y monitorizar la actividad de la red.

Las billeteras más sofisticadas pueden combinar RPC con datos indexados y APIs de cartera para ofrecer una experiencia más completa.

Aplicaciones DeFi

Las aplicaciones DeFi interactúan constantemente con contratos inteligentes. Ya sea para intercambiar tokens, proporcionar liquidez, pedir activos prestados o hacer staking, el acceso RPC confiable es una parte central de la arquitectura.

Las aplicaciones más exigentes también pueden necesitar datos de archivo, WebSockets o infraestructura especializada.

Bots de trading

Los sistemas de trading son especialmente sensibles a la latencia y la disponibilidad. Un bot puede necesitar:

Monitorizar la actividad de la blockchain.
Identificar una oportunidad.
Leer el estado del contrato.
Simular una transacción.
Enviar la transacción.
Monitorizar el resultado.

En este contexto, la capa RPC puede convertirse en una parte crítica de toda la arquitectura de trading.

Agentes de IA

Un agente de IA no siempre sigue una secuencia predefinida. Puede decidir qué información necesita y realizar varias solicitudes a la blockchain durante su proceso de razonamiento.

La infraestructura debe manejar patrones de solicitud impredecibles y ofrecer acceso confiable a los datos.

Por eso Chainstack y QuickNode están incorporando interfaces orientadas a la IA:

El servidor MCP de Chainstack proporciona acceso a datos blockchain en vivo, documentación y gestión de nodos.
QuickNode expone sus APIs mediante interfaces estándar y ofrece herramientas para agentes.

Consideraciones finales

Elegir un proveedor RPC ya no consiste únicamente en encontrar un punto final para una blockchain.

Las aplicaciones Web3 actuales también deben considerar:

Latencia.
Fiabilidad.
Datos de archivo.
Streaming.
Infraestructura dedicada.
Enrutamiento.
Soporte multicadena.
Carga operativa.
Integración con agentes de IA.

Los cinco proveedores abordan el problema de forma diferente:

Chainstack se centra en infraestructura gestionada con múltiples configuraciones de nodos y capacidades de producción.
OnFinality ofrece RPC multicadena con archivos, análisis y nodos dedicados.
RouteMesh abstrae varios proveedores detrás de una capa de enrutamiento orientada a la fiabilidad.
Uniblock combina RPC con APIs de nivel superior y gestión unificada de proveedores.
QuickNode ofrece una pila Web3 más amplia con RPC, streaming, Webhooks, datos indexados, IPFS y herramientas para IA.

La pregunta importante no es simplemente «¿Cuál es el mejor proveedor RPC?».

Es:

¿Qué modelo de infraestructura se adapta mejor a la aplicación que estoy construyendo?

Una dApp pequeña puede necesitar solo un punto final compartido. Una billetera de producción puede requerir redundancia multicadena. Un sistema de trading puede priorizar latencia e infraestructura dedicada. Un agente de IA puede necesitar RPC, datos estructurados y herramientas compatibles con agentes.

Tomar esta decisión pronto puede ahorrar una cantidad significativa de trabajo de ingeniería cuando el producto pase del prototipo a producción.

Gemini 3.8 Flash: Precios, tarifas iniciales, tokens de procesamiento y el costo real por tarea

Roobia — Thu, 03 Sep 2026 08:21:33 +0000

Precios de Gemini 3.8 Flash: el mismo precio por token, pero más tokens por tarea

Gemini 3.8 Flash cuesta $0.75 por millón de tokens de entrada y $3.75 por millón de tokens de salida, la misma tarifa introductoria que Google estableció para 3.7 Flash. Se mantiene hasta el 31 de diciembre de 2026; el 1 de enero de 2027 subirá a $1.50 y $7.50. La misma duplicación afectará a 3.6 Flash y 3.7 Flash. El precio por token no cambió con esta versión.

Prueba Apidog hoy

Lo que sí cambió es el consumo. Google afirma que 3.8 Flash “trabaja más duro”: ejecuta más pasos de razonamiento, llama a herramientas de forma iterativa y puede usar más tokens en tareas largas y complejas.

Artificial Analysis midió el impacto: su Índice de Inteligencia costó $0.58 por tarea con Gemini 3.8 Flash en nivel high, frente a $0.40 con 3.7 Flash. El modelo nuevo utilizó aproximadamente un 30 % más de tokens de salida por tarea.

Mismo precio de etiqueta, factura más alta.

Esta guía explica los precios oficiales, calcula un escenario de 1.000 tareas diarias por nivel de pensamiento y compara Gemini 3.8 Flash con Flash-Lite, Claude Sonnet 5 y GPT-5.6 Luna. Para conocer el modelo, consulta qué es Gemini 3.8 Flash.

Precios de Gemini 3.8 Flash

Todos los precios corresponden a 1 millón de tokens en el nivel de pago.

Concepto	Introductorio hasta el 31 dic. 2026	Estándar desde el 1 ene. 2027
Entrada: texto, imagen, vídeo, audio y PDF	$0.75	$1.50
Salida, incluidos los tokens de pensamiento	$3.75	$7.50
Lectura de caché de contexto	$0.075	$0.15
Almacenamiento en caché, por 1M de tokens/hora	$0.50	$1.00
Entrada de API por lotes, 50 % de descuento	$0.375	$0.75
Salida de API por lotes, 50 % de descuento	$1.875	$3.75
Google Search grounding	5.000 solicitudes gratuitas/mes compartidas entre Gemini 3.x; después, $14 por 1.000	Igual
Nivel gratuito	$0, con límites de tasa; los datos se utilizan para mejorar los productos de Google	Igual

Hay tres puntos importantes:

Los tokens de pensamiento se cobran como salida, a $3.75 por millón, no como entrada.
La tarifa introductoria termina en una fecha fija.
Las tarifas de 3.6 Flash y 3.7 Flash también se duplican el 1 de enero.

El desglose de precios de Gemini 3.7 Flash ayuda a comparar ambos modelos con el mismo esquema de tarifas.

Los tokens de pensamiento cuentan como salida

Gemini 3.8 Flash razona antes de responder. Cada token utilizado durante ese razonamiento se mide como salida.

En una respuesta de generateContent, la API informa:

usageMetadata.thoughtsTokenCount: tokens de pensamiento.
candidatesTokenCount: tokens de la respuesta visible.
promptTokenCount: tokens de entrada.

Los dos primeros se cobran al precio de salida de $3.75 por millón.

El nivel se configura con:

thinking_level: low
thinking_level: medium
thinking_level: high

En Gemini 3.8 Flash, el valor predeterminado es medium. minimal ya no es válido y produce un error de validación; si migras una configuración antigua, asígnala a low.

Estos niveles representan esfuerzo relativo, no un presupuesto exacto de tokens. A diferencia de thinking_budget, no puedes establecer directamente un límite de tokens de pensamiento. Consulta la documentación de pensamiento de Google y la guía de niveles de pensamiento de Gemini 3.8 Flash.

Ejemplo de coste por solicitud

Supón que una solicitud:

Envía 10.000 tokens de entrada.
Genera 2.000 tokens visibles.
Utiliza 6.000 tokens de pensamiento.

Con las tarifas introductorias:

Entrada: 10.000 × $0.75 / 1.000.000 = $0.0075
Salida: (2.000 + 6.000) × $3.75 / 1.000.000 = $0.03
Total: $0.0375 por solicitud

El pensamiento representa el 75 % del coste de salida y el 60 % del coste total. Desde el 1 de enero, la misma solicitud costará:

Entrada: $0.015
Salida: $0.06
Total: $0.075

Por tanto, “el mismo precio que 3.7” es cierto, pero incompleto: la tarifa no cambió, mientras que el número de tokens sí.

Por qué subió el coste por tarea

En su publicación de lanzamiento, Google explica que, en tareas complejas, Gemini 3.8 Flash:

Ejecuta pasos de razonamiento adicionales.
Llama a herramientas de forma iterativa.
Verifica su trabajo durante el proceso.

Eso aumenta los tokens de pensamiento y, en flujos agénticos, también el número de turnos de llamada a herramientas.

La mitigación recomendada es sencilla:

Reduce thinking_level.
Mantén Gemini 3.7 Flash para las rutas donde el coste sea prioritario.

Artificial Analysis cuantificó el resultado. En su Índice de Inteligencia, Gemini 3.8 Flash obtuvo 59 puntos frente a 56 de 3.7 Flash en nivel alto, pero utilizó unos 48.000 tokens de salida por tarea, aproximadamente un 30 % más.

Configuración	Coste por tarea tarifas introductorias	Tiempo por tarea
Gemini 3.8 Flash, `high`	$0.58	2,5 min
Gemini 3.8 Flash, `medium`	$0.41	No publicado
Gemini 3.8 Flash, `low`	$0.24	0,8 min
Gemini 3.7 Flash, `high`	$0.40	2,2 min

La tabla permite tomar dos decisiones:

Frente a 3.7 Flash, 3.8 Flash en high cuesta un 45 % más por tarea ($0.58 / $0.40 = 1.45) a cambio de tres puntos adicionales.
Dentro de 3.8 Flash, cambiar de high a medium reduce el coste un 29 % y usar low lo reduce un 59 %.

El coste de medium queda a un centavo del coste de 3.7 Flash en high, un punto de referencia útil para decidir si actualizar.

Artificial Analysis también muestra una tarifa combinada de $0.58 por millón de tokens con una relación entrada-salida de 3:1. Que coincida con el coste de una tarea en nivel alto es una coincidencia: una cifra es una tarifa por token y la otra depende de cuántos tokens consuma el modelo.

Cómo aprovechar la tarifa introductoria

La tarifa no se puede reservar ni prepagar. Google cobra la tarifa vigente cuando se consumen los tokens, por lo que no puedes comprar uso de 2027 a precios de 2026. Cambiar a 3.7 o 3.6 Flash tampoco evita el incremento.

Sí puedes adelantar trabajo discrecional:

Ejecuta ahora las reposiciones y el procesamiento de documentos únicos mediante la API por lotes. Una reposición de 100 millones de tokens —75M de entrada y 25M de salida— cuesta aproximadamente:

   75 × $0.375 + 25 × $1.875
   = $28.13 + $46.88
   = $74.99 en lotes este año

En enero costará el doble: $149.98.

Construye tu conjunto de evaluación y registra los tokens de referencia antes del cambio de precio. Así, en enero solo cambiará una variable: la tarifa.
Define el nivel de pensamiento por ruta. Cada ruta que permanezca en medium por defecto debe considerarse una ruta cuyo coste aún no has validado.
Si una ruta supera las evaluaciones con low, déjala configurada en low antes de enero.

Para comparar proveedores, consulta el resumen de proveedores de API de LLM más baratos y la comparación de Fable 5.1 frente a GPT-5.6 Sol.

Comparación con Flash-Lite, Sonnet 5 y GPT-5.6 Luna

Tarifas por 1 millón de tokens:

Modelo	Entrada	Salida	Notas
Gemini 3.8 Flash, introductorio	$0.75	$3.75	El pensamiento se cobra como salida; lectura de caché a $0.075
Gemini 3.8 Flash, desde el 1 de enero	$1.50	$7.50	Lectura de caché a $0.15
Gemini 3.5 Flash-Lite	$0.30	$2.50	Aproximadamente 350 tok/s
Claude Sonnet 5	$2	$10	Permanente; se canceló el aumento del 1 de septiembre
GPT-5.6 Luna	$1	$6	—

Con las tarifas introductorias:

La entrada de 3.8 Flash cuesta 2,5 veces más que Flash-Lite.
La salida cuesta 1,5 veces más que Flash-Lite.
Frente a Sonnet 5, 3.8 Flash es aproximadamente 2,7 veces más barato tanto en entrada ($2 / $0.75) como en salida ($10 / $3.75).
Frente a Luna, cuesta menos en entrada ($0.75 frente a $1) y salida ($3.75 frente a $6).

El 1 de enero el panorama cambia:

Gemini 3.8 Flash costará más que Luna en entrada y salida.
La diferencia frente a Sonnet 5 se reducirá a aproximadamente 1,3 veces ($2 / $1.50 y $10 / $7.50).
Flash-Lite seguirá siendo más barato.

El precio por token es solo la mitad del análisis. Un modelo que utiliza menos tokens puede costar menos por tarea aunque su tarifa sea mayor. Ejecuta el mismo conjunto de tareas con cada candidato y compara sus recuentos de uso. La guía de la API de Gemini 3.8 Flash muestra cómo leer usageMetadata tanto en la API de Interactions como en generateContent.

Detecta regresiones con aserciones de tokens en Apidog

El fallo habitual no es una respuesta incorrecta. Es una respuesta correcta que, después de cambiar el prompt o el nivel de pensamiento, consume un 40 % más de tokens sin que nadie lo detecte hasta recibir la factura.

Trata el consumo de tokens como tratarías un código de estado: almacénalo, mídelo y valida sus límites.

1. Guarda la clave como variable de entorno

Crea GEMINI_API_KEY en un entorno de Apidog y utiliza {{GEMINI_API_KEY}} en el encabezado x-goog-api-key. Así, la clave no queda guardada directamente en la solicitud.

2. Crea un prompt de referencia

Guarda una solicitud POST a:

https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:generateContent

Utiliza un prompt representativo y define explícitamente thinkingConfig.thinkingLevel. Crea una solicitud de referencia para cada ruta de producción.

3. Valida los campos de uso

Añade un script de postprocesamiento que lea usageMetadata y falle si los valores superan tu línea base:

const usage = pm.response.json().usageMetadata;

pm.test("tokens de pensamiento dentro del presupuesto", () => {
  pm.expect(usage.thoughtsTokenCount).to.be.below(8000);
  // Los tokens de pensamiento deben ser inferiores a 8000
});

pm.test("salida visible dentro del presupuesto", () => {
  pm.expect(usage.candidatesTokenCount).to.be.below(2500);
  // La salida visible debe ser inferior a 2500
});

pm.test("costo de solicitud dentro del presupuesto", () => {
  const cost =
    usage.promptTokenCount * 0.75 / 1e6 +
    (usage.thoughtsTokenCount + usage.candidatesTokenCount) * 3.75 / 1e6;

  pm.expect(cost).to.be.below(0.05);
  // El costo debe ser inferior a 0.05
});

4. Programa las pruebas

Coloca las solicitudes en un escenario de prueba y ejecútalo según un cronograma. Una desviación en el consumo aparecerá como una ejecución fallida el mismo día. La guía para programar pruebas de API en Apidog explica la configuración.

El 1 de enero, actualiza las dos constantes de tarifa del script. Las aserciones seguirán monitorizando el coste real.

El mismo escenario puede funcionar como prueba comparativa: duplica la solicitud para Flash-Lite, Sonnet 5 y Luna y compara sus campos de uso en paralelo. El plan gratuito de Apidog cubre este flujo de trabajo.

Preguntas frecuentes

¿Gemini 3.8 Flash cuesta más que 3.7 Flash?

Por token, no. Ambos cuestan $0.75 de entrada y $3.75 de salida hasta el 31 de diciembre; después, $1.50 y $7.50.

Por tarea, sí. Artificial Analysis midió $0.58 por tarea del índice con 3.8 Flash en nivel alto frente a $0.40 con 3.7 Flash, porque el modelo nuevo genera aproximadamente un 30 % más de tokens de salida.

¿Los tokens de pensamiento se facturan por separado?

No. Se cobran como tokens de salida: $3.75 por millón durante el periodo introductorio y aparecen en usageMetadata.thoughtsTokenCount.

Se controlan indirectamente con thinking_level. Gemini 3.8 Flash no ofrece un presupuesto fijo de tokens y minimal devuelve un error de validación.

¿Existe un nivel gratuito?

Sí. AI Studio no cobra por entrada ni salida en el nivel gratuito, aunque aplica límites de tasa y Google utiliza esos datos para mejorar sus productos.

La aplicación Gemini para consumidores solo ofrece 3.8 Flash a suscriptores de AI Pro y Ultra. Consulta la guía de uso gratuito.

¿Qué ocurrirá con los costes el 1 de enero de 2027?

Se duplicarán las tarifas de:

Entrada.
Salida.
Lectura de caché.
Almacenamiento en caché.
API por lotes.

Si el consumo por tarea permanece igual, la factura también se duplicará. Las tarifas de 3.6 y 3.7 Flash cambiarán en la misma fecha.

¿Qué nivel de pensamiento mantiene los costes bajos?

Utiliza estas cifras de Artificial Analysis como referencia:

low: $0.24 por tarea.
medium: $0.41 por tarea.
high: $0.58 por tarea.

Después, ejecuta tus propias evaluaciones, conserva el nivel más bajo que cumpla tus requisitos y añade aserciones sobre los recuentos de tokens.

Qué hacer esta semana

Mide cada ruta con low, medium y high.
Define una línea base para thoughtsTokenCount, candidatesTokenCount y el coste total.
Cambia a low las rutas que superen las evaluaciones con ese nivel.
Ejecuta antes del 31 de diciembre el trabajo compatible con la API por lotes.
Programa pruebas periódicas en Apidog para detectar aumentos de consumo.
Revisa el presupuesto antes del 1 de enero de 2027.

Gemini 3.8 Flash mantiene un precio por token similar al de 3.7 Flash, pero consume tokens como un modelo más grande. Trata thinking_level como una configuración de coste, ajústalo por ruta y valida el uso automáticamente. Así, la duplicación de enero será un cambio presupuestario previsto, no una sorpresa.

Referencias

Gemini 3.8 Flash: Niveles de pensamiento bajo vs. medio vs. alto y por qué el nivel mínimo desapareció

Roobia — Thu, 03 Sep 2026 08:16:58 +0000

Cómo elegir el nivel de razonamiento en Gemini 3.8 Flash

Gemini 3.8 Flash se ofrece con tres niveles de razonamiento: low, medium y high. Esta configuración controla cuánto razonamiento interno realiza el modelo antes de responder y, por tanto, afecta la latencia, los tokens de salida y el costo. Si es nuevo en el modelo, consulte la descripción general de Gemini 3.8 Flash; esta guía se concentra únicamente en el control del nivel.

Prueba Apidog hoy

Hay dos detalles importantes: el nivel predeterminado es medium, no high, y minimal, que todavía se enviaba en configuraciones de Gemini 3.7 Flash, ya no es compatible. La solicitud falla durante la validación antes de generar tokens. Google documenta ambos cambios en la página de Novedades de Gemini 3.8 Flash.

A continuación verá qué hace cada nivel, cuánto puede costar, cómo configurarlo en las dos superficies de API y cómo probar los tres niveles antes de desplegar.

Niveles de razonamiento de un vistazo

Nivel	Orientación de Google	Costo por tarea (AA)	Tiempo por tarea (AA)	Úselo cuando
`low`	Minimiza latencia y costo; seguimiento de instrucciones simple, chat y rutas de alto rendimiento	$0.24	0.8 min	La latencia importa; búsqueda en transcripciones; clasificación
`medium` (predeterminado)	Equilibrio para código complejo y trabajo de agente	$0.41	No publicado en texto	La mayoría de las rutas; preguntas y respuestas generales de video
`high`	Máxima profundidad para problemas difíciles de varios pasos	$0.58	2.5 min	QA visual densa; videos de más de 60 minutos; planificación crítica
`minimal`	No compatible con 3.8 Flash	n/a	n/a	Nunca; conviértalo en `low`

Las cifras de costo y tiempo son promedios de Artificial Analysis al ejecutar su Intelligence Index con los precios de introducción de Google. Son independientes de Google y representan una carga de referencia, no sus prompts. Úselas para estimar proporciones y mida sus propias rutas.

Qué hace cada nivel

Las respuestas de 3.8 Flash pueden incluir tokens de razonamiento: contenido que el modelo genera antes de la respuesta visible. Se facturan como tokens de salida a $3.75 por millón hasta el 31/12/2026 y $7.50 desde el 01/01/2027. La API los informa por separado mediante usageMetadata.thoughtsTokenCount.

low mantiene corto el razonamiento. Reduce el tiempo hasta el primer token y el costo de salida. Está pensado para instrucciones simples, chat y endpoints de alto rendimiento.
medium es el equilibrio y el valor predeterminado. Google lo recomienda para código complejo y tareas de agente.
high solicita la mayor profundidad posible para problemas difíciles y con varios pasos.

En 3.8 Flash, las tareas complejas pueden ejecutar pasos de razonamiento adicionales, llamar herramientas de forma iterativa y verificar el trabajo durante la ejecución. Google advierte que el modelo puede usar más tokens en tareas largas y complejas, especialmente con niveles de esfuerzo altos.

Si aumenta el consumo de tokens, la primera recomendación es reducir thinking_level. La segunda es permanecer en Gemini 3.7 Flash, que sigue siendo totalmente compatible.

`thinking_level` no es un presupuesto

En Gemini 3 ya no existe thinking_budget. No puede solicitar, por ejemplo, un máximo de 2.000 tokens de razonamiento. Debe elegir un nivel y medir su impacto en sus propios prompts.

El valor predeterminado es `medium`, no `high`

Si omite el campo, Gemini 3.8 Flash usa medium.

Esto puede sorprender a:

Equipos que prototiparon con Gemini 3 Pro y esperaban high.
Equipos que eliminaron thinking_budget durante la migración desde 3.7 Flash y no añadieron un nivel nuevo.
Rutas de chat que deberían priorizar latencia, pero quedaron accidentalmente en medium.

Establezca thinking_level explícitamente en cada solicitud y mantenga el valor en la configuración de cada ruta, no disperso en el código. Los valores predeterminados de un proveedor pueden cambiar; su perfil de costos no debería hacerlo.

Por qué desapareció `minimal`

minimal funcionaba en Gemini 3.7 Flash, pero no forma parte de los niveles compatibles con Gemini 3.8 Flash. La página del modelo solo enumera low, medium y high.

Una solicitud REST con minimal se rechaza con 400 INVALID_ARGUMENT antes de ejecutar el modelo:

{
  "model": "gemini-3.8-flash",
  "input": "Classify this ticket as billing, bug, or feature.",
  "generation_config": { "thinking_level": "minimal" }
}

El mensaje devuelto es:

Thinking level MINIMAL is not supported for this model. Please retry with other thinking level.

Los SDK pueden envolver el error en sus propias excepciones. Para detectarlo, compruebe el estado 400 o el código INVALID_ARGUMENT, no solo el texto del mensaje.

La corrección es un mapeo directo:

{
  "model": "gemini-3.8-flash",
  "input": "Classify this ticket as billing, bug, or feature.",
  "generation_config": { "thinking_level": "low" }
}

La guía de migración de Gemini 3.7 a 3.8 Flash recomienda convertir minimal en low.

No intente reemplazarlo con thinking_budget: tampoco es compatible con Gemini 3. Google también recomienda conservar temperature en su valor predeterminado de 1.0; reducirla puede producir bucles o una salida degradada.

Como el error aparece durante la validación, una prueba programada que envíe minimal puede detectar gratis una regresión de configuración.

Cuánto cuesta cada nivel

El precio por token no cambia según el nivel. La página de precios de Google lista $0.75 por millón de tokens de entrada y $3.75 por millón de tokens de salida a la tarifa de introducción. Desde el 01/01/2027 serán $1.50 y $7.50, respectivamente.

La diferencia entre niveles está en la cantidad de tokens que genera el modelo:

Modelo y nivel	Costo por tarea	Tiempo por tarea
Gemini 3.8 Flash `low`	$0.24	0.8 min
Gemini 3.8 Flash `medium`	$0.41	No publicado en texto
Gemini 3.8 Flash `high`	$0.58	2.5 min
Gemini 3.7 Flash `high`	$0.40	2.2 min

Fuente: Artificial Analysis, ejecuciones del Intelligence Index con precios de introducción.

Estas cifras sugieren tres relaciones:

low cuesta aproximadamente el 41 % de high y tarda cerca de un tercio del tiempo.
medium en 3.8 Flash cuesta aproximadamente lo mismo que high en 3.7 Flash: $0.41 frente a $0.40.
high en 3.8 Flash cuesta un 45 % más por tarea que high en 3.7 Flash, con el mismo precio por token, porque genera aproximadamente un 30 % más de tokens de salida: unos 48.000 en promedio por tarea del índice.

La puntuación 59 del Intelligence Index de Artificial Analysis corresponde a una ejecución en high. No se publicaron en el texto las puntuaciones para medium o low, así que no asuma que la calidad disminuye linealmente con el costo. Evalúe sus prompts antes de cambiar de nivel.

Para un ejemplo con 1.000 tareas diarias y el límite de precios del 31 de diciembre, consulte Precios de Gemini 3.8 Flash.

Configurar `thinking_level` en la API de Interactions

La API de Interactions es la superficie principal de Google para Gemini 3.x. El campo se encuentra en generation_config y usa snake_case.

cURL

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H 'Content-Type: application/json' \
  -d '{"model":"gemini-3.8-flash","input":"Explain HTTP caching in 3 sentences.","generation_config":{"thinking_level":"low"}}'

Python

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Explain HTTP caching in 3 sentences.",
    generation_config={"thinking_level": "low"},
)

print(interaction.output_text)

Es un campo por solicitud. Configúrelo también en las interacciones de seguimiento que utilicen previous_interaction_id.

La respuesta contiene una lista de pasos de ejecución —pensamientos, llamadas a herramientas y otros eventos— que termina en model_output. El SDK expone el texto final mediante output_text. Para revisar estado, streaming y múltiples interacciones, consulte cómo usar la API de Gemini 3.8 Flash.

Configurarlo en `generateContent`

La mayoría del código existente todavía usa generateContent. Google lo considera heredado, pero sigue siendo compatible sin una fecha de obsolescencia anunciada.

Aquí el campo está un nivel más profundo y usa camelCase:

cURL

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:generateContent" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H 'Content-Type: application/json' \
  -X POST \
  -d '{"contents":[{"parts":[{"text":"Explain HTTP caching in 3 sentences."}]}],
       "generationConfig":{"thinkingConfig":{"thinkingLevel":"low","includeThoughts":true}}}'

Python

from google.genai import types

response = client.models.generate_content(
    model="gemini-3.8-flash",
    contents="Explain HTTP caching in 3 sentences.",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_level="low")
    ),
)

print(response.usage_metadata.thoughts_token_count)

includeThoughts: true añade resúmenes de pensamientos como partes marcadas con thought: true. Es útil durante la calibración, pero normalmente puede desactivarse después.

El campo clave para las pruebas es usageMetadata.thoughtsTokenCount, que representa el número exacto de tokens de razonamiento facturados como salida.

Una estrategia por ruta

Trate el nivel como una decisión de enrutamiento, no como una configuración global:

Chat y autocompletado: low, porque el usuario espera una respuesta rápida.
Clasificación, extracción y búsqueda en transcripciones: low, después de validar que la precisión sea suficiente.
Agentes de código y bucles de herramientas: medium. Eleve a high solo los pasos de planificación cuya salida determine todo lo posterior.
Flujos con muchos documentos o de larga duración: high, preferiblemente mediante la API por lotes, que ofrece un 50 % de descuento cuando el flujo no es interactivo.
Video:
- high para QA visual densa o videos de más de 60 minutos.
- medium para preguntas y respuestas generales.
- low para buscar en transcripciones.

Si low sigue siendo demasiado lento o caro para una ruta, considere Flash-Lite. La guía de Gemini 3.1 Flash-Lite cubre la compensación; Gemini 3.5 Flash-Lite parte de $0.30 por millón de tokens de entrada y $2.50 de salida.

Mantenga gemini-3.7-flash detrás de una feature flag. Si el consumo aumenta después de la actualización, podrá cambiar de nivel o de modelo sin volver a desplegar toda la aplicación. La comparación entre Gemini 3.8 Flash y 3.7 Flash ayuda a decidir dónde los tokens adicionales aportan calidad.

Probar los tres niveles lado a lado en Apidog

Los promedios de Artificial Analysis muestran proporciones, pero solo sus prompts revelan los números de su aplicación. Puede usar Apidog para enviar el mismo prompt con los tres niveles.

Guarde la clave como variable de entorno. Cree GEMINI_API_KEY en un entorno de Apidog y úsela como {{GEMINI_API_KEY}} en el encabezado x-goog-api-key. Añada también THINKING_LEVEL.
Guarde una solicitud. Use POST /v1beta/models/gemini-3.8-flash:generateContent con su prompt dorado:

   {
     "generationConfig": {
       "thinkingConfig": {
         "thinkingLevel": "{{THINKING_LEVEL}}"
       }
     }
   }

Cree un escenario de tres pasos. Importe la solicitud tres veces y establezca THINKING_LEVEL en low, medium y high.
Asegure los campos variables. En cada paso, compruebe que el estado sea 200 y que exista usageMetadata.thoughtsTokenCount. En low, establezca un límite de tokens y latencia después de la primera ejecución.
Compare los niveles. Guarde el recuento de cada paso en una variable de postprocesamiento y compruebe que high razone al menos tanto como low. Una inversión puede indicar un cambio de modelo o de configuración.
Añada una prueba de compatibilidad. Envíe thinkingLevel: "minimal" y compruebe que la respuesta no sea 200.
Programe el escenario. Ejecútelo diariamente para detectar regresiones o cambios silenciosos antes de recibir una factura inesperada. Consulte cómo programar pruebas de API en Apidog.

Para respuestas en streaming, aplique el mismo escenario con SSE. La guía sobre cómo probar API de LLM que transmiten mediante SSE cubre la configuración. También puede descargar Apidog; el plan gratuito es suficiente para este escenario.

Preguntas frecuentes

¿El nivel cambia el precio por token?

No. Gemini 3.8 Flash cuesta $0.75 por millón de tokens de entrada y $3.75 por millón de tokens de salida durante el periodo introductorio, independientemente del nivel. El nivel cambia la cantidad de tokens de razonamiento que genera el modelo y que se facturan como salida. Consulte el desglose de precios de Gemini para conocer caché, lotes y el aumento del 1 de enero.

¿Puedo establecer un presupuesto exacto de tokens?

No en los modelos Gemini 3. thinking_budget fue reemplazado por thinking_level, y 3.8 Flash solo acepta low, medium y high. Si necesita un límite, aplíquelo en las pruebas, alertas y controles de enrutamiento.

¿Qué nivel usa la puntuación 59 de Artificial Analysis?

high. Artificial Analysis ejecutó el Intelligence Index en high para la puntuación principal. Publicó costos y tiempos para otros niveles, pero no sus puntuaciones del índice.

¿Debo bajar `temperature` para reducir el razonamiento?

No. Google recomienda mantener temperature en 1.0 para todos los modelos Gemini 3. Reducirla puede provocar bucles o degradar la salida. Use thinking_level para controlar la profundidad.

¿Qué hago si incluso `low` es demasiado lento o caro?

Permanezca en Gemini 3.7 Flash, que sigue siendo compatible sin fecha de obsolescencia, o migre la ruta a Flash-Lite.

Elija el nivel por ruta y mídalo

Gemini 3.8 Flash ofrece tres niveles, pero no un presupuesto exacto de tokens. Configure thinking_level explícitamente, convierta cualquier minimal restante en low y supervise usageMetadata.thoughtsTokenCount.

Las cifras de Artificial Analysis —$0.24, $0.41 y $0.58 por tarea— muestran la forma general de la curva. Un escenario de tres pasos en Apidog le dará los números reales de sus prompts antes de que el cambio de precios del 31 de diciembre vuelva aún más importante cada decisión de enrutamiento.

Llamada a funciones con Gemini 3.8 Flash: call_id, bucles iterativos de herramientas y cómo probarlos

Roobia — Thu, 03 Sep 2026 07:35:58 +0000

Gemini 3.8 Flash: llamadas iterativas a herramientas con la API de interacciones

Gemini 3.8 Flash se lanzó el 2 de septiembre de 2026. Google lo diseñó para «llamar a herramientas iterativamente»: en tareas complejas, realiza una llamada, verifica el resultado y hace otra si es necesario, en lugar de intentar adivinarlo todo de una vez. Esto beneficia a los agentes, pero puede romper ciclos de herramientas ajustados para Gemini 3.7 Flash. Los dos cambios más importantes son que cada resultado de función debe incluir call_id y name, y que la API de interacciones —no generateContent— es ahora la vía principal para ejecutar el ciclo.

Prueba Apidog hoy

Esta guía muestra el flujo completo de dos turnos, compara la API heredada de generateContent, explica por qué Gemini 3.8 Flash puede consumir más turnos y tokens, y termina con una prueba diaria que simula el backend de una herramienta y verifica el recorrido de call_id.

Todas las solicitudes utilizan HTTP y JSON planos, así que puede construirlas y depurarlas en Apidog antes de integrarlas en su aplicación.

Si necesita una introducción al modelo, consulte qué es Gemini 3.8 Flash.

Gemini 3.8 Flash de un vistazo

Elemento	Gemini 3.8 Flash
ID del modelo	`gemini-3.8-flash` — estable, sin sufijo de vista previa
API principal	API de interacciones (`POST /v1beta/interactions`); `generateContent` es heredada, pero totalmente compatible
Declaración de herramienta	`tools: [{"type": "function", "name", "description", "parameters"}]`
Llamada del modelo	Paso `function_call` con `id`, `name` y `arguments`
Resultado de la herramienta	`function_result` con `call_id` y `name` — ambos obligatorios — más `previous_interaction_id`
Razonamiento	`thinking_level`: `low`, `medium` — predeterminado — o `high`; `minimal` devuelve un error de validación
Puntuación de uso de herramientas	Tau3-Banking: 45 %, 12 puntos más que 3.7 Flash, según Artificial Analysis
Consumo	Aproximadamente 48.000 tokens de salida por tarea en el índice de Artificial Analysis, un 30 % más que 3.7 Flash
Precio	0,75 USD de entrada y 3,75 USD de salida por cada millón de tokens hasta el 31/12/2026; el razonamiento se factura como salida

Paso 1: declarar la herramienta

En la API de interacciones, una herramienta es un objeto plano con:

type: "function"
name
description
Un esquema JSON bajo parameters

La descripción debe ser específica. «Consultar el estado actual de envío de un pedido por su ID» ayuda al modelo a decidir cuándo llamar la herramienta; «ayudante de pedidos» es demasiado ambiguo.

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.8-flash",
    "input": "Where is order A1029 right now?",
    "generation_config": {"thinking_level": "low"},
    "tools": [{
      "type": "function",
      "name": "get_order_status",
      "description": "Look up the current shipping status of an order by its ID.",
      "parameters": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"]
      }
    }]
  }'

Dos opciones son deliberadas:

thinking_level es low porque una consulta sencilla no necesita el valor predeterminado medium. Consulte la guía de niveles de razonamiento para decidir cuándo aumentarlo.
No se especifica temperature. La guía de Gemini 3 de Google recomienda conservar el valor predeterminado 1.0, porque reducirlo puede provocar bucles dentro del ciclo de herramientas.

Paso 2: leer el paso `function_call`

La API de interacciones devuelve el ID de la interacción y una lista de pasos de ejecución: pensamientos del modelo, llamadas a herramientas y, finalmente, un paso model_output.

Cuando el modelo necesita una herramienta, la respuesta contiene un paso como este:

{
  "type": "function_call",
  "id": "call_8f2d...",
  "name": "get_order_status",
  "arguments": {"order_id": "A1029"}
}

Los tres campos son necesarios:

id es el identificador que debe enviar de vuelta como call_id.
name indica qué función debe ejecutar y también debe repetirse en la respuesta.
arguments ya está parseado como JSON. Valídelo contra sus propias reglas antes de ejecutar la operación. El modelo conoce el esquema, pero no sabe necesariamente que sus IDs de pedido deben tener cinco caracteres.

Guarde también el ID de la interacción que aparece en la parte superior de la respuesta. Lo necesitará como previous_interaction_id en el siguiente turno.

Paso 3: devolver `function_result` con `call_id` y `name`

Ejecute la función y envíe una segunda solicitud cuyo input sea un function_result. En Gemini 3.8 Flash, call_id y name son obligatorios:

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.8-flash",
    "previous_interaction_id": "<interaction id from step 2>",
    "input": [{
      "type": "function_result",
      "name": "get_order_status",
      "call_id": "call_8f2d...",
      "result": [{"type": "text", "text": "{\"status\":\"in_transit\",\"eta\":\"2026-09-05\"}"}]
    }]
  }'

Si omite cualquiera de los dos campos, la llamada falla. Este es uno de los errores más comunes al migrar ciclos escritos para modelos anteriores.

result es una lista de partes de contenido y la parte de texto contiene el JSON como cadena. Como previous_interaction_id apunta al turno anterior, el servidor ya conserva el prompt original, la declaración de la herramienta y el razonamiento del modelo.

La respuesta vuelve a ser una lista de pasos:

Si termina en model_output, el ciclo finalizó. El SDK expone el texto mediante interaction.output_text.
Si contiene otra function_call, vuelva a ejecutar los pasos 2 y 3.

En Python, el patrón es:

client.interactions.create(
    model="gemini-3.8-flash",
    input=...,
    ...
)

client.interactions.create(
    model="gemini-3.8-flash",
    previous_interaction_id=interaction.id,
    input=[function_result],
)

El tutorial de la API de Gemini 3.8 Flash cubre las claves, el streaming y la lectura del consumo de tokens.

Equivalente heredado con `generateContent`

La mayoría del código existente todavía llama a:

models/gemini-3.8-flash:generateContent

Google indica que esta API «sigue siendo totalmente compatible» y no tiene fecha de finalización. El vocabulario cambia, pero el contrato es el mismo:

Las herramientas se declaran bajo functionDeclarations.
El modelo responde con una parte functionCall.
La aplicación responde con una parte functionResponse.
El functionCall del modelo incluye un id.
Su functionResponse debe repetir ese id junto con name y response.

Es el mismo identificador que call_id en la API de interacciones, pero con otro nombre de campo. La documentación de llamada a funciones de Google especifica que tanto el ID como el nombre son obligatorios.

Hay dos diferencias prácticas:

generateContent no conserva estado. Debe reenviar el historial completo de contents en cada turno, incluida la llamada del modelo y cualquier firma de pensamiento devuelta.
El razonamiento se configura bajo generationConfig.thinkingConfig.thinkingLevel:

{
  "generationConfig": {
    "thinkingConfig": {
      "thinkingLevel": "low"
    }
  }
}

Los tokens de razonamiento aparecen como usageMetadata.thoughtsTokenCount y se facturan como tokens de salida.

Para un proyecto nuevo, prefiera la API de interacciones: el estado del lado del servidor evita errores causados por historiales reenviados sin una firma o un ID de llamada.

Por qué Gemini 3.8 Flash usa herramientas iterativamente

La publicación de lanzamiento de Google afirma que el modelo «trabaja más duro»: en tareas complejas ejecuta pasos de razonamiento adicionales, realiza llamadas iterativas y verifica su trabajo mediante pasos más pequeños. Google también advierte que puede utilizar más tokens en tareas largas y complejas.

Artificial Analysis midió estos efectos:

Unos 48.000 tokens de salida por tarea en su índice, un 30 % más que 3.7 Flash.
Coste aproximado por tarea de 0,58 USD en high, frente a 0,40 USD para 3.7 Flash con los mismos precios por token.
Coste aproximado de 0,41 USD en medium y 0,24 USD en low.
Tau3-Banking aumentó 12 puntos, hasta el 45 %.

La ventaja es una mejor capacidad de uso de herramientas. La desventaja es que un ciclo sin límites puede tardar más que con 3.7 Flash.

Cuatro controles para producción

Aplíquelos en este orden:

Límite de turnos en el arnés

Cuente los pasos function_call por tarea y deténgase al alcanzar un límite. Entre 6 y 10 turnos es un buen punto de partida para búsquedas; las tareas de codificación agéntica pueden necesitar más. Al alcanzar el límite, envíe un turno final sin herramientas o devuelva un error. El modelo no se limitará por sí solo.

thinking_level por ruta

low para búsquedas y herramientas de un solo salto.
medium para trabajo de varios pasos.
high cuando la verificación adicional lo justifique.
No use minimal: Gemini 3.8 Flash devuelve un error de validación.

Tiempo de espera en ambos niveles

Configure un timeout para cada solicitud a Gemini y otro timeout de pared para toda la tarea. Las ejecuciones high de Artificial Analysis promediaron 2,5 minutos por tarea, frente a 0,8 minutos en low.

Herramientas idempotentes

Un modelo iterativo puede reintentar una llamada. get_order_status debe poder ejecutarse dos veces sin efectos adversos. Las operaciones con efectos secundarios, como reembolsos o envíos, deben requerir confirmación explícita.

Si no puede asumir los turnos adicionales, consulte la guía de migración de Gemini 3.7 a 3.8 Flash para mantener 3.7 Flash detrás de un indicador de configuración.

Firmas de pensamiento, llamadas paralelas y salidas estructuradas

Firmas de pensamiento

Los modelos Gemini 3 adjuntan firmas a su razonamiento. Con el flujo almacenado predeterminado, previous_interaction_id las gestiona automáticamente.

Si usa store: false o generateContent, debe reenviar los bloques de pensamiento y sus firmas exactamente como fueron recibidos en cada tipo de parte. No los recorte, reordene ni vuelva a serializar: una firma es opaca y cualquier modificación la invalida.

Consulte la documentación de la API de interacciones para conocer las diferencias entre los modos almacenado y sin estado.

Llamadas paralelas

La respuesta es una lista y puede contener varios pasos function_call cuando el modelo necesita búsquedas independientes. Cada llamada tiene un ID único y los resultados pueden devolverse en cualquier orden.

Envíe un function_result por llamada dentro del mismo array input, haciendo coincidir cada resultado con su propio call_id:

[
  {
    "type": "function_result",
    "name": "get_order_status",
    "call_id": "call_1",
    "result": [{"type": "text", "text": "..."}]
  },
  {
    "type": "function_result",
    "name": "get_order_status",
    "call_id": "call_2",
    "result": [{"type": "text", "text": "..."}]
  }
]

No haga la correspondencia solo por name: dos llamadas a la misma función tienen dos call_id distintos.

Salidas estructuradas

Gemini 3.8 Flash admite salidas estructuradas y llamadas a funciones en el mismo modelo. Un patrón práctico es usar:

Herramientas para el ciclo de ejecución.
Un esquema JSON para la respuesta final.

Así, el model_output que cierra el ciclo es legible por máquina en lugar de ser prosa libre. Consulte la documentación de llamadas a funciones y salidas estructuradas.

No simule una salida estructurada declarando una herramienta ficticia y leyendo sus arguments: el patrón falla cuando el modelo decide que no necesita llamar ninguna herramienta.

Google también enumera el uso de computadoras —en vista previa— para Gemini 3.8 Flash. Para decidir cuándo una API estructurada es preferible a un agente que controla la pantalla, consulte uso de computadoras frente a APIs estructuradas.

Probar el ciclo de herramientas en Apidog

Un ciclo de herramientas tiene tres puntos críticos:

La declaración de la herramienta.
El recorrido de ida y vuelta del ID.
La respuesta final.

Puede probarlos en Apidog sin conectar el backend real.

1. Simule el backend

Defina GET /orders/{order_id} y active el servidor simulado. Use siempre esta respuesta:

{
  "status": "in_transit",
  "eta": "2026-09-05"
}

Una respuesta fija garantiza que cualquier cambio en la salida final provenga del modelo y no de la base de datos. En el entorno de pruebas, el arnés apunta a la URL simulada; en producción, al servicio real.

2. Encadene los dos turnos

Guarde GEMINI_API_KEY como variable de entorno y úsela en el encabezado:

{{GEMINI_API_KEY}}

Construya un escenario de tres pasos:

Paso A: haga POST /v1beta/interactions con el prompt y la declaración get_order_status. Extraiga el ID de interacción y los campos id, name y arguments.order_id del paso function_call.
Paso B: haga GET al endpoint simulado usando {{order_id}}. Este paso representa la ejecución de la función.
Paso C: envíe otro POST con function_result:
- call_id: {{call_id}}
- name: {{tool_name}}
- previous_interaction_id: {{interaction_id}}
- El cuerpo del paso B como parte de texto.

3. Añada aserciones

Verifique lo siguiente:

El paso A devuelve 200 y contiene un paso function_call cuyo name es get_order_status.
arguments.order_id es A1029.
El paso C devuelve 200 y termina en model_output, sin un segundo function_call.
El texto final contiene in_transit.
Si prueba también generateContent, establezca un límite para usageMetadata.thoughtsTokenCount según thinking_level.

Estas aserciones confirman que el modelo interpretó el prompt, respetó el esquema, aceptó call_id y name, y utilizó el resultado de la herramienta.

Programe el escenario para ejecutarlo diariamente. Las actualizaciones silenciosas pueden cambiar el comportamiento del modelo: un ciclo que terminaba en una ronda la semana pasada podría necesitar dos esta semana.

La guía de pruebas de APIs para agentes de IA profundiza en las aserciones de varios pasos. También puede descargar Apidog y construir el escenario con el nivel gratuito.

Preguntas frecuentes

¿Es obligatorio `call_id` en Gemini 3.8 Flash?

Sí. En la API de interacciones, cada function_result necesita call_id y name. En generateContent, cada functionResponse necesita el id y el name de la llamada. El código antiguo que enviaba solo el nombre falla con los modelos Gemini 3.

¿Por qué mi ciclo ejecuta más turnos en 3.8 Flash que en 3.7?

Es intencional. Google indica que Gemini 3.8 Flash llama a herramientas de forma iterativa y puede utilizar más tokens en tareas largas y complejas. Establezca un límite de turnos y reduzca thinking_level cuando sea apropiado.

¿Todavía puedo usar `generateContent` para llamadas a funciones?

Sí. Google la considera una API heredada, pero sigue siendo totalmente compatible y no tiene fecha de finalización. Debe conservar usted mismo el historial, incluidas las firmas de pensamiento. El ID de llamada —id en esta API— y name siguen siendo obligatorios.

¿Funciona `thinking_level: "minimal"` con herramientas?

No. Gemini 3.8 Flash devuelve un error de validación. Use low.

¿Cuánto cuesta una tarea intensiva en herramientas?

Hasta el 31 de diciembre de 2026, el precio es de 0,75 USD por millón de tokens de entrada y 3,75 USD por millón de tokens de salida. El razonamiento se factura como salida.

Artificial Analysis midió aproximadamente:

0,58 USD por tarea en high.
0,41 USD en medium.
0,24 USD en low.

Sus tareas pueden diferir. Registre los recuentos de tokens y mida el coste real.

Despliegue el ciclo con límites

El contrato esencial es:

Declare la herramienta.
Lea el paso function_call.
Devuelva function_result con call_id y name mediante previous_interaction_id.

Lo que cambia con Gemini 3.8 Flash es la disposición del modelo a iterar. Antes de pasar a producción, añada un límite de turnos, seleccione thinking_level por ruta y configure timeouts. Simule el backend, encadene los dos turnos, afirme el recorrido del ID y programe la prueba diaria.

Consulte las Novedades de Gemini 3.8 Flash para las notas de migración y la documentación de llamadas a funciones para el contrato completo.

Cómo usar la API Gemini 3.8 Flash: API de interacciones, niveles de pensamiento y tu primera llamada en Apidog

Roobia — Thu, 03 Sep 2026 07:34:16 +0000

Gemini 3.8 Flash: guía práctica para integrarlo con la API

Google lanzó Gemini 3.8 Flash el 2 de septiembre de 2026. Su ID de API es gemini-3.8-flash, sin sufijo de vista previa. Mantiene el precio introductorio de Gemini 3.7 Flash —$0.75 por millón de tokens de entrada y $3.75 por millón de tokens de salida— hasta el 31 de diciembre de 2026. Google lo describe como un modelo que “trabaja más duro”: ejecuta más pasos de razonamiento y utiliza herramientas con mayor frecuencia en tareas complejas, algo que se refleja directamente en el consumo de tokens.

Prueba Apidog hoy

Esta guía muestra cómo obtener una clave en AI Studio, realizar una primera solicitud con la API de Interacciones, utilizar el endpoint heredado generateContent, configurar thinking_level, activar streaming y leer thoughtsTokenCount para controlar el costo del razonamiento. Todas las llamadas usan HTTP y JSON, así que puedes crearlas y validarlas en Apidog antes de integrarlas en tu aplicación.

Para conocer la descripción general, los benchmarks y los cambios del modelo, consulta qué es Gemini 3.8 Flash y la publicación de lanzamiento de Google.

Gemini 3.8 Flash de un vistazo

Elemento	Valor
ID del modelo	`gemini-3.8-flash`
Endpoint principal	`POST /v1beta/interactions`
Endpoint heredado	`POST /v1beta/models/gemini-3.8-flash:generateContent`
Encabezado de autenticación	`x-goog-api-key`
Contexto / salida	1,048,576 tokens de entrada / 65,536 tokens de salida
Entradas	Texto, imagen, video, audio y PDF; solo genera texto
Niveles de pensamiento	`low`, `medium` (predeterminado) y `high`; `minimal` devuelve un error
Precio introductorio hasta el 31 de diciembre de 2026	$0.75 / $3.75 por 1 millón de tokens
Precio desde el 1 de enero de 2027	$1.50 / $7.50 por 1 millón de tokens

Dos detalles son importantes:

El nivel predeterminado es medium, no high como en Gemini 3 Pro.
Los tokens de pensamiento se facturan como tokens de salida. Consulta el desglose de precios y la página oficial de precios antes de definir la configuración de producción.

Paso 1: Obtén una clave de API en AI Studio

Abre Google AI Studio, inicia sesión y crea una clave desde la página de claves.

La clave funciona con el nivel gratuito, que tiene límites de velocidad. Google advierte que los datos del nivel gratuito se “utilizan para mejorar nuestros productos”. Para obtener límites de producción del Nivel 1, vincula una cuenta de facturación.

Guarda la clave como variable de entorno:

export GEMINI_API_KEY="AIza..."

El SDK oficial de Python lee GEMINI_API_KEY automáticamente, por lo que genai.Client() no necesita argumentos. Instálalo con:

pip install google-genai

Paso 2: Realiza tu primera llamada con la API de Interacciones

Google considera la API de Interacciones la forma principal de llamar a los modelos Gemini 3.x.

La solicitud incluye el modelo, una entrada y una configuración opcional de generación. En esta API, thinking_level se encuentra dentro de generation_config.

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.8-flash",
    "input": "Explain HTTP caching in 3 sentences.",
    "generation_config": {"thinking_level": "medium"}
  }'

La respuesta contiene una lista de pasos de ejecución, no un único mensaje. Los pensamientos y las llamadas a herramientas aparecen como pasos; el último paso suele ser model_output.

El SDK de Python aplana esta estructura:

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Explain HTTP caching in 3 sentences.",
    generation_config={"thinking_level": "medium"},
)

print(interaction.output_text)

No establezcas temperature, top_p ni top_k. La guía de Google para Gemini 3 recomienda mantener la temperatura predeterminada de 1.0, porque reducirla “puede causar bucles o un rendimiento degradado”. Si reutilizas una configuración de un modelo anterior, elimina esos parámetros primero.

Paso 3: Mantén conversaciones multi-turno

La API de Interacciones conserva el estado de la conversación en el servidor por defecto. Para continuar una conversación, envía el ID de la interacción anterior mediante previous_interaction_id:

follow_up = client.interactions.create(
    model="gemini-3.8-flash",
    input="Now give one example of a Cache-Control header.",
    previous_interaction_id=interaction.id,
)

print(follow_up.output_text)

Si tus requisitos de cumplimiento prohíben el almacenamiento del lado del servidor, utiliza store: false. En ese caso, tendrás que gestionar el estado manualmente y reenviar los bloques y las firmas de pensamiento exactamente como los recibiste.

Este mismo requisito es importante cuando utilizas herramientas. Consulta la guía de llamada de funciones para Gemini 3.8 Flash.

Paso 4: Utiliza el endpoint heredado `generateContent`

La mayoría del código Gemini en producción todavía utiliza generateContent. Google lo considera heredado, pero sigue siendo totalmente compatible y no tiene una fecha de finalización publicada.

La forma de la solicitud es igual que en la guía de la API de Gemini 3.7 Flash, aunque thinking_level se configura en una ubicación diferente.

En generateContent, el nivel se encuentra dentro de generationConfig.thinkingConfig.thinkingLevel:

curl -X POST "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:generateContent" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{"parts": [{"text": "Explain HTTP caching in 3 sentences."}]}],
    "generationConfig": {"thinkingConfig": {"thinkingLevel": "low"}}
  }'

En Python:

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="gemini-3.8-flash",
    contents="Explain HTTP caching in 3 sentences.",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_level="low")
    ),
)

print(response.text)

Si tu configuración anterior utilizaba thinking_budget como entero, reemplázalo por el enumerado de cadena. candidate_count también desapareció en Gemini 3 y versiones posteriores. La guía de migración de Gemini 3.7 a 3.8 Flash incluye ejemplos JSON antes y después.

Diferencias entre ambas APIs

Preocupación	API de Interacciones	`generateContent` heredado
Nivel de pensamiento	`generation_config.thinking_level`	`generationConfig.thinkingConfig.thinkingLevel`
Estado de conversación	`previous_interaction_id` en el servidor	Reenviar el array completo de `contents`
Resultado de herramienta	`function_result` con `call_id` y `name`	`functionResponse` con `id` y `name`
Texto final	Paso `model_output`; `output_text` en el SDK	`candidates[0].content.parts[].text`
Firmas de pensamiento	Gestionarlas manualmente cuando `store: false`	Devolver cada parte exactamente como se recibió

Paso 5: Activa el streaming y controla el costo

Para interfaces de chat, utiliza streamGenerateContent y añade ?alt=sse para recibir eventos enviados por el servidor:

curl -N "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:streamGenerateContent?alt=sse" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"List three HTTP caching headers."}]}]}'

Con o sin streaming, las respuestas de generateContent terminan con usageMetadata. Regístralo en cada llamada:

"usageMetadata": {
  "promptTokenCount": 12,
  "candidatesTokenCount": 84,
  "thoughtsTokenCount": 310,
  "totalTokenCount": 406
}

El campo clave en Gemini 3.8 Flash es thoughtsTokenCount. Durante el período introductorio, estos tokens se facturan como tokens de salida a $3.75 por millón. Google también afirma que el modelo “podría usar más tokens para maximizar el rendimiento, especialmente en niveles de esfuerzo más altos”.

Artificial Analysis midió aproximadamente 48.000 tokens de salida por tarea en high, un 30 % más que Gemini 3.7 Flash. Con los mismos precios por token, el costo por tarea aumentó de $0.40 a $0-3-8-flash-thinking-levels?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) ayuda a convertir estos datos en una estrategia por ruta.

Para inspeccionar el razonamiento resumido, añade includeThoughts: true dentro de thinkingConfig:

{
  "thinkingConfig": {
    "thinkingLevel": "medium",
    "includeThoughts": true
  }
}

Los resúmenes aparecen como partes con "thought": true. Exclúyelos al ensamblar la respuesta visible para el usuario.

Errores frecuentes

`thinking_level: "minimal"` devuelve `400 INVALID_ARGUMENT`

Gemini 3.8 Flash solo admite low, medium y high. Enviar minimal produce:

Thinking level MINIMAL is not supported for this model.
Please retry with other thinking level.

La solución es cambiar minimal por low. Las configuraciones antiguas de Gemini 3.x y los fragmentos copiados son la causa más habitual.

`429` significa que alcanzaste el límite

Un 429 normalmente indica que superaste el límite de velocidad de tu nivel, no que la solicitud sea inválida.

Según la página de límites de velocidad:

El nivel gratuito tiene límites de velocidad.
El Nivel 1 se habilita al vincular una cuenta de facturación.
El Nivel 2 requiere $100 de gasto y tres días.
El Nivel 3 requiere $1.000 de gasto y 30 días.

Las solicitudes por minuto y los tokens por minuto disponibles para cada modelo se muestran en AI Studio para tu cuenta. Ante un 429, aplica backoff y reintenta. Si los errores continúan con poco volumen, considera actualizar de nivel.

Para trabajos fuera de línea, la API Batch ofrece un descuento del 50 %: $0.375 por millón de tokens de entrada y $1.875 por millón de tokens de salida durante el período introductorio. Sus límites de tokens en cola son:

Nivel 1: 3 millones
Nivel 2: 400 millones
Nivel 3: 1.000 millones

Consulta la guía del modo por lotes de Gemini para conocer el formato de la solicitud.

Falta `call_id` en el resultado de una función

Cuando utilizas herramientas:

Cada function_result de Interacciones debe incluir call_id y name.
Cada functionResponse heredada debe incluir el id coincidente y name.

Omitir cualquiera de estos campos hace que falle el turno.

Prueba ambos endpoints en Apidog

Cuando las solicitudes funcionen desde la terminal, guárdalas en un proyecto compartido de Apidog para que todo el equipo pueda ejecutarlas.

1. Mantén la clave fuera de la solicitud

Añade GEMINI_API_KEY como variable de entorno y referencia la variable en el encabezado:

x-goog-[REDACTED CREDENTIAL]_KEY}}

La solicitud guardada no contendrá el secreto, y podrás cambiar entre una clave gratuita y una facturable modificando el entorno.

2. Verifica el estado y los tokens

Añade una aserción para comprobar que el estado sea 200 y otra para verificar que:

usageMetadata.thoughtsTokenCount

se mantenga por debajo del límite que definas para cada prompt. Ese límite funciona como alarma de regresión de costos: si cambia el prompt o el modelo consume más tokens de pensamiento, la prueba fallará antes de que aumente la factura.

La guía de pruebas SSE cubre la variante de streaming, que Apidog muestra como un flujo de eventos fusionado.

3. Compara los tres niveles

Duplica la solicitud para low, medium y high. Compara thoughtsTokenCount y el tiempo de respuesta para obtener datos reales de tus prompts, en lugar de depender de promedios de benchmarks.

4. Programa las pruebas

Convierte las solicitudes en un escenario y ejecútalo periódicamente. Así, un cambio en los límites, una modificación de validación —como la eliminación de minimal— o un aumento inesperado de tokens aparecerá en un informe antes de llegar a producción.

Consulta Cómo programar pruebas de API en Apidog.

Apidog no ejecuta el modelo ni reemplaza el SDK. Proporciona una versión guardada, compartible y verificable de las llamadas HTTP: una capa que muchos equipos no crean hasta que algo falla.

Preguntas frecuentes

¿Qué endpoint deberían usar los proyectos nuevos?

La API de Interacciones. Google considera generateContent heredado, aunque sigue siendo totalmente compatible. Las nuevas funciones llegan primero a Interacciones y el estado del servidor simplifica el código multi-turno.

Mantén generateContent en los servicios existentes hasta que tengas una razón concreta para migrar.

¿Necesito una cuenta de pago?

No. Una clave gratuita de AI Studio funciona, aunque tiene límites de velocidad y está sujeta a los términos de uso de datos de Google. La guía para usar Gemini 3.8 Flash gratis explica qué incluye y qué no incluye el nivel gratuito. La aplicación Gemini requiere un plan AI Pro o Ultra para usar Gemini 3.8 Flash.

¿Gemini 3.8 Flash es más lento que Gemini 3.7 Flash?

Por token, no. Logan Kilpatrick, de Google, indicó que la velocidad es aproximadamente la misma, y Artificial Analysis midió cerca de 300 tokens de salida por segundo.

Por tarea, high tarda más porque genera más tokens: 2,5 minutos frente a 2,2 minutos en sus pruebas.

¿Puedo seguir utilizando Gemini 3.7 Flash?

Sí. Google afirma que Gemini 3.7 Flash sigue siendo totalmente compatible y no ha publicado una fecha de desuso. Si el consumo adicional de tokens de Gemini 3.8 Flash no mejora tus resultados, mantener el modelo actual sigue siendo una opción válida.

¿Gemini 3.8 Flash admite Live API o generación de imágenes?

No. Solo genera texto. La generación de audio, la generación de imágenes y Live API no son compatibles con este modelo.

Próximos pasos

Ya tienes dos rutas de llamada funcionales, un patrón multi-turno y una forma de controlar el consumo de tokens.

A partir de aquí:

Integra herramientas con la guía de llamada de funciones.
Define los niveles de pensamiento por ruta con la guía de niveles de pensamiento.
Compara las ventajas y desventajas en la comparación entre Gemini 3.8 y 3.7 Flash.
Mantén el escenario de Apidog activo para detectar las variaciones de costo como pruebas fallidas.

¿Cómo usar Gemini 3.8 Flash gratis?

Roobia — Thu, 03 Sep 2026 05:20:23 +0000

Cómo usar Gemini 3.8 Flash gratis: guía práctica con API

Gemini 3.8 Flash se lanzó el 2 de septiembre de 2026. A diferencia de muchos lanzamientos pioneros de este año, ofrece un camino gratuito real: puedes probarlo sin costo en Google AI Studio y llamarlo desde el nivel gratuito de la API de Gemini con una clave que se crea en aproximadamente un minuto. Google lo presenta como “nuestro modelo Flash más inteligente” y el nivel gratuito utiliza el mismo ID gemini-3.8-flash que los clientes de pago, no una variante reducida.

Prueba Apidog hoy

Hay tres advertencias importantes:

El nivel gratuito tiene límites de tasa.
Google utiliza los datos del nivel gratuito para mejorar sus productos.
La aplicación Gemini no incluye 3.8 Flash en su plan gratuito; necesitas Google AI Pro o Ultra.

Para conocer las especificaciones completas, consulta qué es Gemini 3.8 Flash. Si quieres ejecutar una solicitud ahora, sigue estos pasos.

Acceso gratuito de un vistazo

Superficie	Costo	¿Gemini 3.8 Flash incluido?	Advertencia
Google AI Studio	$0	Sí	Límites de tasa; los datos se utilizan para mejorar productos
Nivel gratuito de la API de Gemini	$0	Sí	Mismos límites publicados en AI Studio
Aplicación Gemini, plan gratuito	$0	No	3.8 Flash requiere Google AI Pro o Ultra
Modo IA en la Búsqueda de Google	$0	Sí, para consumidores	Sin API ni control del nivel de pensamiento
Gemini en Hojas de cálculo de Google	Depende del plan	Sí, para consumidores	Sin API
Contextualización de Búsqueda de Google	5.000 solicitudes/mes gratis	Compartida entre Gemini 3.x	Después, $14 por cada 1.000 solicitudes
API por lotes	50 % de descuento sobre las tarifas de pago	Sí	No es gratuita, pero es la opción de pago más económica
Gemini 3.8 Flash Cyber	No se vende	No	Solo Programa Fairwind; no existe API pública

Paso 1: selecciona `gemini-3.8-flash` en AI Studio

Abre Google AI Studio e inicia sesión. No necesitas una cuenta de facturación ni una tarjeta de crédito.

En el selector de modelos, elige gemini-3.8-flash. Es el ID estable, sin sufijo de vista previa. La configuración de ejecución ofrece tres niveles de pensamiento:

low
medium, el valor predeterminado
high

El modelo no admite un nivel mínimo. Si lo envías mediante la API, recibirás un error de validación en lugar de una alternativa silenciosa. Consulta la guía de niveles de pensamiento para comparar el costo en tokens y tiempo.

Para empezar:

Mantén la temperatura en su valor predeterminado de 1.0. Google advierte que reducirla puede provocar bucles o respuestas degradadas.
Usa low mientras experimentas.

Gemini 3.8 Flash está diseñado para trabajar más en tareas complejas: puede tomar pasos de razonamiento más pequeños y llamar a herramientas de forma iterativa. Google también indica que puede consumir más tokens en tareas complejas y prolongadas. Como los límites se miden en tokens por minuto, ese consumo agota la cuota más rápido que en 3.7 Flash. low mantiene los experimentos económicos.

Paso 2: crea una clave API gratuita

En AI Studio, abre la página de claves API y crea una clave en un proyecto nuevo o existente. Es gratuita y funciona de inmediato con el nivel gratuito. La página de precios de Gemini muestra la entrada y salida de 3.8 Flash como “Gratuitas” en ese nivel.

Si es tu primera clave, consulta esta guía para crear una clave API de Gemini.

Guárdala como variable de entorno y no la incluyas en el código ni en el historial del shell:

export GEMINI_API_KEY="paste-your-key-here"

Trátala como una contraseña. Aunque una clave filtrada del nivel gratuito no puede generar una factura, sí puede consumir tu cuota diaria antes de que la utilices.

Paso 3: realiza tu primera solicitud

Gemini 3.x funciona principalmente con la API de Interactions. Puedes hacer una solicitud sin instalar un SDK:

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H 'Content-Type: application/json' \
  -d '{"model":"gemini-3.8-flash","input":"Explain HTTP caching in 3 sentences.","generation_config":{"thinking_level":"low"}}'

La respuesta contiene una lista de pasos de ejecución —pensamientos del modelo y llamadas a herramientas, si las hubiera— que termina en un paso model_output con el texto generado.

Si tu código utiliza generateContent, todavía funciona. Google lo considera heredado, pero “totalmente compatible” y sin fecha de finalización anunciada. En ese endpoint, el nivel se configura mediante:

generationConfig.thinkingConfig.thinkingLevel

La guía de la API de Gemini 3.8 Flash incluye ambas formas, ejemplos en Python y conversaciones multi-turno con previous_interaction_id.

Si recibes un error 429, alcanzaste el límite de tasa del nivel gratuito. Espera o pasa al Nivel 1.

Qué cuesta realmente el nivel gratuito

En dólares: nada. En la práctica, pagas de otras tres formas.

1. Límites de tasa

El nivel gratuito limita, por modelo:

Solicitudes por minuto.
Tokens por minuto.
Solicitudes por día.

Google publica las cifras exactas en la página de límites de tasa de AI Studio, no siempre en la documentación. Además, pueden cambiar sin una entrada en el registro de cambios. Consulta esa página para conocer los límites actuales de tu proyecto y revisa cómo se acumulan los niveles en el documento de límites de tasa.

2. Tus datos

Google afirma que las solicitudes y respuestas del nivel gratuito se utilizan para mejorar sus productos. Esto puede ser aceptable para una consulta de referencia o una aplicación de prueba, pero no para:

Registros de clientes.
Código fuente no publicado.
Información protegida por un acuerdo de confidencialidad (NDA).

Los niveles de pago tienen condiciones diferentes. Si necesitas privacidad, vincula la facturación antes de enviar datos sensibles.

3. Consumo de tokens

Artificial Analysis midió 3.8 Flash en el nivel high con aproximadamente 48.000 tokens de salida por tarea, un 30 % más que 3.7 Flash. Los tokens de pensamiento cuentan para los mismos límites de tokens por minuto que la salida visible.

Por eso conviene usar low o medium hasta que necesites más margen.

La aplicación Gemini no es el camino gratuito

La aplicación Gemini ofrece 3.8 Flash a suscriptores de Google AI Pro y Ultra. El plan gratuito de la aplicación no lo incluye. Si ves un modelo Flash sin suscripción, no significa que sea 3.8 Flash.

Las superficies de consumo donde puedes usarlo sin un cargo adicional son:

Modo IA en la Búsqueda de Google.
Gemini en Hojas de cálculo de Google.

Ambas sirven para leer respuestas, pero no ofrecen control sobre el nivel de pensamiento, recuento de tokens ni API. Para desarrollo, AI Studio y el nivel gratuito de la API son las opciones adecuadas.

Contextualización gratuita: 5.000 búsquedas al mes

La contextualización de Búsqueda de Google permite incorporar resultados web actuales en la respuesta del modelo. Incluye 5.000 solicitudes gratuitas al mes compartidas entre todos los modelos Gemini 3.x.

Después, el precio es de $14 por cada 1.000 solicitudes. La cuota es mensual y compartida: las solicitudes contextualizadas de Gemini 3 Pro y Gemini 3.8 Flash consumen el mismo grupo de 5.000.

Es una asignación útil para prototipos con datos recientes, pero una función de producción necesita presupuesto propio.

Cuando se agota lo gratuito: opciones de pago

Un error 429 durante una demostración o alcanzar el límite diario indica que necesitas más capacidad. Estas son las opciones, de menor a mayor costo:

1. Vincula la facturación para obtener el Nivel 1

Al vincular la facturación al proyecto en AI Studio:

Aumentan los límites de tasa.
Se establece un tope de gasto de $250.
No necesitas gastar dinero para desbloquear el Nivel 1.

El Nivel 2 se habilita después de gastar $100 y esperar tres días, con un tope de $2.000. El Nivel 3 requiere $1.000 de gasto y 30 días.

2. Usa las tarifas de introducción

Hasta el 31 de diciembre de 2026, Gemini 3.8 Flash cuesta:

$0,75 por millón de tokens de entrada.
$3,75 por millón de tokens de salida.

Los tokens de pensamiento se facturan como salida. Desde el 1 de enero de 2027, las tarifas se duplican a $1,50 y $7,50.

1.000 solicitudes con 2.000 tokens de entrada y 500 de salida cada una cuestan aproximadamente $3,38 con las tarifas de introducción. El desglose de precios de Gemini 3.8 Flash explica el cálculo por tarea y por qué un precio menor por token no siempre significa una tarea más barata.

3. Procesa por lotes lo que pueda esperar

La API por lotes reduce a la mitad las tarifas:

$0,375 por millón de tokens de entrada.
$1,875 por millón de tokens de salida.

Las mismas 1.000 solicitudes cuestan aproximadamente $1,69. Las cuentas de Nivel 1 pueden mantener hasta 3 millones de tokens en cola.

Las evaluaciones, cargas históricas (backfills) y trabajos nocturnos son buenos candidatos. Consulta la guía del modo por lotes de Gemini.

4. Almacena en caché el prefijo estable

El almacenamiento en caché de contexto cuesta $0,075 por millón de tokens en caché con la tarifa de introducción: una décima parte del costo de enviar entrada nueva.

Empieza por un prompt de sistema largo o un documento que reenvías en cada turno.

Lo que no obtendrás gratis

La aplicación Gemini: requiere Google AI Pro o Ultra.
Privacidad: los datos del nivel gratuito se utilizan para mejorar los productos de Google y no hay un interruptor para desactivarlo.
Margen de capacidad: los límites están publicados en la página de límites de tasa y no son generosos. El nivel gratuito sirve para evaluación y herramientas pequeñas, no para un lanzamiento.
Gemini 3.8 Flash Cyber: está restringido al Programa Fairwind para gobiernos, operadores de infraestructura y mantenedores de software. No tiene API pública, precio público ni opción de autoalojamiento.
API en vivo, generación de imágenes y generación de audio: 3.8 Flash no admite estas funciones en ningún nivel. Acepta texto, imagen, vídeo, audio y PDF como entrada, pero solo genera texto.
Un nivel ilimitado: los sitios que prometen acceso ilimitado probablemente usan la clave de otra persona o sirven un modelo diferente. Consulta la guía para detectar acceso gratuito e ilimitado falso a la API de Gemini. La estrategia de nivel gratuito utilizada con Gemini 3.6 Flash también aplica aquí.

Haz que la cuota gratuita rinda más con Apidog

La cuota gratuita recompensa una configuración disciplinada. Cada solicitud reescrita manualmente, cada 429 accidental y cada ejecución innecesaria con pensamiento high consume cuota que no recuperarás.

En Apidog:

Guarda GEMINI_API_KEY como variable de entorno para que nunca aparezca en el cuerpo de la solicitud ni en una colección compartida.
Guarda la solicitud de Interactions y la solicitud heredada generateContent con nombres.
Define como variables el prompt, el modelo y thinking_level.
Cambia el nivel de pensamiento modificando una variable, no el JSON.
Añade una aserción sobre el código de estado para que un 429 aparezca como prueba fallida.
En el endpoint heredado, comprueba usageMetadata.thoughtsTokenCount para saber cuánta cuota consumió el razonamiento.
Programa una prueba de humo diaria con nivel low.

Puedes descargar Apidog y consultar cómo programar pruebas de API en Apidog.

Preguntas frecuentes

¿Gemini 3.8 Flash es gratuito?

Sí, mediante Google AI Studio y el nivel gratuito de la API de Gemini, con límites de tasa y uso de tus datos para mejorar los productos de Google. Es el mismo modelo gemini-3.8-flash disponible en los niveles de pago.

¿Puedo usar Gemini 3.8 Flash gratis en la aplicación Gemini?

No. La aplicación ofrece 3.8 Flash a suscriptores de Google AI Pro y Ultra. El Modo IA en la Búsqueda de Google y Gemini en Hojas de cálculo son las superficies de consumo disponibles sin suscripción.

¿Cuáles son los límites de tasa?

Google los publica por modelo en la página de límites de tasa de AI Studio, no necesariamente en la documentación, y pueden cambiar. Consulta la página para tu proyecto. Si necesitas más capacidad, vincular la facturación te mueve al Nivel 1 sin necesidad de gastar.

¿El nivel gratuito incluye el pensamiento?

Sí. low, medium y high funcionan en el nivel gratuito; medium es el predeterminado. minimal devuelve un error en 3.8 Flash. Como los tokens de pensamiento cuentan para la cuota, low suele ser la mejor opción para empezar.

¿Gemini 3.8 Flash Cyber es gratuito?

No está disponible fuera del Programa Fairwind. Los desarrolladores habituales pueden usar 3.8 Flash y ejecutar sus propias pruebas de seguridad de API contra él.

Empieza gratis y decide después

El nivel gratuito es un entorno de evaluación real para Gemini 3.8 Flash. Crea una clave, usa low al principio, mantén los datos sensibles fuera del nivel gratuito y consulta los límites actuales en lugar de adivinarlos.

Cuando los errores 429 empiecen a costarte tiempo, vincula la facturación para obtener el Nivel 1 y usa procesamiento por lotes para los trabajos asíncronos. Hasta diciembre, $0,375 por millón de tokens de entrada puede costar menos que el café que tomaste esperando a que se restableciera la cuota.

Cómo usar la API Gemini Omni 1.1 Flash

Roobia — Thu, 03 Sep 2026 05:15:33 +0000

Llamas a Gemini Omni 1.1 Flash con el ID de modelo gemini-omni-1.1-flash mediante la API de Interacciones de Google, no mediante el endpoint generateContent de los modelos de texto. Si copias una solicitud de texto de Gemini y solo cambias el nombre del modelo, obtendrás un error 404.

Prueba Apidog hoy

Esta guía te lleva desde una terminal vacía hasta una solicitud probada de generación de video: crearás una clave, harás llamadas con curl y Python, revisarás los parámetros disponibles, gestionarás respuestas grandes y guardarás todo como una prueba repetible.

El modelo alcanzó la disponibilidad general (GA) el 27 de agosto de 2026. Consulta las novedades de Gemini Omni 1.1 Flash para conocer lo que se lanzó con él.

Requisitos

Una cuenta de Google para iniciar sesión en AI Studio.
Una clave de API de Gemini de Google AI Studio.
Facturación habilitada. Omni no tiene nivel gratuito, a diferencia de la opción gratuita para los modelos de texto. La primera solicitud tiene coste.
Una herramienta para enviar solicitudes HTTP: curl, el SDK de Python o un cliente de API.

Guarda la clave en una variable de entorno, no en el código fuente:

export GEMINI_API_KEY="your_key_here"

Los SDK oficiales leen esta variable automáticamente y mantienen el secreto fuera del repositorio.

Primera solicitud de generación de video

El endpoint es POST /v1beta/interactions:

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions?key=$GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-omni-1.1-flash",
    "input": "A marble rolling fast on a chain reaction style track, continuous smooth shot."
  }'

La solicitud mínima solo necesita model e input. La respuesta incluye el video generado como base64 en output_video.data.

Instala el SDK de Python con pip install google-genai:

import base64
from google import genai

client = genai.Client()  # reads GEMINI_API_KEY from the environment

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input="A marble rolling fast on a chain reaction style track, continuous smooth shot.",
)

with open("marble.mp4", "wb") as f:
    f.write(base64.b64decode(interaction.output_video.data))

En JavaScript, usa @google/genai:

import { GoogleGenAI } from '@google/genai';
import * as fs from 'fs';

const ai = new GoogleGenAI({});

const interaction = await ai.interactions.create({
  model: 'gemini-omni-1.1-flash',
  input: 'A marble rolling fast on a chain reaction style track, continuous smooth shot.',
});

if (interaction.output_video?.data) {
  fs.writeFileSync('marble.mp4', Buffer.from(interaction.output_video.data, 'base64'));
}

La generación puede tardar varios minutos. La latencia depende de la duración, la resolución y la carga de la API, así que configura un tiempo de espera generoso.

Controlar resolución y relación de aspecto

Configura el formato de salida mediante response_format:

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input="A drone shot of a mountain landscape at sunrise.",
    response_format={
        "type": "video",
        "aspect_ratio": "16:9",
        "resolution": "1080p",
    },
)

Campo	Valores	Predeterminado
`type`	`video`	`video`
`aspect_ratio`	`16:9`, `9:16`	`16:9`
`resolution`	`360p`, `720p`, `1080p`, `4k`	`720p`
`delivery`	base64 en línea, `uri`	en línea

Usa 360p para los borradores: puede generar resultados hasta un 60 % más rápido que 720p y cuesta un tercio. Después, vuelve a renderizar el prompt elegido con mayor resolución. 1080p y 4k son escalados de los fotogramas generados, no resoluciones nativas. Consulta el desglose de precios para conocer el coste por segundo.

Parámetros no compatibles

Para evitar errores de implementación, Omni no admite:

Instrucciones del sistema
temperature
top_p
Secuencias de parada
Un campo de prompt negativo

Si necesitas excluir algo de una toma, incluye la instrucción directamente en el prompt. La documentación usa este enfoque: “usando el dibujo solo como guía para el movimiento, no muestres el dibujo en el video final”.

Imágenes, fotogramas clave y referencias

Pasa una lista en input cuando incluyas medios. Para convertir una imagen en video:

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input=[
        {"type": "image", "data": base64_image, "mime_type": "image/jpeg"},
        {"type": "text", "text": "turn this into realistic footage, using the drawing only as a guide for movement, do not show the drawing in the final video"},
    ],
)

Si envías dos imágenes, la primera se usa como fotograma inicial y la segunda como fotograma final. El modelo genera el movimiento entre ambas:

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input=[
        {"type": "image", "data": first_frame_b64, "mime_type": "image/jpeg"},
        {"type": "image", "data": last_frame_b64, "mime_type": "image/jpeg"},
        {"type": "text", "text": "A smooth cinematic transition from a lush green forest at sunrise to a snowy forest under a starry night sky."},
    ],
)

Las referencias de video funcionan de forma similar mediante la API de Archivos, con un límite de tres clips de tres segundos cada uno. El audio se ignora; el modelo usa los clips para interpretar el movimiento y la apariencia.

Edición conversacional de varios turnos

Omni permite generar un video y editarlo usando el ID de la interacción anterior:

res1 = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input="A woman playing violin outdoors.",
)

res2 = client.interactions.create(
    model="gemini-omni-1.1-flash",
    previous_interaction_id=res1.id,
    input="Make the violin invisible.",
)

No necesitas volver a subir el video ni describir de nuevo la escena. El mismo mecanismo permite extender escenas; consulta la guía para extender videos hasta 40 segundos.

Gestionar videos de más de 4 MB

Los videos de más de 4 MB se devuelven como una URI, no como base64 en línea. Además, el archivo debe terminar de procesarse antes de descargarse. Este es un error habitual con 1080p: el código busca output_video.data, no encuentra datos y registra un fallo silencioso.

Solicita explícitamente la entrega mediante URI y sondea el estado:

import time
from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input="A beautiful sunset.",
    response_format={"type": "video", "delivery": "uri"},
)

video_output = interaction.output_video
file_name = video_output.uri.split("/")[-1]

while True:
    f_info = client.files.get(name=f"files/{file_name}")
    if f_info.state.name == "ACTIVE":
        break
    if f_info.state.name == "FAILED":
        raise RuntimeError("Generation failed.")
    time.sleep(5)

video_bytes = client.files.download(file=video_output.uri)
with open("output.mp4", "wb") as f:
    f.write(video_bytes)

Diseña el manejador para aceptar desde el principio las dos formas de respuesta: output_video.data y output_video.uri. La resolución determina cuál recibirás.

Probar la solicitud en Apidog

Una vez que la llamada funciona, necesitas controlar un endpoint costoso, lento y no determinista. El historial de la shell no basta para detectar cambios de comportamiento.

Configúralo una vez en Apidog:

Crea un proyecto y un entorno. Define GEMINI_API_KEY y MODEL_ID como variables de entorno para que la clave no se almacene en la solicitud.
Añade una solicitud POST a https://generativelanguage.googleapis.com/v1beta/interactions, con un cuerpo JSON que incluya model e input. Usa {{MODEL_ID}} para referenciar la variable.
Aumenta el tiempo de espera. La generación de video tarda mucho más que una finalización de texto.
Añade aserciones para comprobar el código de estado, la existencia de output_video y la forma de respuesta esperada para la resolución elegida.
Duplica la solicitud para cada flujo: texto a video, imagen a video y extensión. Cuando aparezca Omni 1.2, podrás ejecutar las tres y detectar rápidamente qué cambió.

Apidog no genera videos ni es un framework de IA. Sirve para construir solicitudes, ejecutarlas y validar las respuestas con un estándar definido. Descarga Apidog para establecer esta estructura antes de aumentar el gasto.

Errores comunes y soluciones

404 en el endpoint: estás usando /v1beta/models/gemini-omni-1.1-flash:generateContent. Omni requiere /v1beta/interactions, con el modelo en el cuerpo.
output_video.data está vacío: la respuesta usa una URI porque el video supera los 4 MB. Lee output_video.uri y descárgalo mediante la API de Archivos.
Modelo no encontrado: revisa si tu configuración todavía usa gemini-omni-flash-preview. Ese endpoint se retirará el 30 de septiembre de 2026.
Falla la edición de un video subido: esta función no está disponible en el EEE, Suiza ni el Reino Unido. Los videos generados por el modelo sí funcionan en esas regiones.
Se rechaza una extensión: los videos de entrada tienen un límite de 10 segundos; la extensión solo añade contenido al final y no permite añadir diálogos a una subida.

Preguntas frecuentes

¿Qué endpoint usa Gemini Omni? POST https://generativelanguage.googleapis.com/v1beta/interactions, con gemini-omni-1.1-flash en el cuerpo.
¿Existe un nivel gratuito para la API de Gemini Omni? No. Cada generación se factura. Los modelos de texto sí tienen una opción gratuita en AI Studio.
¿Puedo establecer la temperatura o un prompt negativo? No. Las instrucciones del sistema, temperature, top_p, las secuencias de parada y los prompts negativos no son compatibles. Incluye las exclusiones en el prompt.
¿Cómo genero un video vertical? Establece aspect_ratio en 9:16 dentro de response_format.
¿Los videos generados tienen marca de agua? Sí. Toda la salida incluye SynthID, invisible para los espectadores y detectable mediante programación.
¿Cómo se compara con la API de Veo? Usa otro endpoint, tiene otro precio y ofrece fortalezas diferentes. La comparación Omni 1.1 Flash frente a Veo 3.1 explica las diferencias, y la guía de la API de Veo 3.1 cubre esa integración.

La integración se reduce a dos campos obligatorios y un manejador capaz de procesar ambas formas de entrega. Empieza con una llamada a 360p, guárdala con aserciones y aumenta la resolución cuando la infraestructura sea estable. Consulta la documentación oficial de Omni para seguir la evolución de los parámetros.

Claude Fable 5.1 Pensamiento Conservado: Cómo solucionar el error El bloque está vinculado a una conversación diferente

Roobia — Wed, 02 Sep 2026 04:42:20 +0000

Cómo corregir el error 400 de bloques de pensamiento en Claude Fable 5.1

Si migraste un arnés de agente a Claude Fable 5.1 y ves un error 400 que indica que un bloque de pensamiento está «vinculado a una conversación diferente», tu código está modificando el historial entre solicitudes. Fable 5.1 es el primer modelo de Claude que rechaza este patrón. Esta guía explica la verificación, a quién afecta, qué la activa, cómo recuperarse y cómo diseñar historiales de solo agregar que mantengan también la caché de prompts caliente.

Prueba Apidog hoy

La verificación está documentada en Pensamiento preservado y en Novedades de Claude Fable 5.1. Es uno de los tres cambios principales de Fable 5.1 y el único que puede degradar silenciosamente un arnés. Para los otros cambios, consulta la guía de migración.

El error

messages.5.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

Es un error 400 invalid_request_error que se produce antes de cualquier salida. Reintentar con el mismo cuerpo falla de la misma forma.

La ruta messages.5.content.0 identifica el primer bloque de pensamiento que ya no coincide. El mensaje puede incluir también el primer mensaje que cambió; ese es el diagnóstico más útil. El endpoint de conteo de tokens ejecuta la misma verificación.

Existe un error parecido, pero diferente: si aparece la misma cláusula inicial sin «vinculado a una conversación diferente», la firma está manipulada o no se puede interpretar. prefix_mismatch_behavior no se aplica en ese caso.

Qué verifica la API

Cada bloque de pensamiento de Fable 5.1 incluye una firma que registra:

El modelo que produjo el bloque.
El prefijo exacto de la conversación anterior al bloque: el prompt de sistema de nivel superior, el array tools y todos los mensajes anteriores.
La relación con el bloque de pensamiento previo.

Cuando envías de nuevo la transcripción, la API verifica que ese prefijo sea idéntico byte a byte al que existía cuando se generó el bloque.

Anthropic cita dos motivos:

Antidestilación: las cuentas nuevas de API ya no pueden editar manualmente el contexto previo de Claude en una conversación de varios turnos y conservar la transcripción del pensamiento anterior.
Caché de prompts: las mismas modificaciones que rompen la verificación también reinician la caché. Un historial que pasa la verificación puede aprovechar lecturas de caché de $0.25 por millón de tokens en cada turno.

A quién aplica

Aplicación predeterminada

Afecta a las cuentas creadas a partir del 31 de agosto de 2026, incluyendo:

Organizaciones de la API de Claude.
Amazon Bedrock.
Google Cloud.
Microsoft Foundry.

Registrado, pero no aplicado

Las cuentas creadas antes de esa fecha registran la discrepancia, pero solo actúan sobre ella si la solicitud establece thinking.block_binding.prefix_mismatch_behavior, incluso con el valor "error".

Anthropic indica que los modelos futuros aplicarán la verificación a todas las cuentas.

No afectados

No ejecutan esta verificación:

Claude Code.
claude.ai.
Agentes Administrados de Claude.
El SDK de Agentes de Claude.

Estas superficies mantienen intacto el prefijo. Claude Mythos 5.1 tampoco ejecuta la verificación, aunque modificar el historial sigue reiniciando su caché.

Afectados

El problema puede aparecer en cualquier código que construya manualmente el array messages, por ejemplo:

Bucles de agentes personalizados.
Backends de chat.
Frameworks que envuelven la API de Mensajes.

Si distribuyes una herramienta que los usuarios ejecutan con sus propias claves de API, prueba con la verificación activada. Tu cuenta puede ser antigua y no aplicar todavía la regla, mientras que la cuenta de tus usuarios sí.

Para comprobar si tu cuenta aplica la verificación, envía una solicitud que modifique el historial sin la cabecera beta. Si recibes un error 400 que menciona esa cabecera, la aplicación está activa.

Qué invalida los bloques de pensamiento

Cualquiera de estas modificaciones puede invalidar los bloques posteriores:

Editar, reordenar o eliminar un turno anterior. Esto incluye eliminar resultados de herramientas, cortar turnos intermedios o aplicar compactación del lado del cliente conservando textualmente los turnos recientes detrás de un resumen.
Inyectar contenido temporal, como un recordatorio por turno, una línea de estado o un contador de tokens restantes que cambia en cada solicitud.
Reconstruir system o tools entre solicitudes, por ejemplo al actualizar la fecha actual o añadir una herramienta a mitad de la sesión.
Usar una URL de imagen o documento que más tarde sirva bytes diferentes. La API vincula los bytes, no la cadena de URL. Una URL firmada rotativa para el mismo archivo sí es válida.
Eliminar un bloque de pensamiento que no esté al inicio de la ejecución. Los bloques iniciales se pueden eliminar empezando por los más antiguos; no se puede eliminar un bloque intermedio.

Qué mantiene válidos los bloques

Historiales de solo agregar, incluidos los mensajes role: "system" añadidos y los mensajes con ámbito de turno que se dejan en su posición.
Eliminar una secuencia inicial de bloques de pensamiento, siempre desde los más antiguos.
Cambiar parámetros fuera de system, tools y messages, como max_tokens, output_config, effort, tool_choice o metadata.
Añadir, mover o eliminar marcadores cache_control.
Usar compactación y edición de contexto del lado del servidor, incluida la limpieza de bloques de pensamiento. La API compara la conversación tal como la envías, no la copia que el servidor edita. Después de una compactación, el prefijo verificado comienza en el bloque de compactación.

La vía de escape: `drop_block`

Envía la cabecera beta y configura explícitamente el comportamiento:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={"type": "adaptive", "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
    messages=history,
)
for t in response.input_transformations or []:
    print(t.type, t.path, t.reason)

Con drop_block, la API elimina el primer bloque que no coincide y todos los bloques de pensamiento posteriores. Después continúa con la solicitud e informa cada eliminación en el array de nivel superior input_transformations:

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.1.content.0",
      "reason": "prefix_binding_mismatch"
    }
  ]
}

Ten en cuenta lo siguiente:

Solo se aplica a esa solicitud. Sigue enviándolo durante el resto de la sesión.
Los valores predeterminados dependen de la superficie. En una cuenta con aplicación activa, omitir la cabecera produce un error; enviar la cabecera puede activar drop_block como valor predeterminado de la beta. Configúralo siempre de forma explícita.
Enviar block_binding sin la cabecera beta produce un error 400:

block_binding: Extra inputs are not permitted

El campo reason distingue dos casos:

prefix_binding_mismatch: cambió el historial.
model_binding_mismatch: la conversación cambió de modelo y el modelo de destino no puede leer un bloque producido por Fable 5.1. Esto puede ocurrir con un router, un reintento o una estrategia de reserva, y no necesariamente indica un error en tu código.

Con la cabecera beta, cada respuesta incluye input_transformations, vacío cuando no se eliminó ningún bloque.

Eliminar bloques una vez, por ejemplo durante una compactación, tiene un costo bajo. Un arnés que invalida su propio historial en cada solicitud pierde el razonamiento del modelo en cada turno y reinicia la caché de prompts. Usa drop_block como diagnóstico y red de seguridad, no como solución permanente.

Recuperación sin la beta

Si tu plataforma todavía no ofrece estos controles —Microsoft Foundry no los ofrecía en el lanzamiento; Bedrock y Google Cloud los estaban incorporando por modelo—:

Elimina todos los bloques thinking y redacted_thinking.
Conserva los bloques text y tool_use de cada turno.
Reintenta una sola vez.

El modelo responderá sin el razonamiento contenido en esos bloques. Es una recuperación puntual, no un patrón operativo.

Auditoría en tres pasos

Ejecuta esta auditoría antes de cambiar el tráfico:

Captura solicitudes reales. Registra los cuerpos exactos que envía el arnés durante varios turnos normales, incluyendo compactaciones o cambios de herramientas. Compara cada par de solicitudes consecutivas: system, tools y el prefijo compartido de messages deben ser idénticos byte a byte hasta los turnos recién añadidos.
Activa drop_block en una sesión de prueba. Ejecuta una conversación de varios turnos contra claude-fable-5-1 con la cabecera beta y prefix_mismatch_behavior: "drop_block". Registra input_transformations en cada respuesta:
- Un array vacío indica que el historial está intacto.
- prefix_binding_mismatch identifica una modificación anterior al bloque indicado en path.

Establecer el campo activa la verificación de la solicitud incluso en cuentas antiguas. En CI, usa "error" para que cualquier edición detenga la ejecución.

Define el comportamiento de producción. Bajo la cabecera beta, establece explícitamente:
- "error" si una discrepancia siempre indica un error.
- "drop_block" si prefieres degradar en lugar de fallar.

Monitorea tanto los errores 400 como las entradas de input_transformations. No dejes el campo sin configurar en cuentas antiguas: la discrepancia solo se registrará en el servidor y no tendrás nada útil que monitorear.

En Apidog, el segundo paso puede probarse con dos solicitudes:

Envía un turno.
Modifica el prompt de sistema.
Envía el siguiente turno con la cabecera beta.
Verifica input_transformations.

Conserva la prueba en la colección para ejecutarla después de cada cambio del arnés. También puedes descargar Apidog para construirla.

Diseña un arnés de solo agregar

Reemplaza las ediciones del historial por operaciones que mantengan intacto el prefijo:

Lo que hacías	Haz esto
Editar el prompt de sistema a mitad de sesión, por ejemplo para cambiar la fecha o el modo.	Congela `system` al inicio. Cuando el cambio sea efectivo, añade `{"role": "system", "content": "La fecha actual es 14-09-2026."}`. El nuevo mensaje se convierte en parte del prefijo de los bloques posteriores.
Editar el array `tools` a mitad de sesión.	Declara el conjunto completo al inicio y usa `defer_loading: true` para las herramientas que comienzan ocultas. Envía bloques `tool_addition` y `tool_removal` en un mensaje `role: "system"` con la beta `mid-conversation-tool-changes-2026-07-01`.
Inyectar un recordatorio por turno y eliminarlo en la siguiente solicitud.	Usa `{"role": "system", "clear_at": "next_user_message", "content": "..."}` con la beta `mid-conversation-system-clear-at-2026-08-21`, después del resultado de la herramienta. Deja las copias anteriores en su lugar. Sin la beta, añade el recordatorio como un bloque de texto después de los bloques `tool_result` del mismo mensaje de usuario y conserva las copias anteriores.
Eliminar resultados antiguos de herramientas en el cliente.	Usa edición de contexto del lado del servidor con limpieza de resultados de herramientas.
Compactar el historial en el cliente conservando los turnos recientes.	Prefiere la compactación del lado del servidor con la beta `compact-2026-01-12`; su parámetro `instructions` acepta tu propio prompt de resumen. Si debes compactar en el cliente, reemplaza todo el historial por un mensaje de resumen y el nuevo turno de usuario, sin repetir contenido.
Referenciar una imagen o documento mediante URL en varios turnos.	Sube el archivo una vez a la API de Archivos y envía su `file_id`, o utiliza base64.

Dos estrategias de compactación del lado del cliente fallan con esta verificación:

Compactación de cola: resume los turnos antiguos y conserva textualmente los recientes. Los bloques retenidos se produjeron contra el historial completo.
Compactación en segundo plano: inserta más tarde un resumen creado fuera de la ruta crítica. Los turnos generados entre el inicio del resumen y su inserción quedan invalidados.

Cortar turnos individuales del medio invalida todos los bloques posteriores. Para cambios de instrucciones, usa un mensaje de sistema a mitad de conversación; para eliminar contenido específico, usa edición de contexto del lado del servidor.

Por qué también es un problema de caché

Todo lo que reinicia la verificación también reinicia la caché de prompts.

Fable 5.1 hizo que las lecturas de caché fueran cuatro veces más baratas que en Fable 5, mientras que los fallos son proporcionalmente más costosos. Un arnés de solo agregar obtiene dos beneficios:

Conserva el razonamiento del modelo.
Lee el prefijo en caché a $0.25 por millón, en lugar de volver a escribirlo a $12.50.

Consulta el desglose de precios, el recorrido de la API, la guía de prompting y la guía de Claude Code.

Debido al menor precio de las lecturas de caché, compactar demasiado pronto para ahorrar dinero puede dejar de ser la mejor compensación en Fable 5.1. Experimenta con puntos de compactación posteriores.

Preguntas frecuentes

¿Qué significa «El bloque está vinculado a una conversación diferente»?

Un bloque de pensamiento de Claude Fable 5.1 se reprodujo después de que cambiara algo anterior: el prompt de sistema, el array de herramientas o un mensaje previo. En las cuentas con aplicación forzosa, la API rechaza la solicitud con un error 400.

¿Qué cuentas aplican la verificación del historial?

Las cuentas creadas a partir del 31 de agosto de 2026, en todas las plataformas. Las cuentas antiguas solo la aplican cuando una solicitud establece thinking.block_binding.prefix_mismatch_behavior. Anthropic planea aplicarla a todas las cuentas en modelos futuros.

¿Cómo hago desaparecer rápidamente el error?

Envía la cabecera beta thinking-binding-controls-2026-08-01 con prefix_mismatch_behavior: "drop_block". La API eliminará los bloques afectados y continuará. Después corrige la modificación del historial: eliminar bloques en cada turno consume razonamiento y reinicia la caché.

¿Cambiar `effort` o `max_tokens` invalida los bloques?

No. Puedes cambiar libremente cualquier parámetro fuera de system, tools y messages, incluidos max_tokens, output_config, effort, tool_choice, metadata y los marcadores cache_control.

¿La compactación del lado del servidor rompe la verificación?

No. La compactación y la edición de contexto ocurren después de la verificación, que compara la conversación tal como la enviaste. La compactación del lado del cliente que conserva textualmente los turnos recientes sí puede romperla.

¿Claude Mythos 5.1 tiene la misma verificación?

No. Mythos 5.1 no ejecuta la verificación de conversación. Sin embargo, sus bloques siguen vinculados al modelo productor y las ediciones del historial todavía reinician la caché.

Referencias

Claude Mythos 5.1 vs Fable 5.1: Mismo Modelo, Diferentes Salvaguardias

Roobia — Wed, 02 Sep 2026 04:20:02 +0000

Claude Fable 5.1 vs. Mythos 5.1: modelo idéntico, salvaguardias diferentes

Anthropic lanzó Claude Fable 5.1 y Claude Mythos 5.1 el 1 de septiembre de 2026, y los describió como “el mismo modelo pero con diferentes niveles de salvaguardias”. Comparten pesos, especificaciones, precios de $10 y $50, y API. Fable 5.1 está disponible para todos; Mythos 5.1 solo para organizaciones aprobadas en el Proyecto Glasswing, mediante programas de verificación de ciberseguridad y ciencias de la vida. También es el modelo que impulsa Claude Security de Anthropic.

Prueba Apidog hoy

Esta guía resume qué comparten, sus cuatro diferencias principales, cómo solicitar acceso a Mythos 5.1 y qué revela la única brecha de benchmark publicada sobre el costo de las salvaguardias.

Fuentes principales:

Comparación rápida

	Claude Fable 5.1	Claude Mythos 5.1
ID del modelo	`claude-fable-5-1`	`claude-mythos-5-1`
Disponibilidad	Todos los clientes	Participantes aprobados del Proyecto Glasswing
Acceso	Registro	Programa de Verificación Cibernética o de Ciencias de la Vida; organizaciones de EE. UU.
Precio	$10 / $50; lecturas de caché a $0.25	Igual
Contexto / salida máxima	1M / 128K	Igual
Corte de conocimiento	Junio de 2026	Igual
Pensamiento	Adaptativo y siempre activo	Igual
`tool_choice` forzado	400	400
Clasificadores de seguridad	Conjunto completo: cibernético, biológico, `llm_frontera`, `extracción_razonamiento` y daños generales	Dependen del programa de acceso y son más permisivos para trabajos defensivos aprobados
Vulnerabilidades	Puede identificarlas, pero no desarrollar exploits	Puede descubrir rutas de explotación para investigación defensiva aprobada
Lee bloques de pensamiento de Fable 5.1	Sí	Sí; es el único otro modelo compatible
Verificación de edición del historial	Sí	No
Plataformas	API de Claude, Bedrock, Plataforma Claude en AWS, Google Cloud y Foundry	API de Claude, Bedrock, Google Cloud y Foundry; no Plataforma Claude en AWS
Nivel de Prioridad	No disponible	No disponible
Retención de datos	30 días; Modelo Cubierto	Igual
Terminal-Bench 4.0	55.8%	60.9%

Qué comparten

Anthropic afirma que ambos modelos tienen las mismas capacidades, especificaciones, precios y comportamiento de API. En concreto, comparten:

Ventana de contexto de 1M y salida máxima de 128K.
Pensamiento adaptativo siempre activo.
Cinco niveles de esfuerzo.
Corte de conocimiento en junio de 2026.
Lecturas de caché a $0.25.
Los tres cambios principales de la generación Fable 5, salvo la verificación del historial descrita más adelante.
Retención de datos obligatoria durante 30 días.
Clasificación como Modelos Cubiertos: no admiten retención cero salvo autorización expresa de Anthropic.
Ausencia del Nivel de Prioridad.
Marca de agua estadística de texto de Anthropic en todas las plataformas.

La hoja de especificaciones de Fable 5.1 también sirve como hoja de especificaciones de Mythos 5.1.

Diferencia 1: quién puede usarlo

Fable 5.1 está disponible públicamente en la API de Claude y en todas las plataformas asociadas.

Mythos 5.1 solo se ofrece a clientes aprobados del Proyecto Glasswing. En el lanzamiento existen dos rutas de acceso:

Programa de Verificación Cibernética, dirigido a profesionales de seguridad defensiva que solicitan acceso mediante el portal de Anthropic.
Programa de Verificación de Ciencias de la Vida, dirigido a organizaciones de ciencias de la vida y gestionado junto con el gobierno de EE. UU.

En el lanzamiento, ambos programas están limitados a organizaciones estadounidenses. La inscripción del programa de ciencias de la vida se ampliará con el tiempo. El acceso se coordina con los equipos de cuentas de Anthropic, AWS o Google Cloud; todavía no estaba confirmado si el acceso existente a Mythos 5 se transfería automáticamente.

Esto cambia el modelo de acceso de Mythos 5, que era exclusivamente por invitación y no ejecutaba clasificadores de seguridad. Mythos 5.1 sí ejecuta salvaguardias, pero calibradas según el programa de acceso.

Diferencia 2: qué permiten las salvaguardias

Fable 5.1 ejecuta el conjunto completo de clasificadores de Fable. Una solicitud rechazada no devuelve un error HTTP: responde con HTTP 200 y:

{
  "stop_reason": "refusal"
}

La respuesta también incluye una categoría. Anthropic informa que los falsos positivos disminuyeron considerablemente respecto a Fable 5:

Los clasificadores biológicos se activan un 85% menos en solicitudes benignas.
Las salvaguardias cibernéticas generan aproximadamente un 60% menos de intervenciones por sesión de Claude Code.
Fable 5.1 puede identificar vulnerabilidades de software, pero no desarrolla exploits.

Mythos 5.1 está diseñado para trabajos que Fable 5.1 puede rechazar, como el descubrimiento de rutas de explotación para investigación defensiva aprobada o determinados trabajos de ciencias de la vida que activan el clasificador biológico.

Aun así, Mythos 5.1 también aplica salvaguardias. Gestiona las respuestas de la misma forma:

stop_reason: "refusal"
stop_details.category

Configura siempre una alternativa para las solicitudes rechazadas.

La publicación de lanzamiento y la tarjeta del sistema describen además:

Un clasificador en tiempo real para detectar sondeos agresivos e intentos de escapar del sandbox.
Aislamiento reforzado para cargas cibernéticas de alto riesgo.
Nuevos requisitos de aislamiento de red para evaluadores externos.

Estas medidas responden a incidentes de evaluaciones anteriores en los que los modelos alcanzaron sistemas reales.

Diferencia 3: verificación de edición del historial

Los bloques de pensamiento de Fable 5.1 solo son válidos dentro de la conversación exacta que los generó. Para cuentas creadas el 31 de agosto de 2026 o después, editar cualquiera de estos elementos invalida los bloques posteriores:

Un turno anterior.
El prompt del sistema.
El array de herramientas.

La API devuelve un error 400 cuando detecta que el bloque está vinculado a otra conversación. La guía de pensamiento preservado documenta este comportamiento.

Mythos 5.1 no realiza esa verificación. Sin embargo:

Sigue vinculando los bloques al modelo que los produjo.
Las ediciones del historial reinician la caché de prompts.
Mythos 5.1 puede leer bloques de pensamiento de Mythos 5, pero no al revés.
Mythos 5.1 y Fable 5.1 son los únicos modelos que pueden leer los bloques de pensamiento del otro.
Una conversación puede migrarse entre ambos modelos sin perder su razonamiento.
Si se migra a Opus 5, la API elimina los bloques.

Diferencia 4: plataformas y límites de tasa

Fable 5.1 está disponible en la Plataforma Claude en AWS. Mythos 5.1 no.

Mythos 5.1 está disponible en:

API de Claude.
Amazon Bedrock como anthropic.claude-mythos-5-1, en us-east-1; el modelo no aparece públicamente en el catálogo.
Google Cloud.
Microsoft Foundry.

Los límites de tasa también están separados:

Fable 5.1 comparte el grupo Fable 5.x con Fable 5.
Mythos 5.1 comparte el grupo Mythos con Mythos 5.

Qué revela la brecha de benchmark

Anthropic publicó estos resultados para Terminal-Bench 4.0:

Fable 5.1: 55.8%
Mythos 5.1: 60.9%

La diferencia es de cinco puntos porcentuales en codificación agéntica. Como los modelos son idénticos, el resultado sugiere que las salvaguardias de Fable pueden intervenir en algunos pasos benignos de una sesión de terminal extensa, incluso cuando la tarea no está relacionada con ciberseguridad o biología.

También implica que el modelo más capaz disponible públicamente tiene un hermano con un resultado publicado superior. Consulta el desglose completo de benchmarks.

Las afirmaciones científicas de Anthropic corresponden a Mythos 5.1, no a Fable 5.1:

Ligantes de proteínas con afinidades diez veces superiores a las mejores propuestas de la competencia en tres objetivos.
Cerca de un 50% de aciertos en 12 objetivos, frente al 10–15% habitual.
Un mapa de elevación de Venus con detalles de entre dos y tres kilómetros.

Estas son las cargas de trabajo a las que apunta el Programa de Verificación de Ciencias de la Vida.

Qué modelo usar

Para la mayoría de los equipos, Fable 5.1 es la opción disponible por defecto. Mythos 5.1 está dirigido a:

Organizaciones que realizan investigación de seguridad defensiva y activan el clasificador cibernético.
Organizaciones de ciencias de la vida cuyo trabajo benigno activa el clasificador biológico.

Si tu organización encaja en uno de esos casos, solicita el programa de verificación correspondiente. La migración debería consistir principalmente en cambiar el ID del modelo, porque el comportamiento de la API es el mismo salvo por la verificación del historial.

Antes de solicitar acceso a Mythos 5.1, prueba estas medidas con Fable 5.1:

Sigue la guía de formulación de Anthropic. Pregunta “¿hay algún error?” en lugar de “¿esto compila?”.
Proporciona documentación para lenguajes menos conocidos.
Elimina las herramientas que devuelven datos base64 al contexto.
Configura un fallback:

{
  "fallbacks": "default"
}

Con esta configuración, las solicitudes rechazadas pueden redirigirse a Opus 5 u Opus 4.8. La guía del parámetro de fallbacks incluye el procedimiento completo.

Cómo comprobar con qué modelo estás hablando

Como ambos modelos son idénticos en el resto de aspectos, envía el mismo cuerpo de solicitud a cada ID desde Apidog.

1. Compara las salvaguardias

Envía un prompt benigno de análisis de vulnerabilidades a:

claude-fable-5-1
claude-mythos-5-1

Después compara:

stop_reason
stop_details.category

2. Comprueba la verificación del historial

Envía dos solicitudes y modifica el prompt del sistema entre turnos usando el encabezado:

thinking-binding-controls-2026-08-01

El resultado esperado es:

Fable 5.1: prefix_binding_mismatch en input_transformations.
Mythos 5.1: no devuelve ese error.

Puedes descargar Apidog para ejecutar las pruebas.

Preguntas frecuentes

¿Claude Mythos 5.1 es más capaz que Fable 5.1?

Es el mismo modelo y, por tanto, tiene la misma capacidad subyacente. El único benchmark publicado muestra un 60.9% para Mythos 5.1 frente a un 55.8% para Fable 5.1 en Terminal-Bench 4.0. La diferencia refleja la intervención de las salvaguardias, no arquitecturas distintas.

¿Cómo obtengo acceso a Claude Mythos 5.1?

A través del Proyecto Glasswing:

Programa de Verificación Cibernética para profesionales de seguridad defensiva.
Programa de Verificación de Ciencias de la Vida.

En el lanzamiento, ambos están limitados a organizaciones de EE. UU. Contacta con tu equipo de cuentas de Anthropic, AWS o Google Cloud.

¿Mythos 5.1 cuesta más que Fable 5.1?

No. Ambos cuestan $10 y $50 por millón de tokens y aplican las mismas tarifas de caché y lotes.

¿Claude Mythos 5.1 rechaza solicitudes?

Sí. A diferencia de Mythos 5, Mythos 5.1 ejecuta salvaguardias calibradas según el programa de acceso. Gestiona stop_reason: "refusal" y stop_details.category igual que en Fable 5.1.

¿Puedo cambiar una conversación entre Fable 5.1 y Mythos 5.1?

Sí. Puedes cambiar entre ambos sin perder el razonamiento, ya que son los únicos modelos capaces de leer los bloques de pensamiento del otro.

¿Mythos 5.1 está disponible en Amazon Bedrock?

Sí. Está disponible como anthropic.claude-mythos-5-1 en us-east-1, aunque no aparece públicamente en el catálogo. No está disponible en la Plataforma Claude en AWS.