AI Models on KnightLi Blog

Gemini 3.5 ya está aquí: Flash llega primero y Google pone el foco en agentes y tareas largas

Wed, 20 May 2026 22:51:31 +0800

Google lanzó oficialmente la serie Gemini 3.5 el 20 de mayo de 2026. El primer modelo disponible es Gemini 3.5 Flash. Su posicionamiento no es solo chat, sino agentes, generación de código y ejecución de tareas complejas de larga duración.

El mensaje de esta presentación es claro: Google quiere que Gemini 3.5 no solo responda preguntas, sino que también planifique, ejecute, compruebe resultados y mantenga el avance en flujos de trabajo de varios pasos.

Gemini 3.5 Flash llega primero

Gemini 3.5 Flash ya está disponible para varios tipos de usuarios:

Los usuarios generales pueden probarlo en la app Gemini y en AI Mode de Google Search.
Los desarrolladores pueden usarlo mediante Google Antigravity, Google AI Studio y la Gemini API en Android Studio.
Los usuarios empresariales pueden acceder a él mediante Gemini Enterprise Agent Platform y Gemini Enterprise.

Google también dijo que Gemini 3.5 Pro sigue en desarrollo, ya se usa internamente en Google y se espera para el próximo mes.

Esto indica que la serie 3.5 mantiene la división entre Flash y Pro: Flash enfatiza velocidad, costo y ejecución a escala, mientras que Pro probablemente apuntará a escenarios más complejos y con mayores requisitos de capacidad.

El foco está en agentes y código

Google describe Gemini 3.5 Flash como uno de sus modelos más fuertes para agentes y programación. El anuncio afirma que supera algunos resultados de Gemini 3.1 Pro en benchmarks de código y agentes como Terminal-Bench 2.1, GDPval-AA, MCP Atlas y CharXiv Reasoning.

La mayoría de usuarios no necesita obsesionarse con cada número. Lo más importante es que Google está llevando la capacidad del modelo hacia flujos ejecutables: no solo escribir código, sino migrar proyectos antiguos, desarrollar aplicaciones complejas, organizar reportes financieros, analizar datos y ejecutar pruebas repetidas.

Dentro del framework de desarrollo Antigravity, Gemini 3.5 Flash puede usar varios subagents colaborativos para manejar tareas grandes. Google mostró ejemplos como analizar el paper de AlphaZero y crear un juego jugable, convertir código legacy a Next.js y generar paisajes urbanos y opciones de UI en paralelo.

La dirección es clara: las herramientas de programación con IA están pasando de “generar un fragmento de código” a “coordinar varios agentes para completar un proyecto”.

UI multimodal y gráficos más potentes

Gemini 3.5 Flash se apoya en la base multimodal de Gemini 3. Google dice que puede generar interfaces web más ricas, animaciones interactivas y contenido visual.

El anuncio incluye ejemplos como:

Crear animaciones interactivas para papers de investigación.
Convertir descripciones de texto en modelos de hardware interactivos.
Generar un concepto completo de marca para una campaña escolar de recaudación.
Producir varias opciones de UX para un flujo de checkout en poco tiempo.

Esto importa para desarrolladores y equipos de producto. El modelo ya no solo escribe explicaciones. También puede participar en prototipos frontend, diseño de interacción y visualización.

Uso empresarial: automatizar flujos que consumen tiempo

Google citó varios ejemplos de socios. Shopify usa subagents para analizar datos complejos y predecir crecimiento de comerciantes. Macquarie Bank prueba 3.5 Flash con documentos de más de 100 páginas para acelerar la apertura de cuentas. Salesforce lo integra en Agentforce. Ramp lo usa para mejorar OCR en facturas complejas. Xero usa agentes de IA para procesos administrativos. Databricks usa flujos automatizados para monitorear anomalías de datos y sugerir correcciones.

Estos casos apuntan a la misma tendencia: la adopción empresarial de modelos grandes se está moviendo de preguntas puntuales a automatización de procesos. Que un modelo sea barato, rápido y estable en tareas largas puede importar más que una respuesta aislada muy llamativa.

Gemini Spark: un agente personal de IA

Google también anunció Gemini Spark, un agente personal de IA impulsado por Gemini 3.5 Flash. Su objetivo es ejecutarse durante largos periodos y realizar tareas de forma proactiva bajo la guía del usuario.

Gemini Spark ya empezó a desplegarse para testers de confianza. Google planea abrir una beta la próxima semana para suscriptores de Google AI Ultra en Estados Unidos.

Vale la pena seguir esta parte. Google Search, la app Gemini, Android, Workspace y el ecosistema del navegador ya están presentes en muchas áreas de la vida digital personal. Si un agente personal puede conectarse con estas entradas, su impacto puede ser mayor que el de un chatbot aislado.

La seguridad se mueve más arriba en el proceso

Google dice que Gemini 3.5 fue desarrollado bajo su Frontier Safety Framework, con protecciones reforzadas para seguridad de la información y riesgos CBRN. El anuncio también menciona herramientas de interpretabilidad para ayudar a examinar y entender el razonamiento del modelo antes de entregar respuestas.

Esto muestra que los lanzamientos de modelos frontera ya no son solo una competencia de capacidad. Cuanto más se enfatizan agentes, ejecución autónoma y tareas largas, más importantes se vuelven los controles de seguridad, la tasa de rechazos erróneos, la prevención de salidas dañinas y la interpretabilidad.

