Antigravity CLI para vigilar comentarios de vídeo: configuración y datos reales

Cuando publicas un vídeo, las primeras 24 horas marcan el tono de los comentarios. Hay tres tipos que alguien debe ver pronto: las quejas, las preguntas de verdad y los comentarios que quedan fríos si nadie responde. En esta guía montamos una ronda de vigilancia con Antigravity CLI, el agente de terminal con el que Google sustituyó a Gemini CLI. El comando se llama agy. Cada pocas horas, un temporizador del sistema arranca agy -p, el agente trae los comentarios nuevos y escribe un informe corto.

Los datos salen del servidor MCP remoto de EveryInfra. Para YouTube usamos youtube/comments y youtube/video; para Bilibili, bilibili/comments, bilibili/danmaku y bilibili/video. La parte de datos la ejecutamos de verdad el 3 de noviembre de 2026, de las 00:17 a las 01:22 hora de Singapur. Hicimos tres rondas sobre dos vídeos con mucho movimiento: 20 llamadas cobradas y 0,01137 USD en total.

Antigravity CLI no está instalado en nuestra máquina de prueba: el mcp_config.json, la skill y los scripts de esta guía son ejemplos escritos a partir de la documentación oficial del 3 de noviembre de 2026, no resultados de ejecutar agy.

Algunas cifras de esta guía no aparecen en ninguna documentación. Un vídeo de YouTube con 23,6 horas y 1546 comentarios solo mostró las últimas 5 horas en sus 100 comentarios más nuevos, que es el máximo por llamada. Veintisiete minutos después, solo 9 de esos 100 eran nuevos. En Bilibili, un vídeo con menos de 3 horas y 4075 comentarios devolvió 3, 10 y 3 comentarios destacados en tres rondas. Una regla de palabras clave marcó 34 de 100 comentarios de YouTube, pero solo 13 merecían la atención del creador. Con una ronda cada 2 horas, un día cuesta 0,023 USD en la API y unos 0,103 USD de modelo a precio público de Gemini 3.8 Flash.

La tarea: qué debe encontrar una vigilancia de 24 horas

Casi ningún comentario de un vídeo nuevo exige hacer algo. Emojis, bromas, «primero» y charla de fans son la mayoría. La vigilancia sirve para encontrar la parte pequeña que sí exige acción y mostrarla en una pantalla. Quien lleva las redes debería leer el informe en el móvil en dos minutos, sin bajar por 1500 comentarios en YouTube Studio para encontrar tres problemas reales.

Elegimos dos vídeos en momentos distintos. El de YouTube es «GTA 6 on PC May be Coming Sooner than We Thought», del canal Linus Tech Tips (página del vídeo). Se publicó el 2 de noviembre a las 00:45 hora de Singapur. En nuestra primera consulta tenía 23,6 horas, 794.104 visualizaciones y 1546 comentarios.

El de Bilibili es el primer vídeo de la cuenta DeepSeek Harness, publicado el 2 de noviembre a las 21:28 hora de Singapur (página del vídeo). En la primera consulta tenía 2,9 horas, 225.698 visualizaciones, 4075 comentarios y 342 danmaku, los comentarios que pasan sobre la imagen. Un vídeo está al final de la ventana de 24 horas y el otro al principio.

Qué es Antigravity CLI y las cuatro funciones que usa esta tarea

Mucha gente que busca «antigravity cli» cree que es un nombre nuevo para Gemini CLI. Es otra herramienta. El 19 de mayo de 2026, el blog de desarrolladores de Google anunció el paso de Gemini CLI a Antigravity CLI para usuarios individuales (Google Developers Blog). La herramienta nueva quedó disponible ese mismo día para todos.

Desde el 18 de junio, Gemini CLI y las extensiones de Gemini Code Assist para IDE dejaron de atender a usuarios de Google AI Pro, Ultra y del plan gratuito. Las organizaciones con licencias empresariales de Gemini Code Assist o con claves de API de pago siguieron con acceso. El mismo calendario aparece en la discusión #27274 de GitHub.

Según el anuncio, el equipo reescribió la herramienta en Go y llamó agy al comando. Siguen las Agent Skills, los hooks, los subagentes y las extensiones, que ahora se llaman plugins. La CLI comparte el núcleo del agente con la aplicación de escritorio Antigravity 2.0. Para esta guía importan dos hechos.

El primero: Antigravity CLI es de código cerrado. El repositorio google-antigravity/antigravity-cli tiene instrucciones de instalación, notas de versión y discusiones, pero no código. Todo lo que contamos sobre su comportamiento sale de la documentación oficial y de las notas de versión.

El segundo: cambia muy rápido. La API de versiones de GitHub muestra 20 versiones entre la 1.3.0, del 2026-10-06, y la 1.4.12, del 2026-10-30 UTC (notas de la 1.4.12). Entre medias salieron la 1.4.0 el 2026-10-16, la 1.4.4 el 2026-10-21, la 1.4.8 el 2026-10-27 y la 1.4.10 el 2026-10-29. Es una versión cada uno o dos días.

Antes de copiar cualquier ejemplo, compara tu agy --version con la documentación del día.

Configuración MCP de Antigravity CLI: dónde va mcp_config.json y qué lleva

Antigravity CLI saca los servidores MCP del archivo principal de ajustes y los lleva a mcp_config.json. El archivo global es ~/.gemini/config/mcp_config.json; el de un proyecto va en .agents/mcp_config.json, en la raíz del proyecto (guía de migración, «MCP config formatting changes»). La clave de dirección de un servidor remoto pasó de url o httpUrl en Gemini CLI a serverUrl, aunque la documentación MCP dice que url también funciona.

La autenticación va en headers personalizados. enabledTools es una lista blanca: el agente no ve ninguna otra herramienta de ese servidor. timeoutSeconds usa por defecto 300 segundos para conectar y 180 por cada llamada a herramienta (documentación MCP, «MCP configuration properties»). Este es el ejemplo para el proyecto de vigilancia, en .agents/mcp_config.json:

{
  "mcpServers": {
    "everyinfra": {
      "serverUrl": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer <tu clave de API de EveryInfra>" },
      "enabledTools": ["everyinfra_call_api", "everyinfra_get_job", "everyinfra_list_capabilities"],
      "timeoutSeconds": 120
    }
  }
}

Cada línea es una decisión. Dejamos solo tres herramientas en enabledTools. A las 00:22 hora de Singapur del 3 de noviembre, una llamada tools/list sin clave mostró 12 herramientas en el servidor MCP de EveryInfra. Varias, como la consulta de cuenta o los tickets de soporte, no tienen nada que ver con la vigilancia. Las herramientas de más ocupan contexto y le dan al modelo una opción equivocada más.

