Quien busca «precios de Roo Code» suele encontrar una contradicción: la extensión no cuesta nada, pero la factura puede ser más alta que la de una herramienta por suscripción. La razón no es complicada: Roo Code usa BYOK, el software es gratuito, el modelo se cobra por token y un agente de programación consume muchos tokens.

Este artículo no enumera precios fijos; explica la estructura de costos, el método de cálculo y las formas de control. Las tarifas se rigen por precios de modelos y por los sitios oficiales de cada producto.

Nota: Roo Code es una marca de su titular; Cursor, Claude, GitHub Copilot y otros nombres pertenecen a sus respectivos titulares. Este artículo solo ofrece una explicación técnica y no implica afiliación con esas empresas. La extensión Roo Code dejó de recibir mantenimiento el 15 de mayo de 2026 y el repositorio se archivó; la bifurcación comunitaria Zoo Code continúa el desarrollo. El estado posterior se rige por el repositorio oficial.

1. Estructura de cobro: el software es gratis, el costo está en el modelo

Roo Code es una extensión de VS Code de código abierto; no cobra por asiento ni incluye una cuota de modelos. Tú introduces tu propia clave, las peticiones van al proveedor o al gateway y el costo se liquida por token. No revende tokens.

Conviene distinguir la extensión del producto en la nube de la empresa Roo Code: este último puede tener su propia suscripción y cuota, mientras que aquí solo se trata del BYOK de la extensión local. La extensión dejó de recibir mantenimiento el 15 de mayo de 2026 y el repositorio se archivó; la bifurcación comunitaria Zoo Code mantiene el mismo modelo, y el cálculo siguiente sirve para ambos.

Por eso, el «precio de Roo Code» se compone de tokens de entrada, tokens de salida y extras como caché o razonamiento. El precio de la herramienta es cero; la forma de usarla determina la factura total.

2. La diferencia real entre suscripción y pago por uso

La suscripción empaqueta funciones del editor, capacidad del agente y cierta cuota de modelos en una tarifa mensual fija; el BYOK separa el software del modelo y pagas según lo que consumes. No se trata simplemente de caro o barato, sino de quién asume el riesgo.

Dimensión Suscripción BYOK por uso
Ritmo de pago Periodo fijo, fácil de presupuestar Varía con el consumo
Techo de costo Suele tener límite de cuota o de peticiones Depende del límite de la clave
Elección de modelo Según lo que soporte el producto Puedes cambiar de proveedor y modelo
Costo en inactividad Se paga aunque no uses Sin uso, sin costo de modelo
Costo en picos Dentro de la cuota no hay cargo extra A mayor uso, mayor factura
Escenario adecuado Uso diario intensivo y búsqueda de simplicidad Uso irregular, modelos específicos o control centralizado

El costo oculto de la suscripción es la reducción de velocidad, las colas o el pago adicional al agotar la cuota; el del pago por uso es la falta de control. Antes de elegir, confirma cuál de los dos toleras mejor.

3. Dónde se gastan los tokens de un agente de código

Un chatbot se limita a «pregunta y respuesta». Un agente de código reenvía en cada vuelta el prompt de sistema, las definiciones de herramientas, la descripción de los modos, el historial de conversación, los archivos leídos, la salida de terminal y los diffs; los tokens de entrada se acumulan con la tarea.

Es habitual que una tarea mediana genere entre una docena y varias decenas de peticiones. La salida suele ser menor que la entrada, pero en la mayoría de los modelos el precio de salida es más alto; los tokens de razonamiento también pueden cobrarse como salida. Lo que más pesa no suele ser el fragmento final de código, sino el contexto que se reenvía una y otra vez.

Otros consumos que se pasan por alto: los reintentos tras fallos de herramientas; la compresión de contexto, que también llama al modelo; las subtareas y el Orchestrator, que multiplican las peticiones; las conversaciones largas, que alargan el historial en cada vuelta; y los fallos de caché, que hacen que todo se cobre como entrada normal.

Para saber si sale caro, hay que mirar el número de peticiones y el tamaño del contexto de una tarea completa, no de una sola pregunta.

