Plano gratuito do OpenCode para agente doméstico com kimaki
Olá, sou o Inútil.
Eu era contra ter um agente residente no servidor de casa, mas como parecia difícil conseguir isso com o plano gratuito, acabei não fazendo. Porém, com o tempo surgiu a vontade de fazer investigações em paralelo e também de plotar, de forma simplificada, gráficos de estatísticas que me interessam, tudo isso a partir de fora de casa.
Foi então que pensei: “como seria possível criar um bot o mais próximo possível do OpenCode nativo?” O repositório do OpenClaw está incrível, mas, por querer usar algo diferente, pesquisei e encontrei o Kimaki, então resolvi usá-lo.
Antes disso, cheguei a tentar envolver o OpenCode e executá-lo como um agente bot, mas gerenciar a adaptação a tantas mudanças dava trabalho, então pensei que seria melhor, se possível, resolver com algo já pronto.
O que eu buscava:
Que tivesse suporte adequado ao Discord;
Que pudesse ser operado gratuitamente dentro da assinatura do OpenCode.
Usando o Kimaki
Instalação
https://github.com/remorses/kimaki
npx -y kimaki@latestCom isso, se você não tiver o OpenCode instalado, ele será instalado, e como o bun é necessário como dependência, ele também será instalado.
E depois, basta convidar o bot do Kimaki para o seu servidor pelo link que aparece no final.
Além disso, nesse caso, por padrão, o bot opera via Kimaki, então é melhor evitar conversas com conteúdo confidencial e, provavelmente, criar um servidor Discord dedicado.
Não há o trabalho de criar o bot pelo seu próprio Dev Portal, então, em termos de praticidade, parece bom.
Sobre a troca de modelo, ela pode ser feita pelo comando /model, então dá para resolver bastante coisa apenas pelo Discord.
Além disso, relacionado a isso, parece que o OpenCode usa um cabeçalho HTTP específico ao fazer chamadas de API, como abaixo.
https://github.com/earendil-works/pi/issues/2824
Será que o servidor da API foi projetado para retornar 429 em vez de 403, para dificultar o entendimento e evitar abusos? Na verdade, acho que existe a intenção de restringir as API Keys emitidas pelo OpenCode ao agente do OpenCode, mas, como atualmente as requisições a esse endpoint de API podem, querendo ou não, ser autenticadas com a API Key, acho que soluções para novas formas de autenticação, ou melhor, medidas para empresas que querem evitar abusos, tendem a se tornar mais comuns daqui em diante.
Por exemplo, se fosse criado um mecanismo em que, via mTLS, certificados de cliente fossem distribuídos aos usuários e armazenados em chips de segurança, como TPMs dedicados ou controladores EC, e que só pudessem ser acionados por um caminho fixo, talvez o mundo atual, em que se pode acessar livremente essas APIs, chegasse ao fim.
Mas, no fim das contas, se o certificado de cliente for extraído por engenharia reversa, isso também não adianta nada. No entanto, considerando o grande avanço da tecnologia TPM e o fato de que remover a senha do BIOS se tornou bastante difícil, talvez surjam recursos que também melhorem a segurança de aplicações integradas ao hardware, quem sabe.