DeepSeek Super-Agent: cuánto cuesta un agente de código proactivo

Actualizado November 2, 2026 · publicado originalmente November 2, 2026

El Super-Agent de DeepSeek (dsh-superagent) es un prototipo de investigación con licencia MIT que consulta GitHub periódicamente, convierte las peticiones de personas autorizadas en tickets y hace que una sesión de trabajo abra una pull request. Limita los trabajadores en paralelo (3 por defecto), pero no tiene tope de tokens ni de gasto, así que la factura del modelo solo la controlan tu clave de proveedor y tu configuración.

Este artículo se publicó por primera vez el 2 de noviembre de 2026 a partir del README y de la cobertura de prensa, y se reescribió el mismo día tras leer el propio repositorio (su documentación, sus prompts y su código fuente). Los datos proceden del repositorio del proyecto y de Help Net Security. Bloomberg informó del lanzamiento como un desafío a Claude Code; DeepSeek no ha publicado ningún benchmark frente a él, así que toma ese enfoque como posicionamiento, no como un resultado.

¿Qué hace?

• Entrada: consulta GitHub mediante la línea de comandos gh, por defecto cada 60 segundos. No hay webhooks. Por esta vía llegan las menciones, los issues y pull requests suscritos, los comentarios de revisión y los resultados de CI. El chat de Feishu es un plugin opcional aparte que viene desactivado; la instalación solo con GitHub es la predeterminada documentada.
• Admisión: una petición es explícita cuando una persona autorizada se dirige al agente. Cualquier otra cosa es un candidato inferido que un modelo debe evaluar. Mientras no haya nadie en una lista de permitidos, ninguna petición puede convertirse en ticket.
• Trabajo: una pequeña sesión de enrutamiento decide qué hacer con cada disparador. Cada ticket aceptado recibe su propia sesión de trabajo persistente en su propio directorio, normalmente un git worktree. El trabajador implementa, comprueba, hace commit, hace push y abre una pull request con la propia cuenta de GitHub del agente, y después sigue la CI y la revisión.
• Estado: el README lo llama “prototipo de investigación solo como referencia, no un producto oficial de DeepSeek” y dice que se trate como código de investigación, no como software listo para producción.

¿Adónde va el dinero?

Consultar GitHub no consume tokens del modelo. El gasto empieza cuando se llama a un modelo. En el código eso ocurre en tres lugares:

1. La sesión de enrutamiento lee cada disparador admitido y lo encamina. Por tanto, cada petición explícita cuesta al menos un turno de enrutamiento antes de que empiece ningún trabajo.
2. El evaluador juzga los candidatos inferidos. Esto importa para el ajuste predeterminado: en modo observe el agente sigue ejecutando la evaluación y solo registra “habría aceptado” en lugar de actuar. El modo observe es un modo sombra para las acciones, no para el coste. Por defecto el agente solo recibe los mensajes que se dirigen a él, así que los mensajes sin destinatario llegan al evaluador solo si activas los interruptores de observación de todo el repositorio para issues, pull requests, comentarios o CI.
3. Las sesiones de trabajo hacen el trabajo real: leer código, editar, ejecutar comprobaciones, reintentar tras fallos y gestionar rondas de revisión. Cada trabajador tiene su propio contexto, que es donde se va la mayoría de los tokens.

El modelo del enrutador/evaluador y el de los trabajadores se configuran por separado, y el modelo de un trabajador queda fijado cuando se crea su sesión. El código no tiene contador de tokens, ni tope por ticket, ni libro de gasto, y el panel no muestra uso ni coste. El único código relacionado con el presupuesto detecta un error de “presupuesto excedido” del proveedor durante los reintentos y lo muestra como una advertencia de estado; no detiene el trabajo. La documentación de DeepSeek no indica un coste por pull request.

¿Qué límites existen?

Una ranura de trabajador sigue ocupada mientras se ejecutan sus trabajos en segundo plano, así que el tope de trabajadores es también un tope de gasto de tokens concurrente, aunque no un tope de cuánto gasta cada trabajador.