4. Hacer las cuentas: fórmula y pasos

El costo de una tarea se divide en cuatro componentes. Sustituye los precios de la página de precios y obtendrás un resultado reproducible:

costo por tarea =
  tokens de entrada sin caché × precio de entrada
+ tokens de escritura de caché × precio de escritura de caché
+ tokens de lectura de caché × precio de lectura de caché
+ tokens de salida × precio de salida

El procedimiento tiene seis pasos:

  1. Elige tres tareas representativas: un cambio pequeño en un archivo, una función que toca varios archivos y un diagnóstico entre archivos.
  2. Registra en el log del gateway el número de peticiones, la entrada, la salida y las lecturas y escrituras de caché de cada tarea.
  3. Obtén los precios vigentes en precios de modelos; ten en cuenta que los cuatro tipos de token pueden tener precios distintos.
  4. Calcula el costo por tarea con la fórmula y multiplícalo por las tareas diarias y los días laborables del mes.
  5. Añade el consumo de reintentos, compresión y subtareas, y deja un margen; no calcules sobre el camino ideal.
  6. Compara el resultado con el precio total, la cuota y las reglas de exceso de la suscripción, no solo con el precio anunciado.

El ejemplo ilustra el método y no representa una medición: supongamos una tarea con 40 peticiones, una entrada media de 15.000 tokens, un 70 % de aciertos de caché y 8.000 tokens de salida en total. Solo multiplicando cada tipo de token por su precio se obtiene el costo real. Si el log no tiene campos de caché, calcula como si toda la entrada fallara en caché.

5. La caché ayuda, pero no es magia

El contexto de un agente de código se repite mucho: el prompt de sistema, las definiciones de herramientas, la descripción de los modos, las reglas del proyecto y las primeras conversaciones son casi iguales en cada vuelta. Los proveedores que soportan caché guardan esos prefijos y cobran las lecturas posteriores a un precio de caché, normalmente muy inferior al de entrada normal.

Para que la caché funcione de verdad hacen falta varias condiciones: un prefijo estable, sin marcas de tiempo ni ID aleatorios al principio; el mismo modelo, porque cambiarlo a mitad de camino vuelve a cobrar; un intervalo compatible, porque si pasa demasiado tiempo caduca; un canal que la soporte, porque no todos los endpoints compatibles la implementan; y asumir que comprimir tiene un costo, porque al reescribir el historial hay que reconstruir la caché.

En la práctica, empieza por usar el mismo perfil, el mismo modelo y las mismas reglas para tareas similares, y después habla de optimización. Trata la caché como un «descuento posible», no como un «porcentaje seguro». Si el log distingue los campos, usa los datos reales; si no, haz una estimación conservadora.

6. Presupuesto máximo: convertir el ahorro en control

El mayor riesgo del pago por uso no es el precio unitario, sino la falta de freno.

En el gateway: una clave por persona y claves separadas por proyecto, con cuotas diarias y mensuales y alertas de consumo; si hay listas de permitidos, limita el rango de modelos de cada clave; exporta el consumo con regularidad para verificarlo. Aunque una tarea se descontrole, el daño queda acotado a una clave.

En Roo Code: usa los perfiles de configuración de API para asignar modelos distintos a cada modo; un modelo potente para planificar, uno ligero para preguntas y cambios masivos; configura Rate Limit en los perfiles de alto consumo; usa la aprobación automática con prudencia, sobre todo en operaciones que ejecutan comandos de terminal, borran archivos o instalan dependencias; las subtareas del Orchestrator heredan el perfil del padre, así que hay que planificarlas aparte.

En los hábitos: divide las tareas grandes en pasos verificables y cierra las conversaciones que ya no sean relevantes; si un modelo falla repetidamente, detente y revisa las llamadas a herramientas y las rutas en lugar de seguir reintentando. Los checkpoints permiten revertir código, pero no devuelven tokens.

7. Cuándo conviene suscribirse y cuándo pagar por uso

No hay un modelo que sea más barato para todos los equipos; hay modelos que encajan y otros que no.

