Kilo Code vs Cline: flujos de trabajo, costes y permisos

Elige primero dónde se ejecuta la tarea

Evalúa Kilo Code si necesitas agentes especializados y permisos por herramienta. Evalúa Cline si prefieres discutir los cambios en Plan y pasar después a Act. Ambos ofrecen flujos en el editor, el terminal y la nube. Esa diferencia por sí sola no decide la comparación.

Consultamos la documentación oficial enlazada el 23 de octubre de 2026. Esta guía de selección se basa en documentación. No ejecutamos esta tarea con ninguno de los productos, ni auditamos su tráfico, ni medimos velocidad, tasa de éxito o coste comparativos.

Dónde se ejecuta el trabajo	Kilo Code	Cline
Espacio de trabajo del editor	Clientes para VS Code y JetBrains	Clientes para VS Code y JetBrains
Terminal	CLI interactiva y comandos de automatización	CLI interactiva y automatización sin interfaz
Entorno alojado	Cloud Agent con integración de repositorios	Cloud Agents con integración de GitHub

Tanto la CLI de Kilo como la CLI de Cline funcionan fuera del editor. La CLI se ejecuta donde la inicias, ya sea un portátil, un equipo remoto o CI. Elegir un modelo en la nube no traslada tu shell a un entorno aislado alojado.

Evalúa la nube por separado. Kilo Cloud Agent documenta aprobación automática siempre activa y cargos separados de cómputo e inferencia. BYOK también paga el cómputo. Su página incluye una pestaña de configuración de MCP, pero también indica que el soporte llegará próximamente. No pudimos resolver esa contradicción con la página. No des por hecho que tu configuración local de MCP funcionará allí.

Cline Cloud Agents permite tareas en GitHub, pero actualmente no carga reglas, habilidades, servidores MCP ni conectores. Es una limitación material si tu tarea depende de esas instrucciones o integraciones locales. La lista de funciones locales no demuestra que estén disponibles en la nube.

Compara el flujo y los permisos efectivos

Los agentes integrados de Kilo incluyen code, ask, plan y debug. Ask bloquea las escrituras. Plan puede modificar archivos de planificación en .kilo/plans/. Orchestrator está obsoleto, por lo que las comparaciones centradas en ese modo pueden inducir a error.

Plan y Act de Cline separan exploración e implementación. Plan inspecciona código, pero no modifica archivos ni ejecuta comandos. Act conserva el contexto de la conversación y permite implementar el cambio. Puedes configurar un modelo distinto para cada modo.

El nombre del flujo no describe todas las aprobaciones:

• Los permisos de Kilo usan allow, ask y deny por herramienta. La mayoría tienen valores iniciales permisivos, con excepciones documentadas. Recarga el cliente después de cambiar reglas de permisos del proyecto durante una sesión.
• Auto Approve de Cline controla categorías como ediciones y comandos. YOLO aprueba todas las acciones. La clasificación de comandos seguros depende del indicador requires_approval del modelo, no de una lista fija de comandos permitidos.

Para la primera comparación en el editor, exige aprobación de ediciones, comandos y MCP. Revisa los ajustes efectivos de la versión instalada. La CLI de Cline documenta otro valor inicial de aprobación automática global. Compruébalo al trasladar el flujo a un script. Los clics de aprobación reflejan tanto la configuración como el comportamiento del agente.

Separa el acceso al modelo del coste total

Ambos ofrecen proveedores externos a su propio servicio de facturación. El directorio de proveedores de Kilo incluye proveedores directos, pasarelas y entornos locales. La configuración compatible con OpenAI de Cline permite definir el endpoint, el identificador del modelo y sus capacidades. Iguala el endpoint y el modelo exacto, no solo un nombre como "Sonnet".

La facturación de Kilo Gateway aplica las tarifas de inferencia del proveedor sin recargo y cobra una comisión independiente del 5% al comprar créditos. Como ejemplo hipotético, comprar 20 dólares en créditos cuesta 21 dólares antes de impuestos y financia 20 dólares de uso. BYOK de Gateway sigue pasando por Kilo. El proveedor factura la inferencia según tu contrato.

Cline ofrece pago por uso con créditos y una suscripción ClinePass opcional e independiente. La suscripción, los modelos gratuitos promocionales y una clave API directa son formas de pago distintas. Revisa las condiciones actuales del modelo. No presupongas que una suscripción cubre todos los modelos o trabajo ilimitado.