Cómo mirar Gemini 3.5

Gemini 3.5 Flash no es solo otro lanzamiento de modelo. Parece más bien la apuesta de Google por la siguiente forma de los productos de IA: modelos que llaman herramientas, dividen tareas, coordinan ejecución, generan UI y entran en flujos personales y empresariales.

Para desarrolladores, lo importante será la experiencia real en Google Antigravity, AI Studio, Gemini API y Android Studio. Para empresas, la pregunta es si puede reducir trabajo manual de forma estable en flujos reales, no solo sacar buenos resultados en benchmarks.

Gemini 3.5 Pro todavía no está disponible públicamente. Cuando Pro llegue, las diferencias entre Flash y Pro en capacidad, precio, velocidad y manejo de contexto determinarán para qué escenarios de producción conviene cada uno.

Referencias:

Google Blog: Gemini 3.5

DeepSeek-V4 KV Cache explicado: por qué el contexto de 1M usa menos VRAM

Mon, 18 May 2026 18:38:26 +0800

El costo real de los modelos de contexto largo no suele estar en si aceptan un millón de tokens, sino en cuánta VRAM consume el KV Cache durante la inferencia.

Durante la decodificación Transformer, cada nuevo token generado necesita acceder a los estados Key y Value de los tokens anteriores. Cuanto más largo es el contexto, más grande es el KV Cache. Un KV Cache mayor presiona VRAM, ancho de banda de memoria, tiempo al primer token y throughput.

DeepSeek-V4 es interesante porque no solo reduce caché en la dimensión de cabezas de atención. Lleva la compresión a la dimensión de longitud de secuencia. Según el análisis de Hugging Face sobre DeepSeek-V4, en un escenario de 1M tokens, el KV Cache de DeepSeek-V4-Pro es alrededor del 10% del de DeepSeek-V3.2, y alrededor del 2% de una arquitectura GQA bf16 común.

Esa es la diferencia clave: DeepSeek-V4 no solo guarda cada entrada KV en un formato más pequeño. Reduce la cantidad de entradas KV que deben conservarse y buscarse en una historia larga.

Varias generaciones de optimización de KV Cache

La optimización de KV Cache ha seguido varias rutas.

La primera es MHA tradicional, Multi-Head Attention. Cada cabeza Query suele tener sus propias cabezas Key/Value. La estructura es directa, pero en contextos largos la caché crece linealmente con la longitud de secuencia, generando mucha presión de VRAM.

La segunda es GQA, Grouped Query Attention. Varias cabezas Query comparten menos cabezas Key/Value. Muchos modelos modernos como LLaMA, Mistral y Qwen usan ideas similares. Reduce mucho el número de cabezas KV y hoy es una optimización común para contexto largo.

La tercera es MLA, Multi-head Latent Attention. DeepSeek-V2 y DeepSeek-V3 usan esta ruta, comprimiendo Key/Value en representaciones latentes de bajo rango y reduciendo aún más la caché en la dimensión de cabezas.

La cuarta es la atención comprimida híbrida de DeepSeek-V4. Se centra en la longitud de secuencia: no solo reduce cuánto KV guarda cada token, sino que comprime múltiples tokens históricos en menos entradas KV y las recupera mediante atención dispersa o densa.

En términos simples:

MHA: cada cabeza recuerda por separado.
GQA: varias cabezas Query comparten memoria.
MLA: la representación KV de cada token se comprime en un vector latente.
DeepSeek-V4: muchos tokens históricos se agregan en menos bloques de memoria comprimida.

Cambio clave: de comprimir cabezas a comprimir secuencia

GQA y MLA optimizan principalmente cuánto KV guarda cada token. Funciona bien, pero cuando el contexto llega a 1M tokens, el número de tokens se vuelve el problema principal.

DeepSeek-V4 comprime el contexto antiguo en bloques. El modelo no necesita preservar KV completo para cada token lejano. En su lugar, varios tokens forman entradas comprimidas.

Es parecido a leer un libro muy largo: recuerdas con detalle las páginas recientes, mientras que los capítulos anteriores quedan como resúmenes, temas y pistas importantes. La atención de DeepSeek-V4 sigue una división similar: conservar detalle cerca y usar representación comprimida lejos.

CSA: compresión 4x más recuperación dispersa

CSA significa Compressed Sparse Attention. Es el mecanismo de compresión de largo alcance de grano más fino.

En CSA, el modelo comprime tokens vecinos en menos entradas KV. La documentación de Hugging Face Transformers da una razón de compresión por defecto m=4, es decir, aproximadamente cada cuatro tokens forman una entrada comprimida.

No es un promedio simple. CSA usa un pool de compresión aprendido y ventanas solapadas para preservar información útil. Después de comprimir, la consulta no atiende a todos los bloques comprimidos directamente. Primero usa Lightning Indexer para puntuarlos, selecciona los bloques top-k más relevantes y luego realiza la atención principal.

Esto aporta dos beneficios:

El número de entradas KV históricas disminuye.
Cada consulta mira solo un subconjunto relevante de bloques comprimidos.

CSA encaja con contextos lejanos donde todavía importan detalles: bases de código, documentos largos e historiales de llamadas a herramientas.

HCA: compresión 128x más atención densa

HCA significa Heavily Compressed Attention, y es más agresivo.