Bajamos timeoutSeconds a 120 en vez de 180. Nuestra llamada síncrona más lenta tardó 70,48 segundos: 50 comentarios de YouTube ordenados por popularidad. Si una llamada puede pasar de 85 segundos, añade "mode":"async" a la petición y consulta el resultado con everyinfra_get_job, que no se cobra. No sigas subiendo el tiempo de espera.

La clave es la línea más delicada. El ejemplo oficial de servidor remoto pone Bearer YOUR_API_TOKEN directamente en headers, y la documentación no dice que headers expanda ${VARIABLE}. La documentación antigua de Gemini CLI sí admitía $VAR_NAME y ${VAR_NAME} en las cabeceras (documentación MCP de Gemini CLI). Un usuario de Reddit cuenta que Antigravity envía ${MY_VAR} como texto literal (hilo en r/google_antigravity).

Mientras la documentación no diga otra cosa, supón que no hay expansión. Pon la clave en el archivo global y deja que solo tu usuario pueda leerlo. Otra opción es mantener el archivo del proyecto y añadir .agents/mcp_config.json a .gitignore. Nunca lo subas al repositorio.

El segundo archivo es el de permisos. La documentación MCP explica que una herramienta MCP sin regla pide confirmación («Ask») en cada llamada. Las reglas de permiso tienen la forma mcp(servidor/herramienta) o mcp(servidor/*) (documentación MCP, permisos; documentación de permisos). En modo sin interfaz nadie confirma nada, así que las reglas van por adelantado en ~/.gemini/antigravity-cli/settings.json:

{
  "permissions": {
    "allow": [
      "mcp(everyinfra/everyinfra_call_api)",
      "mcp(everyinfra/everyinfra_get_job)",
      "mcp(everyinfra/everyinfra_list_capabilities)",
      "write_file(reports/)"
    ]
  }
}

No usamos mcp(everyinfra/*) ni --dangerously-skip-permissions. Una lista blanca por nombre es más segura que un comodín: si el servidor añade una herramienta, la regla por nombre no la cubre. Otro usuario de Reddit tropezó justo aquí. El servidor MCP aparecía conectado, pero el agente decía que no podía usarlo, y la solución fue un permiso explícito en /permissions.

Ese mismo usuario encontró la configuración escrita en ~/.gemini/antigravity-cli/ en vez de ~/.gemini/config/ (r/google_antigravity, «Antigravity CLI MCP Servers Pain»). Después de configurar, abre la CLI interactiva una vez. Ejecuta /mcp para ver el estado del servidor y /permissions para ver las reglas. Solo cuando las dos cosas estén bien, pásale el trabajo a un temporizador.

Un viaje de ida y vuelta real: qué envía el agente y qué devolvemos

No pudimos ejecutar agy, pero lo que envía a un servidor MCP remoto son mensajes MCP estándar. Primero pide tools/list para el catálogo de herramientas y luego tools/call cuando lo necesita. La especificación MCP llama a este transporte Streamable HTTP: el cliente hace POST de un mensaje JSON-RPC y el servidor responde con JSON o con un flujo SSE (especificación MCP 2026-07-28, «Transports»). Así que nos saltamos el cliente y mandamos la misma petición al MCP de EveryInfra: lo que vemos es la respuesta cruda que el servidor da al agente. Lo que el agente lee al final todavía pasa por la CLI; por ejemplo, las notas de la 1.4.7 dicen que los resultados de más de 10 KB se guardan en un archivo. Esa capa no la probamos.

A las 00:45:27 hora de Singapur del 3 de noviembre enviamos este tools/call, con clave, para pedir los 100 comentarios más nuevos del vídeo de YouTube:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "everyinfra_call_api",
    "arguments": {
      "platform": "youtube",
      "action": "comments",
      "params": {
        "url": "https://www.youtube.com/watch?v=g9IOdTisQyM",
        "sort": "newest",
        "limit": 100
      }
    }
  }
}

El servidor respondió HTTP 200 a los 30,99 segundos. MCP envuelve el resultado en result.content[0].text como una cadena JSON de 33.915 bytes. Dentro están platform, action, count, results y billing; count valía 100 y billing.charged_usd, 0,000556. El primer comentario tenía 3 minutos: un espectador listaba su propio PC y decía que el «PC de jugador medio» del programa era demasiado potente. El segundo, de hace 9 minutos, contaba que había terminado un remake con un emulador.

La captura de abajo muestra la respuesta real con dos filas. Los nombres de usuario están ocultos y el texto, recortado.

Ten en cuenta ese tamaño al configurar. Las notas de Antigravity CLI 1.4.7 dicen que los resultados MCP bajo demanda de hasta 10 KB llegan directos al agente (notas de la 1.4.7). Los más grandes se guardan en un archivo y el agente lo lee en un paso extra. Una página de 100 comentarios pesa unos 33 KB, así que siempre va a archivo. Para la vigilancia es bueno: la respuesta en bruto debe quedar en disco de todos modos, y la skill le pide al agente que pase ese archivo a dedupe.py en vez de meter 33 KB de JSON en el contexto.

También puedes saltarte MCP y usar la API REST, por ejemplo si tu script trae los datos antes de despertar a agy. Usamos esta vía en las rondas 1 y 3; el arreglo results tiene la misma forma que dentro de la respuesta MCP:

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"youtube","action":"comments","params":{"url":"https://www.youtube.com/watch?v=g9IOdTisQyM","sort":"newest","limit":100}}' \
  > youtube-$(date +%Y%m%d-%H%M).json

Nuestra recomendación: empieza con MCP para ver cómo queda un buen informe y, cuando esté estable, mueve la descarga y la deduplicación a un script y deja al modelo solo el juicio (el porqué está en la sección del prefiltro).

Los errores también forman parte del viaje. Enviamos a bilibili/comments un parámetro sort que no admite. A las 00:21:33 hora de Singapur recibimos HTTP 422 con unknown_param. El mensaje listaba los parámetros permitidos, url y limit, y terminaba con «Nothing was charged.». Un modelo puede leer ese mensaje y reintentar sin el parámetro sobrante.

Un fallo del servidor se ve distinto. En la ronda 3, a las 01:22:15 hora de Singapur, la llamada de danmaku devolvió HTTP 503 con fault en service: el fallo era del servidor, no de la petición. La respuesta traía retryable en true y retry_after de 20 segundos, y next_steps decía que no se cobró y que era el fallo 1 de 3. Repetimos la misma petición 23 segundos después y llegó un 200 con 100 danmaku, cobrado a 0,000556 USD. Tu script debe seguir esos campos: esperar retry_after, parar en max_retries y escribir «faltan los danmaku de Bilibili en esta ronda» en el informe, no «sin danmaku nuevos».

Para otras formas de conectar un servidor MCP remoto, mira la guía del servidor MCP y la Documentación.

Vigilar comentarios de YouTube: 100 por llamada y cuánto tiempo cubren

El intervalo entre rondas depende de una cifra práctica: si los comentarios nuevos entre dos rondas superan lo que trae una llamada. El catálogo describe youtube/comments con 20 filas por defecto y un máximo de 100. Los parámetros opcionales son sort (newest o popular) y since (filtro por fecha). Los campos son id, text, author_name, like_count, reply_count, posted_at, is_reply y reply_to_id. No hay parámetro de página, así que 100 filas es todo lo que ve una ronda.

La ronda 1 corrió a las 00:18 hora de Singapur. El vídeo tenía 23,6 horas y 1546 comentarios. Pedimos los 100 más nuevos y la llamada tardó 22,2 segundos. La fila más nueva decía «1 minute ago» y la más antigua, «5 hours ago». Al final del primer día, 100 filas cubrían solo las últimas 5 horas.

Tres filas eran respuestas (is_reply verdadero) y cuatro llevaban el sufijo «(edited)». Si das la vuelta a la cuenta, el vídeo seguía ganando unos 20 comentarios por hora entre las horas 18 y 23. Con una ronda cada 6 horas, algunos comentarios caerían entre dos consultas y nunca aparecerían.

Pasado el primer día, los comentarios seguían llegando a un ritmo estable, de unos 20 a 45 por hora.

En la ronda 2, a las 00:45 hora de Singapur y 27 minutos después de la anterior, el vídeo tenía 1557 comentarios, 11 más. De los 100 más nuevos, 9 eran nuevos y 91 ya los habíamos visto. Las 100 filas seguían cubriendo solo las últimas 5 horas.

En la ronda 3, a las 01:20 hora de Singapur y 35 minutos después de la anterior, el vídeo tenía 1583 comentarios, 26 más. De los 100 más nuevos, 18 no aparecían en ninguna de las dos rondas anteriores y 82 ya los habíamos visto; frente a la ronda 2 sola, 19 eran nuevos y 81 coincidían. Las 100 filas seguían cubriendo solo las últimas 5 horas.

Las filas nuevas son menos que el aumento del total. Las respuestas explican parte de la diferencia: la ronda 1 tenía 3 respuestas entre los 100 más nuevos, la ronda 2 ninguna y la ronda 3 una. Comentarios ocultos o plegados pueden explicar el resto. Anota las dos cifras en cada ronda y señala cualquier diferencia en el informe.

El parámetro sort se pasa por alto con facilidad. En el mismo momento pedimos también 50 comentarios por popularidad, y esa llamada tardó 70,48 segundos, la más lenta de todas las síncronas. Los 50 populares y los 100 más nuevos no compartían ninguna fila. En el grupo popular, 30 filas eran respuestas, las etiquetas iban de «9 minutes ago» a «23 hours ago» y el comentario principal tenía 3500 me gusta.

La tarea principal de la vigilancia es no perder comentarios nuevos, así que cada ronda usa newest. El orden popular responde otra pregunta una vez al día: qué comentarios marcan el tono ahora mismo. El campo posted_at es una etiqueta relativa como «N hours ago», no una marca de tiempo. Tu script debe anotar la hora de la consulta y convertir cada etiqueta en una ventana. Para quitar duplicados, usa solo el id del comentario, nunca la hora.

Nuestra recomendación para YouTube: una ronda por hora durante las primeras 6 horas y luego una cada 2 horas. Si una ronda encuentra exactamente 100 filas nuevas, escribe «esta ronda pudo perder comentarios» en la primera línea del informe y adelanta la siguiente ronda. Esa regla ya está en el árbol de decisión de la skill de la sección siguiente. Todos los campos y parámetros están en la API de comentarios de YouTube; los totales de comentarios y visualizaciones salen de la API de vídeo de YouTube.

Bilibili: solo comentarios destacados, y los danmaku como segunda señal

La muestra de Bilibili es un vídeo recién subido. La cuenta DeepSeek Harness publicó su primer vídeo el 2 de noviembre a las 21:28 hora de Singapur, con 200 segundos de duración. En nuestra primera consulta de bilibili/video, a las 00:20, tenía solo 2,9 horas. Ya sumaba 225.698 visualizaciones, 22.070 me gusta, 4075 comentarios y 342 danmaku. Un vídeo que explota en sus primeras horas es justo cuando más importa vigilar.

Sin embargo, bilibili/comments devolvió solo 3 comentarios a las 00:21, en 1,26 segundos. Los tres eran destacados, con entre 48 y 212 me gusta. Se publicaron entre 3 y 131 minutos después del vídeo. En la ronda 2, a las 00:46, la misma petición devolvió 10, que es el máximo. Siete eran nuevos para nosotros, con entre 23 y 1100 me gusta. En esos 25 minutos el total de comentarios pasó de 4075 a 4566: 491 más, o más de mil por hora. En la ronda 3, a las 01:22, con limit otra vez en 10, devolvió solo 3, y ya habíamos visto los tres.

El catálogo es claro con este endpoint: 10 por defecto, 10 como máximo, y un valor mayor se recorta. Los únicos parámetros son url y limit. Probamos sort y obtuvimos el error 422 descrito antes, sin cobro. Este endpoint no da los comentarios más nuevos en orden de tiempo. Da como mucho los 10 comentarios más destacados en ese momento, y la cantidad varía.

Aun así es útil, porque los comentarios destacados forman la primera impresión. Un comentario destacado negativo es prioridad máxima. Pero no sustituye leer cada comentario nuevo. El informe debe decir «Bilibili: 10 comentarios destacados vistos de 4566», para que nadie suponga que se leyó todo.

Los danmaku son la segunda señal. bilibili/danmaku trae 50 filas por defecto y 200 como máximo. Pedimos 200 y llegaron 100, ordenados por tiempo del vídeo desde el segundo 0 hasta el 98: solo la primera mitad de un vídeo de 200 segundos. Se enviaron entre las 21:35 y las 00:19 hora de Singapur. Nuestra regla de palabras clave marcó 29 como preguntas. Pero 15 de esas 29 eran vítores con signos de interrogación, del tipo «¿¡La ballena!? ¿De verdad está en directo?».

El contenido real estaba en unos pocos más. Cuatro danmaku preguntaban por un «modo supervivencia», uno buscaba una app de escritorio y otro preguntaba si seguir a la cuenta regala tokens. Un signo de interrogación no es una pregunta, y menos en los danmaku.

El tema del modo supervivencia apareció también en los comentarios destacados de la ronda 2. Uno con 352 me gusta señalaba que el vídeo no menciona el modo supervivencia en ningún momento. Cuatro danmaku sueltos y un comentario destacado apuntan a lo mismo. Un buen informe los junta en una línea: los espectadores insisten con el modo supervivencia.

En la ronda 2, los danmaku volvieron a ser 100 filas que terminaban en el segundo 98. De ellos, 21 eran nuevos, y el total de danmaku pasó de 342 a 388. La ronda 3 volvió a parar en el segundo 98, con 16 nuevos y un total de 430. El endpoint devuelve los 100 primeros danmaku de la primera mitad del vídeo, así que un danmaku nuevo solo aparece si cae en esa parte de la línea de tiempo.

Si gestionas tu propia cuenta de Bilibili y necesitas todos los comentarios, usa el Creator Center o solicita acceso a la Bilibili Open Platform. Ese camino exige registro de desarrollador, una verificación de requisitos y la revisión de la app (Bilibili Open Platform), mucho más que la YouTube Data API. Para vídeos de la competencia, o si no quieres pasar por la plataforma abierta, acepta la vista «destacados más danmaku» y dilo en el informe. Los parámetros están en la API de comentarios de Bilibili y la API de danmaku de Bilibili; el resumen de cada plataforma, en las páginas de la API de YouTube y la API de Bilibili.

La vigilancia como skill: esqueleto de .agents/skills/comment-patrol/

En Antigravity, una skill es una carpeta con un archivo SKILL.md. En su cabecera YAML solo description es obligatoria; si no pones name, se usa el nombre de la carpeta. En cada turno el agente ve solo los nombres y descripciones de todas las skills y lee el texto completo cuando una parece relevante. La documentación lo llama revelación progresiva (documentación de Agent skills).

El formato sigue el estándar abierto Agent Skills (agentskills.io), así que otras herramientas compatibles pueden usar la misma skill con pequeños cambios de rutas. La documentación da dos consejos que encajan aquí: tratar los scripts como cajas negras y dejar que el agente ejecute --help primero, y escribir los flujos complejos como árboles de decisión.

.agents/
  mcp_config.json            # configuración MCP remota de arriba (fuera de Git)
  skills/
    comment-patrol/
      SKILL.md
      scripts/
        dedupe.py            # lee state/seen.json, deja solo filas nuevas, convierte "2 hours ago" en ventana
        prefilter.py         # prefiltro por palabras clave: pregunta, negativo, requiere respuesta
      resources/
        report.schema.json   # esquema de salida para --json-schema
state/
  seen-<ID del vídeo>.json   # IDs ya vistos, con la hora en que se vieron
reports/
  <ID del vídeo>-<ronda>.md

---
name: comment-patrol
description: Vigila los comentarios de YouTube y Bilibili durante las 24 horas posteriores a publicar un vídeo. Trae comentarios nuevos, quita duplicados, aplica el prefiltro y marca quejas, preguntas y comentarios que requieren respuesta. Úsala cuando pidan vigilar comentarios, seguir un lanzamiento o revisar la sección de comentarios.
---

# Vigilancia de comentarios

## En cada ronda
1. Lee `state/seen-<ID del vídeo>.json`. Créalo en la ronda 1.
2. Llama a everyinfra_call_api solo con estas capacidades:
   - YouTube: platform=youtube, action=comments, params={url, sort: "newest", limit: 100}
   - Bilibili: platform=bilibili, action=comments, params={url}; luego action=danmaku, params={url, limit: 200}
   - Cada 4 rondas: youtube/video y bilibili/video, para anotar cómo crece comment_count
3. Guarda cada respuesta tal cual en `data/<ronda>/`. Ejecuta `python3 scripts/dedupe.py --help` y úsalo para quedarte con lo nuevo.
4. Ejecuta `scripts/prefilter.py`. Juzga solo lo marcado como pregunta, negativo o requiere respuesta, y cualquier tema repetido.
5. Responde según `resources/report.schema.json`: category, severity, needs_reply y un borrador de dos frases como mucho. Nunca prometas precios ni fechas.

## Árbol de decisión
- Filas nuevas de YouTube = 100 (el máximo por llamada): se perdieron comentarios. Escribe «esta ronda pudo perder comentarios» en la línea 1 y sugiere acortar el intervalo.
- Cero filas nuevas: no llames al modelo. Escribe «sin comentarios nuevos».
- Reembolsos, seguridad, asuntos legales o privacidad: severity=high, sin borrador, a una persona.
- Solo emojis, «primero» o similar: descartar.

## Nunca
- Nunca publiques comentarios ni respuestas desde la cuenta. Esta skill solo lee.
- Nunca pongas nombres de usuario ni enlaces a perfiles en el informe. Usa solo IDs de comentario.

¿Por qué hacer la deduplicación y el prefiltro en scripts y no pedirle al modelo que cuente? Primero, por coste. La respuesta en bruto de 100 comentarios ronda los 8075 tokens; en la ronda 2 solo 9 filas eran nuevas, unos 505 tokens. Segundo, porque se puede auditar. Un script aplica reglas fijas y la misma entrada da la misma salida dos veces. El modelo queda para el paso que necesita entender el lenguaje.

La idea de report.schema.json viene de --json-schema en el modo sin interfaz. Según la documentación, la opción acepta la ruta de un archivo de esquema y el objeto resultante aparece en el campo structured_output del sobre de salida (Headless mode, «Structured output with a schema»). Tu script de temporizador lee solo ese campo y nunca tiene que sacar una tabla de texto libre.

Prefiltro: qué atrapan las palabras clave y qué se les escapa

Antes de que ningún modelo vea un comentario, pasamos reglas fijas sobre los 100 comentarios de YouTube de la ronda 1. Escribimos las reglas a las 00:29 hora de Singapur y no las tocamos después de ver más datos. Un comentario es pregunta si tiene signo de interrogación, una palabra interrogativa china o empieza por how, why, what, is o can. Es negativo si contiene una palabra de una lista (bad, worst, disappointed, clickbait, scam, broken y parecidas). Requiere respuesta si es pregunta, o si es negativo con al menos 10 me gusta.

Después leímos a mano los 34 comentarios marcados. Nuestro criterio: el comentario habla de este vídeo y el creador necesita saberlo o responderlo. Solo 13 lo cumplían. La mayoría de los otros 21 eran preguntas retóricas y discusiones. «¿A quién le importa si está hecho con IA?» lleva signo de interrogación, pero nadie tiene que responderlo. Otro comentario llamaba tonto el argumento de un invitado y empezaba con «What», así que la regla lo tomó por pregunta.

Los 13 útiles tienen tipos claros. Alguien preguntó por qué el vídeo se subió a 30 fps. Dos preguntaron por una barra de censura en el minuto 9:43. Otro recordó que el programa prometió volver a una prueba de un juego y no lo hizo. Otros preguntaron si el vídeo promueve la piratería. Esto es lo que va arriba en un informe de vigilancia.

Lo que la regla dejó pasar importa más. Los 66 comentarios sin marcar tenían al menos tres temas repetidos. El primero: un desenfoque falló. Cuatro comentarios decían que el desenfoque sobre una carpeta del juego se perdió un instante, y uno pedía al equipo que revisara el vídeo. Es un error de producción que el creador debe corregir ya, pero la regla solo atrapó los 2 que tenían signo de interrogación.

El segundo: «esto no es gama alta». El presentador dijo que el PC de prueba «no es de gama muy alta» y 10 comentarios lo discutieron; la regla atrapó 2. El tercero: 6 comentarios pedían un vídeo sobre el jailbreak de PS5, una pista de tema; la regla atrapó 1. Encontramos estos temas después de leer, así que no los usamos para puntuar la regla. Muestran una sola cosa: las palabras clave separan bien el ruido obvio de las preguntas obvias, pero una opinión repetida sin interrogaciones solo aparece cuando un modelo lee un grupo de comentarios y los agrupa por tema.

Así podría verse un informe de la ronda 2. Lo armamos a mano con las respuestas reales de las rondas 1 y 2; muestra la salida que buscamos, no una ejecución del modelo:

Por eso la skill reparte el trabajo así. El script quita duplicados, descarta los comentarios de solo emojis o «primero» y añade a cada fila la etiqueta de la regla. El modelo recibe «comentarios nuevos de esta ronda más etiquetas». Su trabajo es corregir falsas alarmas, juntar los comentarios de un mismo tema en una línea con recuento y poner una gravedad a cada tema. Los datos que recibe crecen poco, pero recupera los temas que la regla pierde. La ronda 2 ya lo mostró: 2 de los 9 comentarios nuevos volvían a decir que el PC «medio» de la prueba era demasiado potente, y ninguno contenía las palabras «high end».

Antigravity CLI y cron: ejecutar agy -p desde launchd, cron o systemd

Antigravity trae dos formas propias de programar trabajo, y ninguna encaja con quien usa la CLI y quiere una ronda cada pocas horas en un servidor o un portátil. Con /schedule, el agente usa una herramienta interna schedule para poner un temporizador o una expresión cron de cinco campos. Cuando llega la hora, la instrucción vuelve al agente como aviso de alta prioridad. La documentación dice que la programación pertenece a la conversación que la creó y termina con ella; para trabajos largos entre sesiones remite a los sidecars (documentación de /schedule).

Un sidecar es un proceso en segundo plano definido en ~/.gemini/config/sidecars/<nombre>/sidecar.json. Con "builtin": "schedule" puede llamar a agentapi new-conversation según una expresión cron. Pero la cabecera de esa página solo indica la aplicación de escritorio de Antigravity. Además, los sidecars vienen apagados y hay que activarlos uno a uno en ~/.gemini/config/config.json (documentación de Sidecars). Queda el temporizador del sistema operativo, que arranca el modo sin interfaz.

La columna de reposo sale de la documentación de cada sistema. Apple explica que las tareas de cron no corren mientras la máquina duerme y esperan a la siguiente hora prevista. Una tarea de launchd con StartCalendarInterval que pierde su hora durante el reposo corre al despertar, y ninguna de las dos corre con el equipo apagado (Apple, «Scheduling Timed Jobs»). En Linux, el equivalente es la opción Persistent= de un temporizador de systemd (manual de systemd.timer).

La sintaxis y el entorno de cron están en crontab(5). Cron usa /bin/sh por defecto y no lee tu perfil de shell, así que escribe la ruta completa de agy. Este ejemplo de launchd corre una ronda cada 2 horas en macOS. Pon el archivo en ~/Library/LaunchAgents/ y deja scripts y datos fuera de Escritorio y Documentos, porque la protección de privacidad de macOS los bloquea:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
  <key>Label</key><string>com.example.comment-patrol</string>
  <key>ProgramArguments</key>
  <array><string>/Users/you/patrol/run.sh</string></array>
  <key>StartCalendarInterval</key>
  <array>
    <dict><key>Minute</key><integer>5</integer><key>Hour</key><integer>0</integer></dict>
    <dict><key>Minute</key><integer>5</integer><key>Hour</key><integer>2</integer></dict>
    <!-- las otras 10 horas pares siguen el mismo patron, 12 rondas en total -->
  </array>
  <key>StandardOutPath</key><string>/Users/you/patrol/logs/out.log</string>
  <key>StandardErrorPath</key><string>/Users/you/patrol/logs/err.log</string>
</dict></plist>

El script run.sh es el que llama a Antigravity, y ahí se juntan tres problemas habituales:

#!/bin/bash
set -uo pipefail
cd /Users/you/patrol
out=$(/usr/local/bin/agy -p "Usa la skill comment-patrol con los videos de videos.txt. Es la ronda ${ROUND:-1}." \
  --output-format json \
  --json-schema .agents/skills/comment-patrol/resources/report.schema.json \
  --model gemini-3.8-flash-medium \
  --print-timeout 15m 2> logs/last-stderr.log)
status=$(echo "$out" | jq -r '.status')
reason=$(echo "$out" | jq -r '.finished_reason // "complete"')
if [ "$status" != "SUCCESS" ] || [ "$reason" != "complete" ]; then
  echo "$(date -u +%FT%TZ) ronda fallida: $status $reason" >> logs/alerts.log; exit 1
fi
if grep -qi "permission\|denied" logs/last-stderr.log; then
  echo "$(date -u +%FT%TZ) herramienta rechazada, revisa permissions.allow" >> logs/alerts.log; exit 1
fi
echo "$out" | jq '.structured_output' > "reports/$(date +%Y%m%d-%H%M).json"

El primer problema es el rechazo suave. La documentación explica que el modo sin interfaz no tiene avisos interactivos. Una herramienta que necesita aprobación y no la consigue recibe un rechazo suave: la ejecución sigue, el proceso sale con 0 y un aviso va a stderr (Headless mode, «Permissions in headless mode»). Si tus reglas de permissions.allow están mal, cada ronda «termina bien» y cada informe sale vacío. Por eso el script lee también stderr. La documentación no da el texto exacto del aviso, así que nuestro script busca palabras clave. Antes de publicar, quita a propósito una regla, lee el aviso real una vez y ajusta la búsqueda.

El segundo problema es el inicio de sesión. El modo sin interfaz usa credenciales guardadas, así que ejecuta agy de forma interactiva una vez para entrar. En un entorno sin terminal y sin sesión, falla con «authentication required». El README dice que las credenciales viven en el llavero del sistema (README en GitHub, «Authentication»). Por eso la tarea de launchd debe correr en la sesión del usuario: un LaunchAgent, no un LaunchDaemon.

El tercer problema es el tiempo límite. --print-timeout vale 5 minutos por defecto, y dos plataformas, varias llamadas y una pasada del modelo pueden tardar más; nuestro ejemplo usa 15 minutos. La versión 1.4.11, del 30 de octubre de 2026 (UTC), añadió finished_reason a la salida JSON. Vale print_timeout si la ejecución se cortó y no aparece si el turno terminó con normalidad (notas de la 1.4.11). Así el script distingue un informe completo de medio informe. Desde la 1.2.10, del 24 de septiembre de 2026, una ejecución -p que falla durante una respuesta en streaming sale con código 3 y ya no parece un éxito (notas de la 1.2.10).

Coste de 24 horas: la API por llamada, el modelo por cuota o por token

Empecemos por los datos. El 3 de noviembre de 2026, las cinco capacidades de esta guía costaban 0,000556 USD por llamada en el catálogo: youtube/comments, youtube/video, bilibili/comments, bilibili/danmaku y bilibili/video. El catálogo es público en GET https://api.everyinfra.com/api/v1/social/catalog y no necesita clave; mira siempre el precio del día. Una ronda hace tres llamadas básicas, que suman 0,001668 USD: los 100 comentarios más nuevos de YouTube, los destacados de Bilibili y los danmaku. Cada 4 rondas añadimos una consulta de detalle por vídeo para seguir el crecimiento. Las llamadas fallidas no se cobran: el 422 de antes no costó nada. Para conciliar cobros por ID de petición, mira conciliación de reembolsos por fallo.

La columna del modelo es una estimación, y este es el método para que uses tus propias cifras. En la documentación del modo sin interfaz, un prompt de una línea muestra input_tokens de 10.415 en la salida JSON; de ellos, cache_read_tokens es 8113, y output_tokens es 657 (Headless mode, «JSON output»). Cada llamada a agy -p lleva, por tanto, unos diez mil tokens de prompt de sistema y definiciones de herramientas. Por ronda suponemos esa entrada fija, con 8113 tokens a precio de caché. Sumamos unos 805 tokens de datos: 505 de los 9 comentarios nuevos de YouTube de la ronda 2 y unos 300 de instrucciones y filas de Bilibili. Y sumamos 1500 tokens de salida.

Los precios salen de la página de precios de la API de Gemini, actualizada el 30 de octubre de 2026. Gemini 3.8 Flash cuesta 0,75 USD por millón de tokens de entrada, 3,75 USD por millón de salida y 0,075 USD por millón en caché. La página dice que esos precios valen hasta el 31 de diciembre de 2026 y se duplican desde el 1 de enero de 2027 (precios de la API de Gemini). Estimamos los tokens de datos como bytes entre 4, porque la documentación de Gemini dice que un token son unos 4 caracteres (API de Gemini, «Understand and count tokens»). Funciona con comentarios en inglés y se queda corto con texto chino.

Lee los dos gráficos juntos. En esta tarea el dinero no se va en los datos, ni sobre todo en los tokens de los comentarios: se va en el coste fijo de despertar a agy cada vez. Ahorra en este orden. Primero, alarga el intervalo: una ronda cada 2 horas cuesta la mitad que una cada hora. Segundo, no llames al modelo en rondas sin comentarios nuevos, como ya dice el árbol de decisión de la skill. Solo después recorta campos por comentario.

Fija también el modelo en la gama Flash con --model. La documentación de modelos dice que los planes gratuito y Plus solo tienen Gemini 3.8 Flash, y que Gemini 4 Argon requiere Pro o Ultra (documentación de modelos). Si tu modelo por defecto es Argon, la misma vigilancia cuesta bastante más. En la misma página de precios, Gemini 4 Argon cuesta 2 USD por millón de tokens de entrada y 10 USD por millón de salida hasta el 30 de noviembre de 2026, y se duplica desde el 1 de diciembre.

Los usuarios personales no pagan esa factura de tokens directamente: gastan cuota del plan. La documentación de planes describe tres niveles. El gratuito tiene cuota semanal; Pro se renueva cada 5 horas y tiene además un límite semanal; Ultra es más alto. No se admite traer tu propia clave (documentación de planes). La entrada del blog del 19 de mayo de 2026 dice que Pro cuesta 20 USD al mes, añade un Ultra de 100 USD y baja el antiguo Ultra de 250 USD a 200 USD. Flash y Pro comparten una bolsa que se gasta a precio de API, y los niveles de 100 y 200 USD dan 5 y 20 veces la cuota de Pro (blog de Antigravity, 19 de mayo de 2026). Lee la columna del modelo como «cuánta cuota gasta esta vigilancia, expresada en dólares».

YouTube tiene además un camino gratuito. commentThreads.list cuesta 1 unidad de cuota por llamada y la cuota por defecto es de 10.000 unidades al día (commentThreads.list; calculadora de cuota, actualizada el 2026-10-15). Con una clave de API se leen los comentarios de vídeos públicos; solo los retenidos o sospechosos de spam necesitan OAuth del dueño del vídeo. El precio es un proyecto de Google Cloud, tu propia gestión de cuota y paginación, y nada de Bilibili. Si quieres las dos plataformas en un informe sin mantener dos integraciones, pagar por llamada es más simple. La lista completa está en precios.

Antigravity CLI frente a Gemini CLI: qué cambiar al migrar

Si ya tenías un script parecido con Gemini CLI, la mayoría de los cambios están en la ubicación de los archivos y en los nombres de las claves; los archivos de reglas del espacio de trabajo no cambian. El comando oficial agy plugin import gemini convierte las extensiones antiguas en plugins y escribe sus definiciones MCP en mcp_config.json (guía de migración, «Converting extensions to plugins»). La primera ejecución de agy también detecta la configuración antigua y ofrece una lista para marcar. Aun así, revisa los servidores MCP que escribiste a mano en ~/.gemini/settings.json y los ajustes de confianza. Hicimos esta tabla comparando línea a línea las dos documentaciones oficiales:

La última fila es la que más pesa en tareas programadas. La documentación de planes dice que no puedes traer tu propia clave o endpoint para subir la cuota (documentación de planes). En la discusión de GitHub, varios desarrolladores se quejan de que la nueva CLI ya no acepta una clave de AI Studio (discusión #27274). El anuncio de mayo dice además que Gemini CLI sigue funcionando con claves de pago y licencias empresariales. Si tu vigilancia corre en un servidor en la nube sin pantalla y solo tienes una clave de API, quizá lo sencillo sea seguir en Gemini CLI hasta que la documentación de Antigravity explique el inicio de sesión desatendido.

No hay una comparación oficial de cuota. Un usuario de Reddit cuenta que Antigravity CLI la gasta más rápido; lo vemos en la pregunta frecuente «¿cuál gasta menos cuota?», al final.

Límites y qué vigilar

Del lado de los datos hay cuatro límites. Primero, los comentarios que la plataforma retiene para revisión no se ven. La ayuda de YouTube dice que los ajustes «Básico» o «Estricto» retienen comentarios en YouTube Studio hasta 60 días y que siguen ocultos hasta su aprobación (Ayuda de YouTube, ajustes de comentarios). Cualquier tercero, nosotros incluidos, ve solo comentarios públicos. Para ver los retenidos, el dueño del canal debe llamar a la YouTube Data API con OAuth y moderationStatus=heldForReview (documentación de commentThreads.list).

Segundo, las horas de YouTube son etiquetas relativas como «2 hours ago», y 4 filas de la ronda 1 decían además «(edited)». Una hora convertida solo es exacta a la hora, y los comentarios más viejos acumulan más error. Tercero, en Bilibili solo hay comentarios destacados: recibimos 3 y luego 10, frente a totales de 4075 y 4566. Una vigilancia de «todos los comentarios nuevos» no es posible en Bilibili, así que sigue los cambios en destacados y danmaku.

Cuarto, YouTube añadió snippet.imageUrl a los comentarios en su historial de revisiones de la Data API el 30 de septiembre de 2026, y los comentarios con GIF o imagen llegan a todos los usuarios en noviembre (historial de revisiones de la YouTube Data API). La lista de campos de youtube/comments no tiene campo de imagen, así que un comentario que solo es una imagen aparece como texto vacío. No trates todo texto vacío como ruido.

Del lado de Antigravity, la CLI es de código cerrado y cambia rápido. Esta guía usa la documentación leída el 3 de noviembre de 2026 y las notas de la 1.4.12. La documentación de sidecars solo menciona la app de escritorio. El modo sin interfaz depende de una sesión guardada y la documentación no explica el inicio de sesión desatendido en la nube. La cuota personal se gasta según el trabajo hecho, y la documentación de planes dice que puede cambiar. Toma nuestras cifras de coste como estimaciones; el panel /usage muestra las reales (documentación de /usage).

Por último, hay límites de uso. La skill solo lee y no publica nada. EveryInfra lee datos públicos y no puede publicar con tu cuenta, así que cualquier respuesta la envía una persona desde YouTube Studio o el Creator Center de Bilibili. En los informes, guarda solo IDs y texto, nunca nombres de usuario ni enlaces a perfiles, y respeta los términos de cada plataforma y la ley de privacidad que te aplique.

Las etiquetas tampoco son perfectas. Nuestras reglas de palabras clave marcaron 34 comentarios y solo 13 merecían el tiempo del creador; además, se les escapó la mitad de los comentarios del tema «falló el desenfoque». La clasificación con el modelo no la probamos en esta guía: antes de ponerla en marcha, etiqueta a mano los mismos 100 comentarios y compáralos con lo que da el modelo. Lo marcado como «alto» siempre lo lee una persona; el modelo solo reduce 100 comentarios a una docena.

Cambios recientes

• El 30 de octubre de 2026 (UTC), Antigravity CLI 1.4.11 añadió finished_reason a --output-format json, y ese mismo día la 1.4.12 arregló tablas Markdown rotas en respuestas largas (1.4.11, 1.4.12). Qué significa para ti: un script ya puede distinguir «informe terminado» de «cortado por tiempo»; usa la 1.4.11 o posterior.
• El 24 de octubre de 2026, la 1.4.7 bajó el uso de CPU en -p y subió de 4 KB a 10 KB el tamaño de los resultados MCP que llegan directos al agente (1.4.7). Qué significa para ti: 100 comentarios de YouTube son unos 33 KB, todavía por encima; comprime las filas nuevas en un script antes.
• El 13 de octubre de 2026, Gemini 4 Argon llegó a la app y la CLI para usuarios de Google AI Pro y Ultra (blog de Antigravity), y la 1.3.4 hizo que un --agent desconocido salga con código 1 en modo sin interfaz (1.3.4). Qué significa para ti: Gemini 3.8 Flash basta para clasificar comentarios, y una errata en el script ahora falla de forma visible.
• La página de precios de la API de Gemini, actualizada el 30 de octubre de 2026, da para Gemini 3.8 Flash 0,75 USD de entrada y 3,75 USD de salida por millón de tokens hasta el 31 de diciembre, con precios dobles desde el 1 de enero de 2027; Gemini 4 Argon cuesta 2 y 10 USD hasta el 30 de noviembre y luego se duplica (precios de la API de Gemini). Qué significa para ti: la cuota del plan se gasta a precio de API (anuncio de planes de mayo), y Google no ha dicho si los precios nuevos cambian ese ritmo; mira /usage una semana tras el lanzamiento.

Preguntas frecuentes

¿Dónde va la configuración MCP de Antigravity CLI?

El archivo global es ~/.gemini/config/mcp_config.json, y el de un proyecto, .agents/mcp_config.json en la raíz, según la guía de migración. Un usuario de Reddit encontró la configuración escrita en ~/.gemini/antigravity-cli/ y tuvo que copiarla a ~/.gemini/config/ (hilo de r/google_antigravity). Lo más rápido tras configurar es ejecutar /mcp. (Pregunta tomada de la sugerencia de Google «antigravity cli mcp config».)

Antigravity CLI frente a Gemini CLI: ¿cuál gasta menos cuota?

No hay una comparación oficial. Un post de Reddit con 35 votos cuenta que Antigravity CLI agotó dos cuentas Pro en dos horas programando una web, mientras que Gemini CLI gastó cerca del 10 % en cuatro horas; es la experiencia de una persona, no una medición. Sabemos que la cuota personal se gasta a precio de API, que Flash y Pro comparten bolsa y que cada llamada sin interfaz lleva unos 10.000 tokens fijos de entrada. Para tareas cortas como esta, deja que un script quite duplicados y filtre primero, manda al modelo solo unos cientos de tokens de comentarios nuevos y fija --model en Flash. (Pregunta tomada de la sugerencia «antigravity cli vs gemini cli quota» y del hilo de r/GeminiCLI.)

¿Puedo usar /schedule como tarea cron de Antigravity CLI?

Sirve para revisar cada pocos minutos mientras una conversación sigue abierta, pero no para una tarea de 24 horas sin nadie delante. /schedule acepta expresiones cron de cinco campos y MaxIterations, pero pertenece a la conversación actual. La documentación sugiere sidecars para trabajos largos, y los sidecars solo mencionan la app de escritorio. Con la CLI, launchd, cron o systemd llamando a agy -p dan un resultado más estable. (Pregunta tomada de las sugerencias «antigravity cli cron job» y «antigravity cli cron expression».)

¿Qué es el modo yolo de Antigravity CLI y debe usarlo un temporizador?

La referencia de la CLI no tiene ninguna opción llamada yolo. Lo más parecido es --dangerously-skip-permissions, que permite todas las herramientas, y el ajuste toolPermission: "always-proceed". La vigilancia solo necesita tres herramientas MCP y una carpeta de informes, así que nómbralas en permissions.allow. (Pregunta tomada de la sugerencia «antigravity cli yolo mode»; las opciones están en la referencia de la CLI.)

YouTube ya tiene herramientas de moderación de comentarios. ¿Para qué una vigilancia?

La moderación de YouTube Studio retiene comentarios sospechosos: responde a «qué debe quedar oculto». La vigilancia responde a «qué comentarios públicos son preguntas, quejas o piden respuesta», junta YouTube y Bilibili en un informe y sirve con vídeos de la competencia. En tu propio canal, usa las dos: Studio para lo retenido y la vigilancia para el seguimiento de lo público. (Pregunta tomada de la sugerencia «youtube comment moderation tool»; los ajustes están en la Ayuda de YouTube.)

¿Un scraper de comentarios de Bilibili puede traer todos los comentarios de un vídeo?

Con bilibili/comments, no. El catálogo dice 10 por llamada como máximo y recorta un límite mayor. En nuestra prueba devolvió 3 y luego 10 comentarios destacados cuando el vídeo tenía más de cuatro mil, y rechaza el parámetro de orden. Solo el dueño del vídeo ve todo, en el Creator Center o con una app aprobada de la plataforma abierta. Para vigilar, trata Bilibili como dos señales: destacados y danmaku. (Pregunta tomada de una sugerencia de búsqueda en chino que significa «scraper de comentarios de Bilibili».)

Primeros pasos

1. Consigue una clave de API en el inicio rápido y lee primero el catálogo gratuito: GET https://api.everyinfra.com/api/v1/social/catalog?platform=youtube, y lo mismo con ?platform=bilibili.
2. En las páginas de la API de YouTube y la API de Bilibili, prueba una vez el endpoint de comentarios con la URL de tu vídeo.
3. Escribe .agents/mcp_config.json y permissions.allow como arriba, ejecuta agy una vez en modo interactivo y comprueba /mcp y /permissions.
4. Pon la skill en .agents/skills/comment-patrol/, ejecuta agy -p a mano una vez y comprueba que structured_output cumple el esquema y que stderr no muestra herramientas rechazadas.
5. Pásale la tarea a launchd, cron o systemd: cada 2 horas el primer día, atento a «pudo perder comentarios» en la línea 1, y luego ajusta el intervalo.

El mismo enfoque sirve en otras herramientas de IA. Para tareas programadas en Claude Code, mira tareas programadas de Claude Code con problemas de Reddit. Para otra forma de conectar Gemini a un servidor MCP remoto, mira Gemini Deep Research API con MCP remoto. Para limpiar y etiquetar comentarios, mira DeepSeek V4 y Claude Code para limpiar comentarios.

Leímos todas las fuentes externas de esta guía el 3 de noviembre de 2026 (hora de Singapur). Las fechas de la lista de referencias son las de publicación o actualización de cada página.

Referencias

1. Blog de desarrolladores de Google: el paso de Gemini CLI a Antigravity CLI, 19 de mayo de 2026.
2. Discusión #27274 de gemini-cli en GitHub.
3. Guía de migración de Antigravity CLI.
4. Referencia de opciones de Antigravity CLI.
5. Modo sin interfaz de Antigravity CLI.
6. Comando /schedule de Antigravity.
7. Sidecars de Antigravity.
8. Documentación MCP de Antigravity (pestaña CLI).
9. Documentación de Agent skills (pestaña CLI).
10. Documentación de permisos (pestaña CLI).
11. Documentación de planes de Antigravity.
12. Documentación de modelos de Antigravity.
13. Modos de ejecución de Antigravity CLI.
14. Comando /usage de Antigravity CLI.
15. Registro de cambios de Antigravity.
16. Repositorio google-antigravity/antigravity-cli.
17. Notas de la versión 1.4.12, 30 de octubre de 2026 (UTC).
18. Notas de la versión 1.4.11, 30 de octubre de 2026 (UTC).
19. Notas de la versión 1.4.10, 29 de octubre de 2026.
20. Notas de la versión 1.4.7, 24 de octubre de 2026.
21. Notas de la versión 1.3.4, 13 de octubre de 2026.
22. Notas de la versión 1.2.10, 24 de septiembre de 2026.
23. Notas de la versión 1.2.9, 23 de septiembre de 2026.
24. Documentación MCP de Gemini CLI.
25. Blog de Antigravity: cambios en los planes, 19 de mayo de 2026.
26. Blog de Antigravity: Gemini 4 Argon, 13 de octubre de 2026.
27. Blog de Antigravity: Gemini 3.8 Flash.
28. Blog de Google: lanzamiento de Gemini 4 Argon, 30 de septiembre de 2026.
29. Precios de la API de Gemini, actualizada el 30 de octubre de 2026.
30. API de Gemini: entender y contar tokens, actualizada el 13 de octubre de 2026.
31. Foro de desarrolladores de Google AI: Ultra para empresas sin Gemini 4 Argon, 14 de octubre de 2026.
32. Especificación MCP 2026-07-28: Transports.
33. Estándar abierto Agent Skills.
34. YouTube Data API: commentThreads.list.
35. Calculadora de cuota de la YouTube Data API.
36. Historial de revisiones de la YouTube Data API.
37. Ayuda de YouTube: ajustes de comentarios.
38. TechCrunch: novedades de comentarios en YouTube, 23 de septiembre de 2026.
39. Bilibili Open Platform.
40. Documentación de Apple: Scheduling Timed Jobs.
41. Manual de crontab(5).
42. Manual de systemd.timer.
43. r/google_antigravity: «Antigravity CLI MCP Servers Pain».
44. r/google_antigravity: variables de entorno en la configuración MCP.
45. r/GeminiCLI: por qué Antigravity CLI gasta tanta cuota.
46. The New Stack: el sustituto de Gemini CLI, 20 de junio de 2026.
47. Vídeo de muestra de YouTube, publicado el 2 de noviembre de 2026.
48. Vídeo de muestra de Bilibili, publicado el 2 de noviembre de 2026.
49. Catálogo de EveryInfra: YouTube.
50. Catálogo de EveryInfra: Bilibili.