El coste de una tarea incluye inferencia, reintentos, la parte correspondiente de suscripciones o planes de equipo y, cuando proceda, cómputo alojado. Registra por separado entrada, salida y caché. Un precio por token inferior puede acabar en una factura mayor si requiere más intentos.

Tanto Kilo como Cline documentan inferencia local mediante Ollama, LM Studio y Atomic Chat. Evalúa hardware, capacidad de contexto y fiabilidad del uso de herramientas. Kilo también tiene ajustes de modelos auxiliares, incluida una alternativa de modelo pequeño mediante su pasarela autenticada. Configura esas rutas antes de considerar que todo funciona en local.

Comprueba la migración de reglas y contexto

Las reglas de Kilo usan el array instructions de kilo.jsonc para referenciar archivos o patrones glob. El directorio antiguo .kilocode/rules/ sigue siendo compatible. Las reglas de Cline admiten .clinerules/, .cline/rules/ y AGENTS.md, con instrucciones globales y del espacio de trabajo. Renombrar un directorio no demuestra que se hayan cargado las mismas reglas.

Consulta los ejemplos de configuración y la comprobación de carga en la guía de reglas de Cline.

Las menciones de Kilo pueden incluir archivos, salida del terminal y cambios de Git. El contexto de Cline incluye menciones de archivos y carpetas. Para comparar, proporciona los mismos archivos relevantes. Adjuntar todo el repositorio a uno y archivos concretos al otro cambia el consumo y la información disponible.

Ambos documentan MCP en Kilo y MCP en Cline. Verifica transporte, autenticación, herramientas y aprobaciones del servidor en el cliente elegido. Una conexión MCP puede enviar datos a servicios ajenos al proveedor del modelo. Usar un modelo local no convierte en locales las herramientas remotas.

Las reglas indican al modelo qué hacer. Los permisos limitan las herramientas. Retira los archivos confidenciales del repositorio de prueba. Una instrucción escrita no sustituye un límite de acceso.

La restauración de archivos no revierte acciones externas

Las instantáneas de Kilo permiten volver al momento de un mensaje del usuario, no a un punto intermedio de la respuesta del agente. Si no hay instantáneas disponibles o están desactivadas, la restauración puede retroceder solo la conversación y mantener los archivos modificados. Revisa el aviso y el diff real.

Los checkpoints de Cline permiten restaurar archivos, historial de la tarea o ambos por separado. Restaurar solo los archivos conserva la conversación para intentar otra implementación. Los repositorios grandes pueden aumentar el almacenamiento y el trabajo de los checkpoints.

Ambos documentan almacenamiento de instantáneas separado del historial Git del proyecto. Conserva también un commit inicial. Restaurar archivos o conversaciones no revierte correos enviados, escrituras en bases de datos, despliegues o cargos API. Ese límite procede de la acción externa, con independencia de la interfaz de restauración. Prueba la recuperación con archivos locales desechables antes de permitir acciones sobre otro servicio.

Define qué colaboración necesita tu equipo

Las sesiones de Kilo permiten compartir enlaces para que otras personas las lean o creen una sesión derivada. Sus planes Teams y Enterprise añaden controles organizativos y facturación centralizada, separados de los créditos de modelos.

Cline Kanban ejecuta tareas paralelas en worktrees de Git aislados y es una vista previa de investigación. Cline Enterprise documenta gobierno y observabilidad. Compartir una conversación, ejecutar agentes en paralelo y aplicar políticas organizativas resuelve problemas diferentes. Evalúa la capacidad que necesita tu equipo.

Relaciona la elección con una tarea real

Son criterios de selección basados en los límites documentados, no ganadores de una prueba de rendimiento:

• Para explorar un módulo desconocido sin ejecutar comandos, prueba Cline Plan. Si necesitas inspección mediante shell de solo lectura, prueba Kilo ask.
• Para implementación con permisos e instrucciones por función, evalúa Kilo. Para discutir y después implementar, evalúa el paso de Plan a Act de Cline.
• Si tienes un contrato API o un entorno local, ambos son candidatos. Compara ruta de peticiones, modelos auxiliares, herramientas y factura final.
• Para trabajo desatendido en la nube, verifica ese entorno por separado. Una tarea que depende de reglas locales o MCP puede incumplir requisitos antes de evaluar la calidad del código.

