El número principal de Gemini 4 Argon, 1M de tokens, es su límite de salida, no su ventana de contexto. Google dice que una sola respuesta de Argon puede llegar a 1 millón de tokens, aproximadamente 16 veces el límite anterior de 64K, y no ha publicado la ventana de entrada de Argon en absoluto. Todavía no hay nada que invocar: Argon está disponible hoy solo para los defensores del Programa Fairwind, y los clientes de API de pago serán los siguientes una vez que Google abra el acceso (consulte la guía de fecha de lanzamiento y acceso).
Una respuesta tan larga rompe tres suposiciones en las que la mayoría de las pilas de API confían: una llamada finaliza en segundos, el cuerpo cabe en la memoria y una solicitud tiene un costo pequeño y predecible. Esta guía cubre el costo de una respuesta máxima, el streaming, los tiempos de espera, los límites de salida, el almacenamiento y cómo probar todo esto en Apidog antes de que llegue el acceso. Para una descripción general del modelo, consulte qué es Gemini 4 Argon; para las formas de solicitud, consulte la guía de la API de Gemini 4 Argon.
1M de tokens de salida no es una ventana de contexto de 1M
Varias páginas que clasifican para Argon describen la cifra de 1M como una ventana de contexto, y un titular la llama una "ventana de contexto 16 veces más grande". Eso es al revés. La publicación de lanzamiento de Google dice que expandió "el límite de tokens de salida del modelo a un líder de la industria de 1M de tokens". Esos 64K coinciden con el límite de salida de 65,536 tokens en Gemini 3.1 Pro Preview, el modelo Pro superior anterior de Google.
La entrada es un número separado que Google no ha proporcionado. Su evaluación de contexto largo, descrita en la metodología de evaluación, utilizó prompts entre 256K y 1M de tokens. Eso es un subconjunto de referencia, no una especificación. También hay una advertencia en el lado de la salida: Vals AI enumera una salida máxima de 262K para la configuración de Argon que probó. Google dice que el límite del modelo es de 1M; al menos un evaluador externo vio un límite inferior en el endpoint que utilizó.
| Modelo | Salida máxima por respuesta | Ventana de entrada o contexto |
|---|---|---|
| Gemini 4 Argon | 1M (límite declarado por Google) | No publicado |
| Gemini 3.1 Pro Preview | 65,536 | 1,048,576 |
| Gemini 3.8 Flash | 65,536 | 1,048,576 |
| GPT-6 Astra | 128,000 | 1,050,000 (922K entrada máxima) |
| Claude Opus 5.5 | 128K (300K en Batch con un encabezado beta) | 1M |
Todos los competidores limitan la salida síncrona a 128K, por lo que el límite declarado de Argon es aproximadamente 8 veces el de ellos. La razón de Google es la profundidad del razonamiento: con margen, el modelo puede "generar cientos de miles de tokens en una sola trayectoria" y resolver problemas difíciles en una sola pasada. Para saber cómo otros proveedores manejan ejecuciones largas, consulte las tareas de 18 horas de Claude Opus 5.5 y la guía de la API de GPT-6 Astra.

