Agente doméstico con kimaki: la cuota gratuita de OpenCode
Hola, soy un inútil.
Era de los que estaban en contra de tener un agente residente en el servidor de casa, y no lo puse en marcha porque parecía difícil de conseguir con la cuota gratuita, pero al final me entraron ganas de hacer desde fuera tareas como investigaciones en paralelo o trazar gráficos sencillos de estadísticas que me llamaban la atención.
Así que andaba pensando: «¿cómo puedo montar un bot lo más parecido a OpenCode nativo?». OpenClaw tiene un repositorio impresionante, pero tenía ganas de usar algo distinto, y buscando encontré una cosa llamada Kimaki, así que lo probé.
Antes de esto, había intentado envolver OpenCode y ejecutarlo como un bot agente, pero gestionar aquí las numerosas actualizaciones era incómodo, así que, si era posible, prefería resolverlo con algo ya existente.
Lo que buscaba:
Que afirme claramente ser compatible con Discord.
Que se pueda operar gratis dentro de la cuota de suscripción de OpenCode.
Usar Kimaki
Instalación
https://github.com/remorses/kimaki
npx -y kimaki@latestCon esto, si no tenías OpenCode instalado, se instalará; y bun también se instalará porque es una dependencia necesaria.
Y basta con invitar al bot de Kimaki a tu servidor desde el enlace que aparece al final.
Además, en este caso, por defecto el bot funciona a través de Kimaki, así que es mejor evitar contenido confidencial en los mensajes, y probablemente convenga crear un servidor de Discord dedicado.
No hay que pasar por la molestia de crear el bot desde tu propio Dev Portal, así que en cuanto a comodidad está bastante bien.
En cuanto al cambio de modelo, se puede cambiar mediante /model, así que se puede resolver en cierta medida solo desde Discord.
Además, en relación con esto, OpenCode parece usar una cabecera HTTP específica al realizar llamadas a la API, como se muestra a continuación.
https://github.com/earendil-works/pi/issues/2824
¿Será que, como diseño del lado del servidor de la API, devuelven 429 en lugar de 403 para hacer que resulte menos evidente y así evitar el abuso? De hecho, aunque en OpenCode se puede emitir una API Key y supongo que hay cierta intención de limitarla al agente de OpenCode, con el estado actual las peticiones a este endpoint pueden autenticarse con dicha API Key quieran o no, por lo que creo que cada vez habrá más casos de uso en los que las empresas tengan que adoptar nuevos mecanismos de autenticación o soluciones orientadas a prevenir el abuso.
Por ejemplo, si se pudiera implementar mTLS repartiendo certificados de cliente a los usuarios, almacenándolos en chips de seguridad como TPM dedicados o controladores EC, y creando un mecanismo que solo permita invocarlos a través de una ruta fija, quizás terminaría el mundo actual en el que se puede acceder libremente a todo.
Sin embargo, al final eso tampoco sirve de nada si los certificados de cliente acaban siendo extraídos mediante ingeniería inversa. Aun así, considerando el gran salto de la tecnología TPM actual, en la que desbloquear la contraseña del BIOS se ha vuelto muy complicado, puede que en el futuro aparezcan funciones que ayuden también a mejorar la seguridad de las aplicaciones integradas en el hardware, vaya uno a saber.