La documentación de Transformers da una razón por defecto m'=128. HCA comprime un tramo mucho más largo de contexto en una sola entrada comprimida. Como la secuencia resultante ya es muy corta, no necesita recuperación dispersa top-k como CSA. La consulta puede hacer atención densa sobre todas las entradas HCA comprimidas.

HCA se parece más a un resumen global. No intenta conservar todos los detalles. Cubre una historia muy larga a costo muy bajo, ayudando al modelo a mantener conciencia de contexto global, temas de largo alcance e información lejana.

Si CSA es “notas comprimidas consultables”, HCA es más bien un “índice global y resumen”.

Ventana deslizante: el contexto reciente conserva detalle

DeepSeek-V4 no comprime todo.

Además de CSA y HCA, mantiene una rama de ventana deslizante para el contexto reciente sin comprimir. La documentación de Transformers indica que los attention blocks de DeepSeek-V4 concatenan ramas comprimidas de largo alcance con K/V de ventana deslizante.

Esto importa. Al generar el siguiente token, el contexto más cercano suele ser el más importante: nombres de variables, firmas de funciones, la frase actual, resultados recientes de herramientas o la última instrucción del usuario. Si se comprimiera demasiado, la calidad de salida caería.

La idea de DeepSeek-V4 es:

Cerca: conservar detalles sin comprimir.
Medio y largo alcance: usar CSA para compresión consultable.
Más lejos: usar HCA para resumen global muy comprimido.

Pila híbrida de capas: distintas capas usan distinta atención

DeepSeek-V4 no usa el mismo mecanismo de atención en todas las capas.

El artículo de Hugging Face sobre DeepSeek-V4 señala que la estructura de 61 capas de V4-Pro usa HCA en las dos primeras capas, alterna CSA y HCA después, y usa una sliding-window MTP block al final. La documentación de Transformers también describe V4-Pro como dos capas HCA bootstrap seguidas por capas alternas CSA/HCA.

Esto muestra que DeepSeek-V4 trata la atención como un sistema por capas. Algunas capas favorecen compresión global, otras recuperación dispersa, y otras conservan ventanas locales.

Es más complejo que usar un solo tipo de atención en todas partes, pero se ajusta mejor a contextos extremos de 1M tokens.

FP8 y FP4 reducen aún más el costo de caché

El ahorro de DeepSeek-V4 no viene solo de la razón de compresión.

El artículo de Hugging Face indica que la mayoría de entradas KV en V4 usan almacenamiento FP8, las dimensiones relacionadas con RoPE permanecen en BF16, y el Lightning Indexer de CSA usa FP4. La combinación de compresión, baja precisión y recuperación dispersa produce un uso muy bajo de KV Cache.

Esto recuerda algo importante: no basta mirar el número de longitud de contexto. La viabilidad de despliegue depende de VRAM, presión de ancho de banda, latencia y calidad de implementación bajo contexto largo.

Diferencias con otros modelos

Frente a MHA tradicional, DeepSeek-V4 ya no mantiene memoria de atención completa para cada token en una historia larga, así que la presión de caché cae mucho.

Frente a GQA, DeepSeek-V4 no solo reduce el número de cabezas KV. También reduce el número de entradas KV para historia larga. GQA sigue acumulando caché linealmente con la longitud de secuencia; V4 comprime el contexto lejano en bloques.

Frente al MLA de DeepSeek-V3, V4 extiende la optimización desde “hacer más compacta la representación de cada token” hacia “comprimir también la cantidad de entradas históricas”. MLA ya reduce mucho el costo KV por token, pero en contexto de millones de tokens la longitud de secuencia sigue siendo un cuello de botella.

Frente a atención dispersa ordinaria, CSA primero comprime y luego recupera de forma dispersa sobre una secuencia comprimida más corta. HCA va más lejos: con compresión 128x, incluso la atención densa resulta barata.

Qué significa para agentes y tareas largas

Los workflows de agentes consumen mucho contexto. Leen archivos, llaman herramientas, reciben resultados, generan planes, corrigen planes y vuelven a llamar herramientas. Cuanto más largo es el contexto, más probable es que KV Cache sea el cuello de botella.

El diseño de caché de DeepSeek-V4 puede ayudar en varias formas:

Manejar bases de código largas, documentos extensos e historiales de herramientas de muchas rondas.
Reducir presión sobre tiempo al primer token y throughput causada por KV Cache.
Ejecutar contextos más largos o más solicitudes concurrentes con el mismo hardware.
Acercar el contexto de un millón de tokens a un despliegue práctico, no solo a un número de benchmark.

Pero la atención comprimida no es gratis. Comprimir tokens históricos en bloques implica elegir qué información se conserva. El modelo debe equilibrar ahorro de VRAM con retención de detalles recuperables. El rendimiento real depende de la tarea: navegación de código, documentos legales, QA largo y toolchains de agentes tienen necesidades distintas de recuperación de detalles.

No leas 2% como 2% de todo el costo

“KV Cache alrededor del 2% de GQA” puede malinterpretarse.

Se refiere principalmente al tamaño de memoria de KV Cache. No significa que el costo total de inferencia caiga al 2%, ni que todos los escenarios sean 50 veces más rápidos. La inferencia también incluye lectura de pesos, enrutamiento MoE, redes feed-forward, cómputo de atención, scheduling y comunicación.