Ejecuta una comparación reproducible

Este es un experimento para que lo ejecutes tú. No lo hemos realizado. Aísla un error para revisar el parche y las aprobaciones antes de pasar a un repositorio grande.

Crea ports.py en un repositorio Git desechable:

def parse_port(value):
    if not value:
        return 8080
    if not value.isascii() or not value.isdecimal():
        raise ValueError("invalid port")
    port = int(value)
    if not 1 <= port <= 65535:
        raise ValueError("invalid port")
    return port

Crea tests/test_ports.py:

import unittest
from ports import parse_port


class PortTests(unittest.TestCase):
    def test_valid(self):
        for value, expected in [(None, 8080), ("80", 80), ("65535", 65535)]:
            with self.subTest(value=value):
                self.assertEqual(parse_port(value), expected)

    def test_invalid(self):
        for value in ["", "0", "65536", "abc", "-1"]:
            with self.subTest(value=value):
                with self.assertRaises(ValueError):
                    parse_port(value)

El fallo inicial previsto es el caso de la cadena vacía. El contrato de entrada admite None o una cadena decimal ASCII. Usa exactamente este prompt en ambas sesiones nuevas:

Corrige parse_port para que solo None seleccione el valor predeterminado. Conserva los puertos válidos del 1 al 65535 y rechaza las entradas inválidas de las pruebas. Mantén la firma pública y las dependencias. Ejecuta python3 -m unittest discover -s tests -v y explica el parche. No hagas commits, no hagas push ni uses servicios externos.

1. Ejecuta las pruebas y guarda el ejemplo en un commit. Crea dos copias limpias de ese mismo commit. Registra las versiones de Python, cliente y sistema operativo.
2. Iguala proveedor, modelo exacto, ajuste de razonamiento disponible y contexto. Desactiva el cambio automático de modelo y MCP. Registra las diferencias inevitables.
3. Iguala las aprobaciones y usa conversaciones nuevas. Fija los mismos límites de gasto y tiempo. Por ejemplo, 2 dólares de inferencia y 10 minutos son límites hipotéticos, no previsiones de coste o duración. Detén la sesión manualmente si el cliente no puede aplicarlos.
4. Ejecuta las pruebas por tu cuenta después de cada intento. Acepta solo si pasan, se respeta el contrato, no cambian las dependencias y no hay ediciones ajenas. Rechaza parches que eliminen aserciones para pasar. Guarda prompt, diff, salida de pruebas y facturación.
5. Prueba por separado la restauración de un archivo desechable. Repite con una tarea de tu repositorio e invierte el orden de ejecución. Un error pequeño no determina la calidad general.

Usa el mismo registro para ambos:

Registro	Qué guardar
Configuración	Commit, versiones, proveedor, modelo exacto, contexto, permisos
Aceptación	Salida de pruebas, revisión del contrato, cambios ajenos
Revisión	Aprobaciones solicitadas, prompts correctivos, ediciones manuales, minutos de revisión
Uso y coste	Tokens, caché, reintentos, cargo final del proveedor, comisiones, cómputo
Parada y recuperación	Límite alcanzado, motivo del fallo, resultado de restauración, efectos externos restantes

Comprueba estos puntos antes de migrar

1. Inventaría reglas del proyecto y globales, endpoints, modelos auxiliares y variables de entorno. Configura las credenciales mediante el procedimiento del destino.
2. Confirma qué instrucciones se cargaron. Pide el comando de pruebas y los límites de edición, y comprueba que la primera acción real los respeta.
3. Reconstruye MCP y las aprobaciones. Verifica una llamada de solo lectura antes de habilitar escrituras.
4. Guarda un commit inicial limpio y prueba la restauración de archivos. No presupongas que el historial o los checkpoints se transfieren entre productos.
5. Completa una tarea representativa dentro del presupuesto. Conserva prompt, parche y factura para decidir a partir de trabajo aceptado.

Las fichas de Kilo Code y Cline enlazan a los productos. Consultamos las fuentes oficiales junto a cada comparación el 23 de octubre de 2026. Revisa el comportamiento de tu versión y de la nube antes de depender de él.