Using Kimaki for a Home Agent with OpenCode's Free Tier
Hello, I'm useless.
I had been against having an agent resident on my home server, and since it seemed difficult to achieve within the free tier, I hadn't done it. But as expected, I started wanting to have it do parallel research and plot simple charts of statistics I was curious about, from outside.
So I was thinking, how can I set up a bot that's close to native OpenCode? OpenClaw's repository is impressive, but I wanted to use something different, so I searched and found something called Kimaki, which I tried out.
Before doing this, I had also tried wrapping OpenCode and launching it as a bot agent, but managing the changes on my end was tedious, so I hoped to solve it with an existing solution if possible.
What I wanted:
Proper Discord support claimed
Can be operated for free within OpenCode's subscription quota
Using Kimaki
Installation
https://github.com/remorses/kimaki
npx -y kimaki@latestIf OpenCode isn't installed, this will install it, and bun is required as a dependency, so it will be installed as well.
Then all you need to do is invite the Kimaki bot to your server from the link that appears at the end.
Also, in this case, the bot runs via Kimaki by default, so you should avoid sending confidential content, and I think you should probably create a dedicated Discord server.
Since there's no hassle of creating a bot from your own Dev Portal, it's quite convenient.
As for model switching, you can change it via /model, so you can handle it to some extent just through Discord.
Also, in relation to this, OpenCode seems to use a dedicated HTTP header when making API calls, as follows:
https://github.com/earendil-works/pi/issues/2824
Is the API server designed to return 429 instead of 403 to make it harder to understand and avoid abuse? Actually, while OpenCode can issue API keys, I think there's an intention to restrict them to OpenCode's agents. But because requests to this API endpoint can inevitably be authenticated with an API key as things stand, I think new authentication mechanisms—or rather, solutions for companies that want to prevent abuse—will become more common going forward.
For example, if a mechanism were created that distributes client certificates to users via mTLS and stores them in a security chip like a dedicated TPM or EC controller, so that they cannot be invoked unless through a fixed route, the current world of freely hitting APIs might come to an end.
However, in the end, it would be meaningless if the client certificate could be extracted through reverse engineering. But considering the recent advances in TPM technology, and the fact that BIOS password removal has become quite difficult, we might see features that also lead to improved security for hardware-integrated applications in the future.