El artículo de Hugging Face separa dos números: en contexto de 1M tokens, los FLOPs por token de DeepSeek-V4-Pro son 27% de DeepSeek-V3.2, mientras que KV Cache es 10%. Caché y cómputo son dimensiones distintas.

La afirmación más segura es: DeepSeek-V4 reduce mucho la presión de KV Cache en contexto ultralargo, mejorando la viabilidad de despliegue en escenarios de un millón de tokens. Latencia y throughput reales dependen de implementación, hardware, batching, cuantización y framework de inferencia.

Resumen

La mayor diferencia entre DeepSeek-V4 y otros modelos grandes es que mueve la optimización de KV Cache desde la dimensión de cabezas de atención hacia la dimensión de longitud de secuencia.

GQA guarda menos cabezas KV. MLA hace más compacta la representación KV de cada token. DeepSeek-V4 además agrega tokens lejanos en bloques comprimidos y combina CSA, HCA, ventanas deslizantes y almacenamiento de baja precisión, para que el contexto de un millón de tokens no quede bloqueado de inmediato por KV Cache.

No es un truco único. Es una arquitectura de inferencia para contexto largo: conservar detalles cerca, comprimir lo lejano, recuperar detalles cuando hacen falta y resumir globalmente cuando es posible.

Para desarrolladores y aplicaciones de agentes, el significado es directo: contexto largo no es solo aceptar más entrada. Debe poder ejecutarse, ser estable y tener costo aceptable. Eso es lo que DeepSeek-V4 cambia.

Referencias

Filtración de Gemini 3.5 Pro: con nombre en clave Cappuccino, Google intenta recuperar ritmo en coding y agentes

Sun, 17 May 2026 11:47:27 +0800

Google todavía no ha lanzado oficialmente Gemini 3.5 Pro.

La información disponible por ahora proviene sobre todo de capturas de comunidades de desarrolladores, benchmarks anónimos, filtradores y reportes de medios. El 15 de mayo de 2026, 36Kr / Xinzhiyuan publicó que un checkpoint de la próxima generación de Gemini podría tener el nombre interno Cappuccino, y que modelos relacionados ya habrían aparecido en comunidades y plataformas de evaluación.

Esta información no debe tratarse como un lanzamiento oficial, pero sí muestra una dirección clara: Google intenta cubrir dos brechas a la vez, coding y razonamiento por un lado, y agentes de IA always-on por el otro.

Conclusión rápida

Esta filtración puede leerse en tres capas:

Gemini 3.5 Pro aún no ha sido lanzado oficialmente, y Cappuccino parece más un checkpoint interno o una build candidata.
La información filtrada sugiere que el nuevo Gemini mejora en generación de código, generación SVG / web interactiva y salida multimodal.
La prueba paralela de Gemini Spark por parte de Google puede ser más importante que el modelo en sí, porque apunta a un agente personal de IA funcionando 24 horas.

En otras palabras, no es solo una historia de benchmarks. Parece más una señal de roadmap antes de Google I/O: el modelo necesita alcanzar a GPT-5.5, mientras la capa de agentes necesita capturar flujos de trabajo de usuarios.

Qué es Cappuccino

El artículo de 36Kr menciona que, según una publicación de Lentils, el checkpoint de Gemini 3.5 Pro con nombre en clave Cappuccino ya habría empezado a producirse. La comunidad todavía hablaba de Gemini 3.2 horas antes, pero la filtración más reciente saltó directamente a 3.5.

Si ese nombre termina siendo correcto, Google podría querer presentar el próximo Gemini como un salto de versión más grande, no como una actualización menor.

Por ahora, Cappuccino debe tratarse como un nombre interno filtrado. No significa que Google haya lanzado públicamente el modelo final, ni garantiza que el nombre de lanzamiento vaya a ser Gemini 3.5 Pro.

Por qué el coding es el foco

La parte más comentada de la filtración es la capacidad de coding del nuevo Gemini.

Según capturas y supuestos benchmarks citados por 36Kr, el nuevo modelo parece más fuerte en:

Generación de SVG y componentes visuales.
Generación de aplicaciones web interactivas.
Manejo de animación, 3D, paneles de parámetros ajustables y otras salidas frontend complejas.
Mejoras en razonamiento lógico y generación de código.

El artículo también cita a Bindu Reddy, CEO de Abacus.AI, diciendo que 3.2 Flash se acerca a GPT-5.5 en coding y razonamiento, con un coste mucho menor. Otras fuentes de medios creen que el nuevo Gemini se ubica aproximadamente en el nivel de GPT-5.5, aunque quizá no represente un salto cualitativo.

Por eso conviene leer con cautela la frase “alcanza a GPT-5.5”. Se parece más a un juicio relativo basado en filtraciones y pruebas anónimas que a un resultado oficial de benchmark de Google.

Por qué Google necesita ponerse al día en coding

El AI coding pasó de ser una categoría de herramientas para desarrolladores a ocupar el centro de la competencia entre modelos fundacionales.

OpenAI tiene Codex y Anthropic tiene Claude Code. No solo sirven a ingenieros: también llevan a product managers, diseñadores y equipos de operaciones a flujos donde el lenguaje natural produce productos ejecutables.

En comparación, Google tiene Gemini y Antigravity, pero no ha logrado formar el mismo punto de entrada predeterminado en la mente de los desarrolladores. El artículo de 36Kr también señala que Antigravity no ha logrado despegar claramente en el mercado externo, y que precios, avisos de cuota y estabilidad de experiencia han generado discusión en la comunidad.