La suscripción encaja en quien la usa a diario, tiene tareas estables, no quiere gestionar claves y acepta modelos y cuotas limitados. Su valor es convertir el costo en un gasto fijo y ahorrarse presupuesto y auditoría; pero si se agota la cuota con frecuencia o alguien casi no la usa, el costo por unidad sube.

El BYOK encaja en equipos con consumo irregular, que necesitan modelos concretos, que quieren un gateway común y que desean ver la cuenta por miembro y por proyecto. Es más amable con el uso ligero, porque sin uso el costo de modelo es cero; pero el uso intensivo, con contextos largos y muchas subtareas, no siempre resulta más económico.

También es común un esquema mixto: suscripción para la edición diaria y BYOK para refactorizaciones masivas, automatización y tareas con modelos específicos. Además, como Roo Code dejó de recibir mantenimiento, hay que contar el costo de tiempo de migrar a herramientas como Zoo Code.

8. Una prueba real de 30 días

  • Semana 1: mantén la situación actual, registra los tokens y las peticiones de tres tareas representativas y establece una base.
  • Semana 2: fija el prompt de sistema y la configuración de modos, reduce los cambios de modelo y observa los aciertos de caché.
  • Semana 3: añade cuota y alertas a las claves y cambia los modos de alto consumo a modelos ligeros.
  • Semana 4: compara el costo mensual acumulado con la suscripción y revisa si la cuota alcanza.

No cambies demasiadas variables a la vez, porque no podrás saber qué funcionó. Al final mira tres cifras: costo mensual total, tasa de tareas completadas y proporción de excesos o reintentos. Ser solo más barato pero fallar a menudo no es ahorrar.

Preguntas frecuentes

¿Roo Code cobra por sí mismo?

La extensión local no cobra por asiento: usa BYOK y las llamadas al modelo se facturan por token con tu clave. El producto en la nube tiene otro sistema de facturación y no conviene mezclarlos. La extensión dejó de recibir mantenimiento en mayo de 2026 y Zoo Code continúa el desarrollo.

¿El pago por uso siempre es más barato que la suscripción?

No necesariamente. El uso ligero e intermitente suele salir mejor; el uso intensivo, con contextos largos y muchas subtareas, puede ser más controlable con suscripción. Haz el cálculo con tus propios registros y los precios vigentes.

¿Por qué la factura real es mucho más alta que la estimación?

La causa habitual es subestimar los tokens de entrada: cada vuelta reenvía historial, archivos y salidas de herramientas; después vienen los reintentos, la compresión, las subtareas y los tokens de razonamiento. Revisa primero el número de peticiones y la composición de la entrada, y decide después si el problema es el precio o el consumo.

¿Cuánto ahorra la caché?

Depende de la estabilidad del prefijo, el modelo, la vigencia de la caché y la implementación del canal. Cuanto más estable sea el prefijo y más concentrada la sesión, mayor será la proporción de lecturas de caché; cambiar de modelo con frecuencia o reescribir el prompt la invalida. Calcula con los campos de caché del log y no des por hecho un descuento fijo.

¿Cómo evita un equipo que la factura se descontrole?

Una clave por persona y claves por proyecto, cuotas diarias y mensuales con alertas en el gateway; limita el rango de modelos de cada clave; en Roo Code, asigna modelos ligeros y Rate Limit a los modos de alto consumo; y audita periódicamente el consumo anómalo.

Resumen

Si vas a poner bajo control el costo del agente de código, empieza por crear en el registro una clave de prueba con cuota, ejecuta tareas reales durante una semana con registro y aplica después la fórmula de este artículo. Los precios por modelo, las reglas de caché y las políticas de cuota cambian; toma como referencia la información en tiempo real de precios de modelos.

Lecturas relacionadas:

Nota: Roo Code es una marca de su titular; Cursor, Claude, GitHub Copilot y otros nombres pertenecen a sus respectivos titulares. Este artículo solo ofrece una explicación técnica y no implica afiliación con esas empresas. Las capacidades, los precios y el estado de los proyectos pueden cambiar; consulta la documentación oficial y los anuncios de cada repositorio.