Cuánto cuesta una respuesta máxima
Calcule el límite primero. La salida se factura a $10 por 1M de tokens durante el período de introducción de Argon y $20 después, por lo que una respuesta de longitud completa cuesta:
- Introducción: 1,000,000 x $10/1M = $10.00 de salida
- Estándar: 1,000,000 x $20/1M = $20.00 de salida
La entrada se suma. Un prompt de 200,000 tokens añade 200,000 x $2/1M = $0.40 a tarifas de introducción o $0.80 a tarifas estándar, por lo que una sola llamada máxima cuesta $10.40 o $20.80. Un trabajo nocturno que dispara 100 de esos cuesta $1,040 a tarifas de introducción.
Pensar hace que esto sea más difícil de ver. En los modelos actuales de Gemini, los tokens de "pensamiento" se facturan como salida; Google no ha dicho si Argon sigue esa regla o si el pensamiento cuenta para el límite de 1M. De cualquier manera, una respuesta visible corta aún puede implicar una gran factura de salida. La guía de precios de Gemini 4 Argon presenta más escenarios, incluyendo la entrada en caché con un 95% de descuento.
Por qué el streaming es obligatorio
Una llamada sin streaming no devuelve nada hasta que la respuesta completa ha terminado. Con cientos de miles de tokens, esa es una conexión larga y silenciosa, y los tiempos de espera por inactividad en su pila pueden cerrarla antes de que llegue el primer byte.
Transmita en su lugar (Stream instead). En generateContent, cambie el método por :streamGenerateContent?alt=sse y Google enviará eventos enviados por el servidor, un fragmento parcial de candidatos por evento. Lea cada evento a medida que llega y escríbalo; no recopile el cuerpo primero. Esto se ejecuta hoy en Gemini 3.8 Flash, con el modelo en una variable porque Google no ha publicado la ID del modelo de Argon (la configuración se encuentra en nuestra guía de la API de Gemini 3.8 Flash):
import json, os, requests
MODEL = os.environ.get("GEMINI_MODEL", "gemini-3.8-flash")
URL = ("https://generativelanguage.googleapis.com/v1beta/models/"
f"{MODEL}:streamGenerateContent?alt=sse")
body = {
"contents": [{"parts": [{"text": "Write a test plan for every endpoint in a payments API."}]}],
"generationConfig": {"maxOutputTokens": 60000},
}
usage = None
with requests.post(URL, json=body, stream=True, timeout=(10, 120),
headers={"x-goog-api-key": os.environ["GEMINI_API_KEY"]}) as r, \
open("response.txt", "a", encoding="utf-8") as out:
r.raise_for_status()
for line in r.iter_lines(decode_unicode=True):
if not line or not line.startswith("data:"):
continue
event = json.loads(line[5:])
for cand in event.get("candidates", []):
for part in cand.get("content", {}).get("parts", []):
out.write(part.get("text", ""))
out.flush()
usage = event.get("usageMetadata", usage)
print(usage)
timeout=(10, 120) establece un tiempo de espera de conexión de 10 segundos y un tiempo de espera de lectura de 120 segundos. En requests, el tiempo de espera de lectura es la brecha más larga entre bytes, no la duración total, por lo que un stream que sigue enviando puede ejecutarse tanto tiempo como sea necesario. Cada fragmento se escribe en el disco a medida que llega. En 3.8 Flash, cada evento lleva un usageMetadata en ejecución, por lo que el último le da los recuentos finales de tokens para registrar y facturar.
Tiempos de espera en cada salto
Su cliente es un salto. Una transmisión larga también cruza un proxy inverso, una puerta de enlace API, un equilibrador de carga y quizás un entorno de ejecución sin servidor, y cualquiera de ellos puede finalizar la respuesta antes de tiempo:
| Salto | Qué comprobar | Síntoma cuando algo va mal |
|---|---|---|
| Cliente HTTP | Tiempo de espera de lectura o inactividad, más cualquier tiempo de espera total de la solicitud | Excepciones a mitad de la transmisión solo en respuestas largas |
| Proxy inverso | Tiempo de espera de lectura y almacenamiento en búfer de respuesta para text/event-stream |
Los eventos llegan en ráfagas, o la transmisión se interrumpe |
| Gateway de API | Duración máxima de la solicitud | Las solicitudes fallan en el mismo tiempo transcurrido en cada ejecución |
| Balanceador de carga | Tiempo de espera de inactividad | Caídas durante pausas largas antes del primer evento |
| Función sin servidor | Tiempo máximo de ejecución | La función termina mientras el modelo sigue escribiendo |
Esté atento a un corte fijo. Si las respuestas largas siempre fallan en el mismo tiempo transcurrido, algún salto tiene un límite de duración estricto que el streaming no puede solucionar, y ese trabajo debe salir de la ruta de la solicitud.
Ejecutar trabajos largos en segundo plano
Para los trabajos más largos, quite el trabajo de una conexión activa. La API de Interacciones soporta la ejecución en segundo plano para tareas de larga duración utilizando background=true. Las ejecuciones en segundo plano dependen de las interacciones almacenadas: la documentación dice que store=false es incompatible con la ejecución en segundo plano, así que deje el almacenamiento activado para estas solicitudes. Para recuperar una interacción en segundo plano finalizada, siga la documentación de Google; no intente adivinar los endpoints de sondeo. Dado que Google dice que los nuevos modelos se lanzan en la API de Interacciones, planifique que los trabajos largos de Argon se ejecuten allí.
Limitar la salida a propósito
El límite de 1M es un tope, no un objetivo. En generateContent, generationConfig.maxOutputTokens limita cada respuesta; el ejemplo de streaming establece 60,000. En 3.8 Flash, el "pensamiento" cuenta para ese límite: nuestra prueba limitada a 2,000 devolvió 1,340 tokens de pensamiento y 656 visibles. Para la API de Interacciones, confirme el campo de límite de salida en la documentación de Google antes de depender de uno. Luego, elija el límite según el costo que aceptará por llamada:
| Límite de salida | Costo de salida en el peor de los casos, estándar ($20/1M) | Introducción ($10/1M) |
|---|---|---|
| 64,000 | 64,000 x $20/1M = $1.28 | $0.64 |
| 128,000 | $2.56 | $1.28 |
| 500,000 | $10.00 | $5.00 |
| 1,000,000 | $20.00 | $10.00 |
Una respuesta que alcanza el límite se detiene antes de tiempo, así que trátela como incompleta. Compruebe el finishReason del evento final: MAX_TOKENS significa que el límite la interrumpió. Luego, continúe en un turno de seguimiento o aumente el límite para ese trabajo.
Almacenar y analizar salidas enormes sin buffering
Un millón de tokens son megabytes de texto por respuesta. Algunas reglas evitan que eso sature un worker:
- Escriba los fragmentos a medida que llegan, en un archivo o en una carga de objeto multiparte, en lugar de construir una sola cadena en la memoria.
- Conserve el archivo parcial si la conexión se cae. Un reintento ciego desde cero genera, y factura, la salida de nuevo.
- Pida JSON Lines cuando necesite estructura, para que cada línea se analice por sí sola en lugar de esperar a que se cierre un documento gigante.
- Registre
usageMetadatay un recuento de bytes, no cuerpos completos. - Compruebe los límites de columnas y tamaño de mensajes en su base de datos y cola antes de que una respuesta de 800K tokens los alcance.
Pruébalo en Apidog antes de que se abra el acceso
Puede ensayar todo esto con un sustituto. Descargue Apidog y realice tres comprobaciones.
- Observa el stream. Envía la solicitud de streaming contra 3.8 Flash con
GEMINI_API_KEYyGEMINI_MODELcomo variables de entorno. Apidog analiza las respuestastext/event-streamy muestra cada evento en su vista de Línea de Tiempo a medida que llega, para que puedas ver los tamaños de los fragmentos, las pausas y elusageMetadatafinal. - Asegúrese de los recuentos de tokens. En una solicitud generateContent sin streaming, afirme que
candidatesTokenCountmásthoughtsTokenCountenusageMetadatase mantiene en o por debajo de su límite y que el costo calculado se mantiene por debajo de su techo a precios de Argon. La guía de la API de Argon tiene un script de costos listo para usar.
Transmite una respuesta falsa mucho más larga. La salida real de 3.8 Flash alcanza un máximo de 65,536 tokens, así que ejecuta un mock local que transmita mucho más con la misma forma de evento:
# long_stream_mock.py: Gemini-shaped SSE for parser and timeout tests (fake data)
import json, time
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
EVENTS, DELAY, CHUNK = 20000, 0.005, "lorem ipsum " * 40
class Handler(BaseHTTPRequestHandler):
def do_POST(self):
self.rfile.read(int(self.headers.get("Content-Length", 0)))
self.send_response(200)
self.send_header("Content-Type", "text/event-stream")
self.end_headers()
for i in range(EVENTS):
event = {"candidates": [{"content": {"parts": [{"text": CHUNK}]}}]}
if i == EVENTS - 1: # fake counts sized like a near-max reply
event["usageMetadata"] = {"promptTokenCount": 1200,
"candidatesTokenCount": 950000, "thoughtsTokenCount": 40000,
"totalTokenCount": 991200}
self.wfile.write(f"data: {json.dumps(event)}\n\n".encode())
self.wfile.flush()
time.sleep(DELAY)
ThreadingHTTPServer(("127.0.0.1", 8787), Handler).serve_forever()
Apunte la URL base de un entorno "mock" a http://127.0.0.1:8787 y envíe la misma solicitud de streaming a través de él. El stream se ejecuta durante aproximadamente dos minutos (128 segundos en nuestra prueba) y transporta 9.6 millones de caracteres de texto, suficiente para exponer un analizador con búfer, un proxy que retiene eventos o un tiempo de espera demasiado corto.
Preguntas frecuentes
- ¿Es 1M la ventana de contexto de Gemini 4 Argon? No. 1M es el límite de salida por respuesta, frente a los 64K. Google no ha publicado la ventana de entrada de Argon.
- ¿Cuánto cuesta una respuesta de Argon de 1M de tokens? $10 de salida a tarifas de introducción y $20 a tarifas estándar, más la entrada. Consulte los precios de Gemini 4 Argon para más escenarios.
- ¿Puedo generar una respuesta de 1M de tokens hoy? No, a menos que su organización esté en el grupo Fairwind con acceso a Argon. Gemini 3.8 Flash y 3.1 Pro Preview limitan la salida a 65,536 tokens, y Vals AI lista 262K de salida máxima para la configuración de Argon que probó.
- ¿Tengo que hacer streaming de respuestas largas de Argon? Google no ha publicado guías de streaming para Argon, pero una llamada sin streaming que se ejecuta durante minutos está expuesta a cada tiempo de espera por inactividad en su pila. Transmítala, o use la ejecución en segundo plano en la API de Interacciones.
- ¿Cómo se compara el límite de salida de Argon con GPT-6 Astra y Claude Opus 5.5? Ambos limitan la salida síncrona a 128K; Anthropic permite 300K en Batch con un encabezado beta. Los 1M declarados de Argon son aproximadamente 8 veces eso.
Su próximo paso
Añada streaming y un límite de salida a su cliente Gemini ahora, en 3.8 Flash, y ejecútelo contra el mock stream largo hasta que nada en su pila lo corte. Cuando se lance la ID de Argon, cambie GEMINI_MODEL y vuelva a ejecutar las mismas pruebas en Apidog.