Así que, si el nuevo Gemini necesita demostrar algo, coding será el campo de batalla más directo. La pregunta no es solo si puede escribir código, sino si puede producir interfaces completas de forma estable, entender requisitos complejos, llamar herramientas, corregir errores e integrarse en flujos reales de desarrollo.

Spark puede importar más que 3.5 Pro

En la misma ola de filtraciones también apareció Gemini Spark BETA.

Según TestingCatalog y otras fuentes, Spark se posiciona como un agente de IA always-on: puede procesar la bandeja de entrada, ejecutar tareas online, gestionar flujos de varios pasos y conectar contexto de apps de Google, módulos de habilidades, historial de chats, tareas programadas, sitios con sesión iniciada e información de ubicación.

Eso significa que Spark no es una entrada de chat normal. Podría ser un sistema que permanece online, lee contexto de forma continua y ejecuta tareas por el usuario.

El atractivo es obvio: si Google puede conectar Gmail, Calendar, Chrome, Android, Workspace y Gemini, Spark tendrá una ventaja de distribución difícil de copiar para OpenAI y Anthropic.

El riesgo también es obvio. El artículo de 36Kr menciona una descripción de Spark según la cual podría compartir información o completar compras sin preguntar. Aunque el sistema esté diseñado para pedir permiso antes de operaciones sensibles, este tipo de agente sigue planteando riesgos de privacidad, límites de autorización y acciones accidentales.

Qué significa para usuarios comunes

Si eres un usuario normal de Gemini, lo más importante de esta filtración no es el nombre del modelo, sino tres cambios.

Primero, Google puede seguir reforzando la capacidad de producir resultados completos. Antes, usuarios se quejaban de que Gemini podía ser perezoso en generación visual, SVG y páginas frontend. Si el nuevo modelo puede generar varias propuestas completas en una sola pasada, la experiencia mejorará de forma visible.

Segundo, la capacidad de coding seguirá bajando a modelos más ligeros. La filtración menciona varias veces mejoras de Flash en coding, razonamiento y generación interactiva, lo que significa que en el futuro no siempre hará falta un modelo Pro para tareas complejas.

Tercero, los agentes serán más proactivos. Si Spark se lanza, Gemini podría dejar de limitarse a responder preguntas y empezar a asumir correo, web, compras, calendario y tareas entre apps durante periodos largos.

Eso es bueno para la eficiencia, pero crea un nuevo desafío de gestión de permisos.

Qué significa para desarrolladores

Los desarrolladores deberían vigilar dos cuestiones.

La primera es el ecosistema de herramientas. El artículo de 36Kr dice que la comunidad vio una entrada no publicada llamada MCP Tool Testing en el selector de modelos. Si Gemini soporta MCP o pruebas de herramientas de terceros de forma nativa, será más fácil conectarlo a las toolchains propias de los desarrolladores.

La segunda es coste y estabilidad. Aunque el nuevo Gemini alcance a GPT-5.5 en algunos benchmarks, los desarrolladores acabarán mirando tres cosas: calidad real del código, estabilidad del contexto, y si precios y cuotas son predecibles.

El último año de competencia en herramientas de AI coding ha demostrado que la capacidad del modelo es solo el billete de entrada. Lo que retiene a los desarrolladores es si la herramienta puede editar código, ejecutar tests, leer contexto y manejar casos límite de forma fiable en proyectos diarios.

Cómo leer esta noticia ahora

Esta noticia se entiende mejor como “señal fuerte, confirmación débil”.

La señal fuerte es que múltiples pistas comunitarias apuntan a que Google prepara un Gemini más fuerte y un Gemini Spark Agent más proactivo.

La confirmación débil es que Gemini 3.5 Pro aún no ha sido lanzado oficialmente, Cappuccino sigue siendo un nombre filtrado, y la afirmación de que “alcanza a GPT-5.5” necesita validación con benchmarks oficiales de Google, pruebas de terceros y experiencia real de usuarios.

La lectura más prudente por ahora:

No tratarlo como un producto ya lanzado.
Tratarlo como una vista previa temprana de la próxima dirección de Gemini.
Observar si I/O u otros eventos oficiales confirman el nombre del modelo, disponibilidad de API, precios, ventana de contexto, tool calling y límites de permisos del agente.

Resumen

La exposición de Gemini 3.5 Pro / Cappuccino sugiere que Google podría estar preparando un empuje más fuerte para la próxima generación de Gemini. No intenta corregir una sola capacidad aislada, sino todo un flujo de trabajo de IA: el modelo debe escribir mejor código, generar interfaces y manejar razonamiento complejo, mientras Spark empuja Gemini hacia un agente always-on.

Pero antes de un lanzamiento oficial, todos los benchmarks y capturas siguen siendo pistas. Lo que decidirá si Gemini 3.5 Pro puede recuperar impulso no será si el nombre en clave suena bien, sino si puede ganar de forma fiable en desarrollo real, trabajo de oficina real y tareas reales de varios pasos.

Referencias:

Claude Opus 4.7, Sonnet 4.6 y Haiku 4.5: diferencias y guía para elegir modelo

Fri, 08 May 2026 08:19:03 +0800

