Ideas que conectan.
Trabajo que avanza.

Qué cambia

Google Cloud anunció la incorporación de Claude Opus 5.5 y Sonnet 5.5 a Antigravity para sus clientes en una publicación fechada el 20 de octubre de 2026. El anuncio abarca Antigravity 2.0, CLI y extensiones de IDE. Anuncio de Google Cloud.

Para un equipo de desarrollo, la decisión práctica consiste en elegir qué modelo emplear, cómo comprobar sus cambios y qué consumo aceptar. La incorporación de más opciones permite plantear esas decisiones dentro del mismo entorno, pero su utilidad debe evaluarse con tareas y criterios propios.

Quién puede acceder

La matriz de modelos consultada distingue estos planes para ambos Claude 5.5. La inclusión en la matriz está sujeta a las condiciones del servicio. Disponibilidad por plan.

Para las herramientas empresariales, Google enumera Standard, Plus, Standard Emerging Market y Pay-as-you-go; exige una cuenta de facturación por factura, licencia y permisos de usuario. Claude está desactivado hasta que un administrador lo autoriza y acepta los términos del proveedor. Configuración empresarial.

Clientes, versiones y alcance regional

La documentación de extensiones incluye VS Code, Visual Studio 2026, JetBrains, Zed y Xcode. El soporte Enterprise de JetBrains, Zed y Xcode figura en Preview, un matiz relevante al planificar su adopción. Extensiones de IDE.

En Enterprise, Claude ofrece los niveles Low, Medium —predeterminado—, High y Max. La CLI permite cambiar de modelo con `/model`; ajustar el esfuerzo mediante `/effort` requiere la versión 1.2.11 o posterior. Los niveles superiores pueden consumir más tokens. Selección de modelos y niveles de esfuerzo.

La inferencia de estos modelos en las herramientas empresariales está documentada para las ubicaciones `global`, `us` y `eu`; las regiones nacionales no están admitidas. Esto no acredita acceso desde cualquier país ni disponibilidad en una cuenta concreta. Disponibilidad regional.

Facturación y límite mensual

En Standard y Plus, Claude se paga por consumo mediante Cloud Billing, fuera de la cuota incluida, y requiere habilitar excedentes. Configuración de modelos.

La guía de facturación aclara que los excedentes no se aplican a la edición Pay-as-you-go, donde todo el uso se factura por consumo. Permite fijar un límite mensual por proyecto para excedentes y consumo Pay-as-you-go. El corte puede tardar unos minutos y generar cargos por encima del límite. Configuración de excedentes y gasto.

Seleccionar Claude tampoco elimina todo consumo de Gemini: Antigravity mantiene modelos ligeros de Google para coordinación y resúmenes, que pueden generar cargos adicionales. Arquitectura de ejecución.

En los planes personales Pro y Ultra, las cuotas dependen de la capacidad y del trabajo realizado. El usuario puede permitir créditos adicionales al agotarlas; la documentación no ofrece un número universal de peticiones garantizadas. Planes y cuotas.

Precios de referencia y una tarifa sin confirmar

Como referencia de API, Anthropic publica 4 USD por millón de tokens de entrada y 20 USD de salida para Opus 5.5; para Sonnet 5.5, 2 USD de entrada y 10 USD de salida. Las operaciones de caché tienen tarifas propias. Ficha de Opus, ficha de Sonnet.

Estas cifras no confirman el precio aplicable dentro de Antigravity. Google remite a sus catálogos de SKUs de Opus y Sonnet, cuyos importes no pudieron recuperarse en esta consulta. Por tanto, queda sin verificar la tarifa específica y no puede calcularse aquí un coste total fiable por tarea.

Interpretación: una segunda revisión necesita evidencia

Google propone combinar una familia de modelos para implementar y otra para revisar, y emplear modelos rápidos en tareas auxiliares. El anuncio no aporta una comparación controlada de esos patrones en Antigravity. Patrones propuestos por Google.

Nuestra interpretación es que la revisión cruzada merece probarse cuando ofrece observaciones concretas que el equipo puede verificar. Dos respuestas coincidentes no bastan para acreditar que un cambio cumple los requisitos. La evaluación debería medir defectos detectados, falsas alarmas, tiempo de revisión y coste completo, manteniendo pruebas ejecutables y revisión humana como criterios de aceptación.

La elección de modelo también debería poder variar según la tarea. Una corrección localizada y una migración entre varios componentes pueden justificar configuraciones distintas; asignarlas de antemano a un modelo sería una hipótesis de trabajo, no un resultado demostrado.

Ejemplo propuesto: comparar una corrección de paginación

Este diseño es una propuesta editorial reproducible con datos sintéticos. No se ha ejecutado y no anticipa qué modelo obtendría mejores resultados.

• Preparar un repositorio de prueba con un fallo de paginación, registros ficticios y casos de aceptación para páginas vacías, límites y duplicados.
• Comparar tres condiciones: Sonnet implementa y se revisa; Opus implementa y se revisa; un modelo implementa y una familia distinta revisa.
• Mantener iguales el estado inicial, las herramientas, las instrucciones y el presupuesto de cada condición; registrar versiones y niveles de esfuerzo y repetir las tareas.
• Medir requisitos cumplidos, defectos confirmados, falsas alarmas, tiempo total, intervención humana y consumo facturado de todos los modelos utilizados.
• Aceptar cambios mediante pruebas y revisión del código. Si la revisión cruzada añade coste sin detectar defectos relevantes, ajustar su alcance antes de extenderla.