¿Qué necesita y cuáles son los riesgos?

• Una cuenta de usuario de GitHub dedicada para el agente con acceso de escritura. Una GitHub App no puede ser el agente porque el agente lee las notificaciones. También necesita el entorno de ejecución DeepSeek Harness (dsh), Node, pnpm, git, tmux y gh.
• Acceso total. Las sesiones de trabajo se ejecutan con el perfil de permisos de acceso total como el propio usuario del sistema operativo del operador. El proyecto dice que sus envoltorios de comandos son valores predeterminados, no un límite de seguridad. Ejecútalo en una máquina o cuenta aislada.
• El estado crece sin límite. Las notas de arquitectura dicen que los registros antiguos aún no se eliminan.

¿Cómo presupuestar una prueba?

Usa el registro de peticiones que habría aceptado para dimensionar el trabajo y después valóralo con tus propias mediciones. El gasto mensual es elementos de trabajo aceptados x coste facturado medio por elemento, donde el coste por elemento incluye el turno de enrutamiento, cualquier evaluación, cada llamada de un trabajador, cada reintento y cada intento abandonado. Divide el gasto total entre los elementos que se convirtieron en cambios aceptados, como en el coste por tarea exitosa.

Ilustración con datos supuestos, no de DeepSeek: 200 elementos de trabajo al mes con un coste facturado medio supuesto de $4 cada uno son $800. Si solo 140 producen un cambio aceptado, el coste por cambio aceptado es $800 / 140 = $5,71, no $4. La diferencia es el precio del trabajo abandonado y rechazado.

¿Qué controles conviene configurar primero?

• Mantén pequeña la lista de permitidos y añade personas de forma deliberada. Es la primera barrera de gasto.
• Deja desactivados los interruptores de recibirlo todo hasta que hayas leído el registro de lo que habría aceptado, porque son los que envían tráfico sin destinatario al evaluador.
• Pon maxWorkers bajo en una prueba, y coloca el verdadero tope de gasto en la clave de tu proveedor de modelos o en tu gateway, ya que el proyecto no tiene ninguno. Consulta los tres presupuestos de un agente y las barreras de gasto en producción.
• Etiqueta el gasto por repositorio y ticket para poder rastrear una pull request hasta su factura.
• Deja el merge en manos de personas y trata el prompt de entrega como un archivo de políticas con un responsable.

¿Cómo se compara con otros agentes de GitHub?

Otras tres opciones convierten una petición de GitHub en una pull request. Lo que difiere es dónde aparece el gasto y qué lo limita. Comprobado el 2 de noviembre de 2026; confirma en la página de cada proveedor.

La diferencia práctica es que las opciones alojadas están dentro de una factura que ya gobiernas (una asignación de Actions, una clave de API con límites de espacio de trabajo) y documentan topes de turnos o de tiempo, mientras que Super-Agent deja todo eso en tus manos. Para comparaciones de coste a nivel de herramienta, consulta coste de Cursor vs Copilot vs Claude Code.

¿Deberías desplegarlo ahora?

Para producción, no: el propio DeepSeek dice que no está listo para producción. Para una prueba acotada en un repositorio no crítico, en una máquina aislada y con una clave con tope, es una forma barata de aprender cuánto cuestan los agentes proactivos a tu equipo, porque el código es gratis y el gasto es visible en tu propio proveedor. La métrica de decisión es el coste por pull request aceptada frente a la atención que ahorra, no el titular de que compite con otra herramienta.

Relacionado

• ¿Qué es DeepSeek Harness?
• Distribución en subagentes y límites de concurrencia
• Agentes en segundo plano y el reloj del coste
• Coste de Cursor vs Copilot vs Claude Code

¿Quieres aplicar esto a tu plataforma? Comparte las facturas, los registros de la pasarela y los flujos principales; identificaremos los costes y las oportunidades de ahorro. Solicitar auditoría gratuita →

Volver a finopsllm.com