Los modelos grandes principales de Anthropic evolucionan sobre todo a través de la serie Claude. A mayo de 2026, la línea principal de Claude ya está en la etapa 4.x, pero mantiene una estructura de tres niveles: Opus se centra en la máxima capacidad, Sonnet equilibra rendimiento y costo, y Haiku prioriza velocidad y relación costo-beneficio.

Si solo quieres una regla rápida para elegir, recuerda esto:

Para el razonamiento más complejo y pesado, y para agentic coding: mira primero Claude Opus 4.7.
Para la mayoría de escenarios de desarrollo, escritura, análisis y API empresariales: empieza por Claude Sonnet 4.6.
Para tareas de alta concurrencia, baja latencia y sensibilidad al costo: considera Claude Haiku 4.5.

Modelos principales actuales

Según la documentación oficial de modelos de Anthropic, los modelos principales actuales de Claude pueden entenderse así.

Modelo	Posicionamiento	Escenarios adecuados
`Claude Opus 4.7`	El modelo general disponible más potente actualmente, orientado a razonamiento complejo y agentic coding	Refactorización de grandes bases de código, tareas de varios pasos, análisis estratégico complejo, trabajos que requieren mayor consistencia
`Claude Sonnet 4.6`	El punto de equilibrio entre velocidad, capacidad y costo, con una ventana de contexto de 1 millón de token	Generación de código, análisis de documentos largos, trabajo de conocimiento empresarial, desarrollo de Agent, tareas diarias de producción de alta calidad
`Claude Haiku 4.5`	El nivel de modelo pequeño más rápido y de menor costo, pero aún con capacidades cercanas a modelos de frontera	Conversación en tiempo real, soporte al cliente, clasificación por lotes, colaboración simple con código, llamadas API de alta concurrencia

Aquí conviene prestar atención a dos detalles de nombres.

Primero, el nombre oficial es Claude Haiku 4.5, no Claude 4.5 Haiku. Segundo, Claude Mythos Preview no es un modelo principal disponible para usuarios comunes o desarrolladores. Es una vista previa de investigación controlada relacionada con Project Glasswing, orientada principalmente a flujos defensivos de ciberseguridad, y no debería mezclarse con la selección habitual de modelos Claude.

Opus: para los problemas más difíciles

Opus es el nivel que Anthropic usa para sus modelos más potentes. El punto de Claude Opus 4.7 no es ser barato ni ser el más rápido, sino ser más adecuado para tareas complejas, de varios pasos, que requieren verificación repetida.

Encaja mejor en estas situaciones:

Cambios grandes de código en muchos archivos.
Refactorización de sistemas complejos y razonamiento arquitectónico.
Tareas Agent de cadena larga.
Trabajo que requiere mayor comprensión visual, comprensión documental y planificación de varias rondas.
Tareas de análisis empresarial donde el costo del error es alto.

Si el costo de que una tarea falle una vez es alto, o si quieres que el modelo dedique más tiempo a entender el contexto antes de actuar, normalmente vale más la pena probar Opus.

Sonnet: el punto de partida predeterminado para la mayoría

Claude Sonnet 4.6 es un modelo más adecuado como entrada predeterminada. Su posicionamiento no es ser un “Opus de gama baja”, sino poner razonamiento, programación, comprensión visual, contexto largo y agent planning suficientemente fuertes dentro de un perfil de costo y velocidad más controlable.

Para desarrolladores, el valor de Sonnet 4.6 está principalmente en tres puntos:

Puede manejar contextos muy largos, por lo que sirve para bases de código, contratos, informes o varios documentos.
Es más fácil usarlo como modelo habitual en Claude Code, API y escenarios empresariales.
Cuesta menos que Opus, así que encaja mejor con el uso frecuente.

Si no sabes con qué modelo Claude empezar, normalmente puedes empezar por Claude Sonnet 4.6. Solo cuando la tarea necesite claramente más capacidad conviene cambiar a Opus.

Haiku: cuando importan más la velocidad y el costo

Claude Haiku 4.5 es el nivel de modelo pequeño, pero no debe entenderse simplemente como un “modelo débil”. Anthropic lo posiciona como rápido y de bajo costo, manteniendo al mismo tiempo capacidades cercanas a modelos de frontera.

Es adecuado para estos escenarios:

Chat en tiempo real y bots de soporte al cliente.
Clasificación masiva de textos cortos.
Llamadas API de baja latencia.
Cambios simples de código y prototipos rápidos.
Ejecución de subtareas en flujos con múltiples Agent.

Si la tarea es clara, el contexto no es complejo y el rendimiento por volumen importa, Haiku suele ser más razonable que usar a ciegas un modelo más grande.

Capacidades de herramientas de Claude

La serie Claude no es solo un conjunto de modelos de chat. Anthropic ahora integra sus capacidades de modelo en varios productos y herramientas para desarrolladores.

Claude Code es una herramienta de programación de línea de comandos para desarrolladores. Puede leer bases de código, editar archivos, ejecutar comandos y correr pruebas, por lo que sirve para avanzar de forma continua en tareas de ingeniería. Su experiencia depende mucho de la comprensión de código del modelo, la gestión de contexto y la estabilidad en llamadas a herramientas.

Computer Use permite que el modelo opere un entorno de escritorio mediante capturas de pantalla, mouse y teclado. Todavía debe usarse con cautela, y la documentación oficial también enfatiza ejecutarlo en un entorno aislado para evitar errores de operación o riesgos de seguridad.

