El conteo que hay que hacer antes de elegir dónde corren los agentes
Cuando un equipo empieza a correr agentes de IA en paralelo, la primera pregunta casi nunca es de memoria: es de modelo, de prompt o de framework. La que sí decide el rendimiento es más aburrida: cuánta memoria se está comiendo cada agente mientras trabaja.
Esta es la cuenta para hacerla. Si tu problema es que varios agentes se pisan el código, ese es otro tema: parte por Worktrees para agentes de IA: que no se pisen el código.
Qué ocupa memoria cada agente
Cada agente que corre en paralelo carga tres cosas al mismo tiempo:
- Su contexto de trabajo: el historial de la conversación, los archivos que leyó y el código que tiene abierto.
- El runtime de la herramienta que lo ejecuta: Claude Code, Codex, Gemini o el script propio que controla cada tarea.
- Los procesos que lanza: compiladores, servidores locales, watchers de archivos y procesos de test.
Un agente que está "esperando" sigue ocupando su parte. Y un build usa la memoria del sistema entero, no la del agente que lo lanzó.
Por eso el problema aparece antes como "el agente está lento": cada agente arrastra su worktree, su build, sus tests y su dev server, y todo eso compite por la misma RAM.
La cuenta rápida
FicPod se paga por máquina y no por tokens: Hobby cuesta US$29 al mes y Startup US$54 al mes con 24 GB (precios publicados en ficpod.com). La calculadora del propio sitio, con 8 agentes en paralelo, recomienda el plan Startup de 24 GB (ficpod.com). De ahí sale una regla práctica de entre 2 y 3 GB por agente en paralelo, contando builds y tests (estimación derivada de esa referencia, no una medición publicada).
Sobre esa base, el cálculo para tu equipo es simple:
- Agentes que corren a la vez en tu peor día, no en el promedio.
- Uno o dos GB extra por agente si además corres builds pesados o tests en paralelo.
- Memoria de base del sistema y de tu editor.
El propio sitio de FicPod pone el ejemplo: con cinco agentes en paralelo un notebook de 16 GB ya empieza a usar swap, y con diez se cae (ficpod.com). Si tu día típico es ese, la cuenta ya está hecha.
Las tres preguntas que delatan el cuello de botella
- ¿Cuántos agentes corres en paralelo a la vez?
- ¿Cuánto tarda un build completo desde el último commit?
- ¿Qué pasa con las tareas largas si cierras el notebook?
Si la tercera es "se pierden o quedan a medias", el problema no es el prompt ni el modelo: es dónde vive la flota.
Qué mirar antes de mover nada
- Mide el pico, no el promedio: cuenta los agentes del día más pesado.
- Distingue si el cuello es memoria, disco o red; un build lento no siempre es falta de RAM.
- Separa las tareas largas (tests, refactors, migraciones) de las interactivas: las primeras son las que ganan cuando corren sin supervisión.
- El notebook no tiene por qué ser el servidor: puede seguir siendo tu lugar de control.
La decisión, en una frase
Si tu equipo ya corre agentes de IA en paralelo, el siguiente paso no es cambiar de modelo: es medir la carga y darle a esa flota una máquina que no se duerma. Puedes abrir la beta en https://ficpod.com/registro?utm_source=blog.