Artifacts está más orientado a la experiencia dentro de la aplicación Claude. Puede colocar código, prototipos de páginas, gráficos o documentos en la interfaz para previsualizarlos e iterarlos. No es un modelo independiente, sino una parte de la forma de producto de Claude.

En cuanto a expresiones como “Managed Agents” o “Agent autoevolutivos”, conviene ser prudente al escribir. Anthropic sí está reforzando Agent SDK, Claude Code, contexto largo, llamadas a herramientas y flujos empresariales, pero no hay que describirlo como si ya tuviera capacidades de autoevolución no controlada.

Formas de acceso

Los usuarios comunes pueden usar Claude desde la web de Claude.ai o desde aplicaciones móviles. Los distintos planes afectan los modelos disponibles, las cuotas y las funciones.

Los desarrolladores suelen tener varias formas de integración:

Anthropic Console y Claude API.
Amazon Bedrock.
Google Cloud Vertex AI.
Microsoft Foundry.

Los modelos disponibles, la ventana de contexto, los precios y el soporte regional pueden cambiar. Antes de desarrollar, conviene basarse en la documentación oficial de modelos de Anthropic y en las páginas de la plataforma en la nube correspondiente.

Cómo elegir

En el uso real, no hace falta perseguir el modelo más potente desde el principio. Una mejor forma es dividir la elección según el costo de la tarea.

Para escritura diaria, generación de código, análisis de documentos largos, organización de conocimiento y la mayoría de prototipos Agent, empieza con Claude Sonnet 4.6. Normalmente es el mejor punto de partida por relación costo-beneficio y capacidad general.

Si la tarea necesita razonamiento complejo más fuerte, cambios de ingeniería entre archivos, planificación de cadena larga o mayor confiabilidad, cambia a Claude Opus 4.7.

Si la tarea es simple, de gran volumen y sensible a la latencia, como clasificación, resumen, atención al cliente o procesamiento por lotes, incluye Claude Haiku 4.5 entre los candidatos.

La línea de modelos Claude no es simplemente una historia de “una nueva versión reemplaza a la anterior”. Es una caja de herramientas organizada por dificultad de la tarea, velocidad y costo. Elegir el modelo correcto importa más que usar a ciegas el modelo más caro.

Referencias

Anthropic Models Overview: https://platform.claude.com/docs/en/about-claude/models/overview
Introducing Claude Opus 4.7: https://www.anthropic.com/news/claude-opus-4-7
Introducing Claude Sonnet 4.6: https://www.anthropic.com/news/claude-sonnet-4-6
Introducing Claude Haiku 4.5: https://www.anthropic.com/news/claude-haiku-4-5
Anthropic Computer Use Tool: https://docs.anthropic.com/en/docs/build-with-claude/computer-use

GPT-5.5 Instant llega: el modelo predeterminado de ChatGPT se vuelve más preciso, breve y personal

Thu, 07 May 2026 14:28:40 +0800

OpenAI lanzó GPT-5.5 Instant el 5 de mayo de 2026 y comenzó a desplegarlo como modelo predeterminado para todos los usuarios de ChatGPT.

Las palabras clave de esta actualización no son “más grande” ni “más llamativa”. Están más cerca del uso diario: respuestas más precisas, respuestas más claras y cortas, un tono más natural y mejor uso del contexto que los usuarios ya compartieron. Para ChatGPT, los cambios en el modelo predeterminado importan especialmente porque afectan la experiencia que la mayoría de personas usa cada día.

Por qué importa el modelo predeterminado

Instant es el modelo diario de ChatGPT. Muchos usuarios no cambian manualmente de modelo ni estudian las diferencias entre ellos. Su experiencia de ChatGPT es la calidad del modelo predeterminado.

Por eso GPT-5.5 Instant no es solo otro nombre de modelo. Empuja hacia adelante la experiencia base. OpenAI dice que la actualización hace que las interacciones cotidianas sean más útiles y fluidas: mejores respuestas en distintos temas, conversaciones más compactas y mejor uso del contexto existente cuando corresponde.

Este tipo de mejora es menos dramático que un gran lanzamiento multimodal, pero para cientos de millones de usuarios, un modelo predeterminado que comete menos errores, escribe menos de más y hace menos preguntas de seguimiento inútiles es un gran cambio de producto.

Menos alucinaciones y respuestas más fiables

OpenAI coloca la precisión en primer lugar.

En evaluaciones internas, OpenAI dice que GPT-5.5 Instant produjo 52,5% menos afirmaciones alucinadas que GPT-5.3 Instant en prompts de alto riesgo sobre medicina, derecho y finanzas. En conversaciones especialmente difíciles que los usuarios habían marcado por errores factuales, las afirmaciones inexactas se redujeron 37,3%.

Estos números importan. Muestran que OpenAI no solo intenta hacer el modelo más fluido, sino que sigue reduciendo errores factuales. En áreas como medicina, derecho y finanzas, un modelo no puede limitarse a sonar convincente. Tiene que ser más cauteloso e inventar menos.

Esto no significa que los usuarios deban tratar ChatGPT como reemplazo de asesoramiento profesional. Un modelo más preciso aún necesita verificación, fuentes y juicio humano en contextos de alto riesgo. Pero como experiencia de producto, una mayor fiabilidad factual en el modelo predeterminado reduce muchos riesgos cotidianos.

Mejor rendimiento en tareas diarias

GPT-5.5 Instant también mejora en tareas diarias.

OpenAI menciona mejor análisis de fotos e imágenes subidas, respuestas STEM más fuertes y mejor criterio sobre cuándo usar búsqueda web. El último punto es importante. A muchos usuarios no les importa si internamente el modelo llama a una herramienta. Les importa que la respuesta sea actual, precisa y clara.

Si el modelo puede decidir mejor qué preguntas necesitan búsqueda web y cuáles se pueden responder directamente, los usuarios no tienen que repetir “búscalo”. ChatGPT se siente más como un asistente proactivo que como una caja de chat esperando instrucciones explícitas.

El ejemplo matemático de OpenAI también apunta en esa dirección. GPT-5.5 Instant acepta inicialmente una solución incorrecta, pero luego verifica el resultado, encuentra el error algebraico y resuelve la ecuación corregida. Lo importante no es que nunca se equivoque, sino que tiene más posibilidades de detectar y reparar un error durante el razonamiento.

Respuestas más cortas, no menos sustancia

OpenAI también enfatiza que GPT-5.5 Instant da respuestas más compactas y directas, manteniendo contenido útil y el tono amable de ChatGPT.

Esto importa para un modelo predeterminado. La fatiga con respuestas de IA muchas veces no viene de falta de información, sino de demasiada estructura, demasiada preparación y demasiado formato. Una pregunta simple puede convertirse en cinco encabezados y una docena de advertencias, lo cual se siente artificial.

GPT-5.5 Instant busca reducir la verbosidad y el exceso de formato innecesarios, hacer menos preguntas de seguimiento sin necesidad y evitar ruido decorativo. Para trabajo diario de oficina, consejos de escritura, preguntas de vida y explicaciones rápidas, estos cambios suelen importar más que una puntuación de benchmark.

Más corto no significa más superficial. Un buen modelo predeterminado debe juzgar si el usuario necesita una frase práctica, una explicación o un plan completo. GPT-5.5 Instant avanza hacia un criterio más estable en ese equilibrio.

La personalización sigue mejorando

Otro hilo principal es la personalización.

OpenAI dice que Instant ahora usa mejor, cuando está disponible, contexto de chats anteriores, archivos y Gmail conectado para hacer respuestas más relevantes. Decide cuándo la personalización extra puede mejorar una respuesta y busca conversaciones pasadas más rápido, para que los usuarios no tengan que repetir tanto contexto.

Esto es valioso para usuarios de ChatGPT de largo plazo. Al planificar, escribir, elegir herramientas, organizar proyectos o continuar un flujo de trabajo, los usuarios quizá ya dieron preferencias, restricciones y contexto en chats anteriores. Si el modelo puede continuar de forma natural, reduce explicaciones repetidas.

Pero la personalización debe venir con transparencia y control. De lo contrario, los usuarios no saben por qué el modelo menciona de repente una preferencia o qué memorias están dando forma a una respuesta.

Memory sources hace más visible la personalización

OpenAI también está introduciendo memory sources en todos los modelos de ChatGPT.

La función permite a los usuarios ver qué contexto se usó para personalizar una respuesta, como memorias guardadas o chats anteriores. Si algo está desactualizado, es inexacto o ya no se desea, los usuarios pueden eliminarlo o corregirlo.

OpenAI también dice que memory sources no se muestra a otras personas cuando los usuarios comparten un chat. Los usuarios pueden borrar chats que no quieren que se citen, editar memorias guardadas en configuración o usar chats temporales que no usan ni actualizan memoria.

Esto importa. Cuanto más personalizado se vuelve un asistente de IA, más necesita explicar “qué usé para responderte”. Memory sources quizá no muestre todos los factores, pero saca parte de la personalización de la caja negra.

Disponibilidad

GPT-5.5 Instant se despliega desde el día del anuncio para todos los usuarios de ChatGPT, reemplazando GPT-5.3 Instant como modelo predeterminado. En la API, corresponde a chat-latest.

Los usuarios de pago pueden seguir usando GPT-5.3 Instant durante tres meses mediante la configuración de modelos antes de que se retire.

La personalización mejorada desde chats anteriores, archivos y Gmail conectado se despliega primero para usuarios Plus y Pro en la web, con soporte móvil más adelante. OpenAI planea expandirla a Free, Go, Business y Enterprise en las siguientes semanas. Memory sources se despliega en la web para planes de consumo de ChatGPT y llegará a móvil después. La disponibilidad de fuentes específicas de personalización puede variar por región.

Resumen

GPT-5.5 Instant es una mejora de la experiencia predeterminada de ChatGPT.

No se trata solo de mayor capacidad del modelo. Ajusta precisión, densidad de respuesta, tono, uso de contexto y transparencia de personalización a la vez. Para usuarios comunes, el cambio más directo debería ser: menos relleno, menos errores factuales y mejor continuidad con su contexto.

Para OpenAI, es otro paso en la evolución del asistente predeterminado. ChatGPT se vuelve menos una herramienta que empieza de cero cada vez y más un asistente de largo plazo que puede recordar preferencias, entender contexto, saber cuándo buscar y dejar que los usuarios gestionen esas fuentes de memoria.

Enlaces

Anuncio de OpenAI: https://openai.com/index/gpt-5-5-instant/