thepoet

I suspect also to do with internal Slack etc. where employees vote on launch posts (a lot of them on HN since long). Not a scam or accusing anyone but this probably propels a lot.

Yes absolutely, the current Kobo one uses the Mac's mic. I work near a window on my Mac so this is handy without any hardware setup.

If you have a Kobo (~ US$ 120 or even less used) you can run this using Cobalt https://github.com/BandarLabs/Cobalt/tree/beta/apps/birds

Perfect! BW should work the best as it is the one I test on. We have merged the Libra branch to main, it will still show grayscale but should work. I am working with contributors on adding Color support to the UI components.

Yes, issues is where we are talking currently, though we have started a sub on Reddit too for those who are not on GitHub and want to share suggestions, bugs, app requests /r/CobaltForKobo

Current priority is a stable SDK, support for oauth and token for adding apps like Dropbox, read later ones etc. and a larger app ecosystem eventually.

Hey, we have merged support for the Color devices, actual colorful displays still testing. Let me know if you would like to test it. Happy to get any feedback on this.

Thanks! Can you please create two separate issues in the project for both Elipsa Gen1 support and the other for the stockfish and tailscale client implementation support. Would love to discuss and collaborate with you on both. I would need your help to test on the actual Gen1 device.

There are current issues and PRs for Clara HD and Color devices support so we can take it up by common generations.

I can help to port it for your device if you can help by testing it on your Color.

This project has an OPDS client implemented as an app example here, tested on Gutenberg's OPDS and standard eBooks. https://github.com/BandarLabs/Cobalt/tree/main/examples/gute...

Thank you for the kind words. I will add a page to the project explaining the differentiation.

NickelMenu is a mature project and perfect at what it does, we just have different goals. NickelMenu is designed to extend Kobo's stock interface. Cobalt is designed to be an app platform like Android has for example. I wanted app creators to just write their app logic and not build things like a UI toolkit for their apps, app lifecycle and rendering support (framebuffer drawing, partial eInk refreshes, touch input handling etc.), bluetooth handling, sensor and more. Anything launched through NickelMenu like KOReader or Plato have to implement these on their own.

AFAIK NickelMenu command actions spawn arbitrary shell cmds that inherit root from Nickel, we avoid it by running apps as separate unprivileged processes with declared capabilities like network, storage, audio, fronlight etc.

I also wanted to provide ability to quickly build apps with the SDK and our simulator to test apps on before putting it on the real device, an app store to get new apps over the WiFi after the initial USB install.

This was more oriented on making my life easier, say I have an app idea that I want on my Kobo tomorrow and how quickly can I bring it live on the device. The 'you can run apps' I wrote was meant to signify anyone can now create apps using the SDK without bothering about the device specific bits and publish them and install it via Cobalt's app store. I hope this clarifies things.

Hey, author here. NickelMenu is terrific and Cobalt uses it to show the menu item in the default Kobo menu. It's just that Cobalt and NickelMenu are not the same in terms of project goals.

I created this as I could not find anything existing that gives the capabilities I wanted. I read several things downloaded over web apart from books on my Mac and phone, which I would prefer to do on an eInk display. Search papers on arxiv and read them offline later, Substack, even spending a lot of time on chess puzzles, monitor my Claude/Codex remotely, generate explainer audiobooks and listen to them on my bluetooth speaker etc.

The longer battery and the display makes some use cases really shine and I wanted to create apps for my own Kobo and potentially helpful for others as well.

Thank you for this! This is perfect and what I was looking for while building the UI components for an SDK for Kobo e-ink apps https://github.com/BandarLabs/Cobalt

I have high myopia that is progressively getting worse so started working on building an app development platform for my Kobo eReader so that I can live without my mac and phone. https://github.com/BandarLabs/Cobalt

Have built the SDK and some apps like an HN Client, ChatGPT client, Claude Code permissions sidekick, RSS Reader, some games etc. (all in the same above repo)

It has 8x less powerful hardware than a modern raspberry pi but runs Linux with an eink display, wifi bluetooth and a good battery life for $100 or something.

NickelMenu is fantastic for adding custom buttons and some extra. We use it to display the Cobalt entry button on the stock Kobo interface.

This SDK provides more of an android/iOS type framework to use underlying hardware like bluetooth, wifi, battery and a bunch of UI components for creating complex apps with eink rendering, notifications, managed windows, OTA updates, a simulator, a sidekick mode for your apps and more.

I have a Kobo that was kept unused in a similar state for a few years until I decide to build an SDK platform to develop and deploy apps on it. My Kobo does not support apps on its Linux platform.

I have been using it to read HN, as an RSS reader over my news and blog sources, generate audiobooks on topics I want to understand with ElevenLabs, Exa and OpenAI and listen via connecting its bluetooth to my speakers and even as a remote Claude Code & Codex approval sidekick.

It is amazing that a $100 device with a single core and 512mb RAM can do so much and run for so long.

Here is the open-sourced platform https://github.com/BandarLabs/Cobalt

I have tried to do this, but most newer Kobo cannot due to CPU architecture support limitations. https://wiki.postmarketos.org/wiki/Kobo_Clara_BW

The older ones which do are severely restricted in features, and often end up with several issues. Have you tried it personally?

A bit idealistic for the crowd here but has some good points.

The other day I wanted to build personal apps for my Kobo device. It has a single ~800Mhz core and 512 MB of RAM, probably eight times less than a rasbperry pi, but runs a Linux.

I wanted to break free from watching my laptop screen for long Claude sessions partially due to degrading eyesight and have a sidekick for approvals streamed to the Kobo. Apart from the Claude and Codex permissions sidekick done via hooks, I ended up building an entire SDK, an HN client, an RSS discovery & reader and an audiobook generator using deep research and ElevenLabs API all running on it.

Anyone using an LLM can now personalize it for their own Kobo device, which might have some nuances over my Clara BW. Significantly less work I hope than doing it all from scratch even with a coding agent.

https://github.com/BandarLabs/Cobalt

An earlier larger discussion 22 days ago on this https://news.ycombinator.com/item?id=48834924

We will be soon including this in Tarit, a firecracker alternative https://github.com/instavm/tarit

Currently we have to supply a kernel to run the OCI as a microVM with a warm pool.

  TARIT_KERNEL=/path/vmlinux

  taritd image build --oci ubuntu:24.04 --name ubuntu
  taritd vm create --image ubuntu

Yes, we have been using this internally too. If you use it and encounter any bugs or have ideas for improvement, please file it. I will have a look.

Interestingly we did a version of a shared communication bus over MCP here https://github.com/instavm/murmur

The idea being mostly to use all of the coding agent subscriptions which are much cheaper than API access in order to delegate tasks, break down into chunks and distribute or even the standard coder/reviewer pattern.

Hey, this is exactly what we do at https://instavm.io Agents get persistent storage that outlive the sandbox and when the agent spins up again you get access to the computer with same files.

The images or rather portable artifacts rehydration on any platform plus the packaging is neat. I have been working on https://instavm.io for some time around VM based sandboxes and related infra for agents and this is refreshing to see.

Hi Ben, one of the founders of InstaVM here. Congrats on the launch!

Here is a feature tour of InstaVM https://instavm.io/blog/meet-instavm-infra-for-your-agents We would be publishing on the tech soon.

Would love to give you a demo of InstaVM and trade notes. Let me know abhishek@instavm.io

One of the things that makes Clawdbot great is the allow all permissions to do anything. Not sure how those external actions with damaging consequences get sandboxed with this.

Apple containers have been great especially that each of them maps 1:1 to a dedicated lightweight VM. Except for a bug or two that appeared in the early releases, things seem to be working out well. I believe not a lot of projects are leveraging it.

A general code execution sandbox for AI code or otherwise that used Apple containers is https://github.com/instavm/coderunner It can be hooked to Claude code and others.

This looks cool, congratulations. We investigated WASM for our use case but then turned to Apple containers which run 1:1 mapped to a microVM for local use here, which is being used by a bunch of folks https://github.com/instavm/coderunner

We are currently also building a solution InstaVM which is ideologically the same but for cloud https://instavm.io

The blog says more about keeping the user data private. The remote models in the context are operating blind. I am not sure why you are nitpicking, almost nobody reading the blog would take remote code execution in that context.

I am working on a chess analytics tool, specifically a free and open source replacement of Chessbase in this age of LLMs that can run on all platforms. The idea is to lower the barrier of entry to use a chess improvement tool since Chessbase can be intimidating for a causal Chess.com beginner looking to go into serious chess prep. At present, it can do basic queries like H2H score of Magnus Carlsen vs Hikaru Nakamura, the top 10 juniors in the US, Magnus Carlsen's games with the London system opening and involving a queen sacrifice etc. Though getting it to work for advanced multi-step tactical patterns and finding games with certain imbalances in the query using natural language is getting challenging. DuckDB has helped a lot, along with modern LLMs for query generation with schema and some preprocessing of game PGNs and piece hashes. It can also import a user's Chess.com and Lichess games given the usernames and do similar queries as on Master level games.

I also used the tool to generate an Adult Chess improvers FIDE rank list for all federations around the world. Here are the July 2025 rankings though it still needs major improvements in filtering - https://chess-ranking.pages.dev

------------------

Another idea that I have been working on for sometime is connecting my Gmail which is a source of truth for all financial, travel, personal related stuff to a LLM that can do isolated code execution to generate beautiful infographics, charts, etc. on my travels, spending patterns. The idea is to do local processing on my emails while generating the actual queries blindly using a powerful remote LLM by only providing a schema and an emails 'fingerprint' kind of file that gives the LLM a sense of what country, region, interests we might be talking about without actually transmitting personal data. The level of privacy of the 'fingerprint' vs the quality of queries generated is something I have been very confused with.

No, Gemini-cli still is on your local machine, when it generates some code based on your prompt, with Coderunner, the code runs inside a container (which is inside a new lightweight VM courtesy Apple and provides VM level isolation), installs libraries requested, executes the generated code inside it and returns the result back to Gemini-cli.

This is also not Gemini-cli specific and you could use the sandbox with any of the popular LLMs or even with your local ones.

We looked at Pyodide and WASM along with other options like firecracker for our need of multi-step tasks that require running LLM generated code locally via Ollama etc. with some form of isolation than running it directly on our dev machines and figured it would be too much work with the various external libraries we have to install. The idea was to get code generated by a powerful remote LLM for general purpose stuff like video editing via ffmpeg, beautiful graphs generation via JS + chromium and stuff and execute it locally with all dependencies being installed before execution.

We built CodeRunner (https://github.com/BandarLabs/coderunner) on top of Apple Containers recently and have been using it for sometime. This works fine but still needs some improvement to work across very arbitrary prompts.

Interestingly, this test has been in the public domain for the last seven years, since it is part of all possible chess games with 7 or less pieces, which is solved and published. It is a huge file, but the five pieces games dataset with the FEN is less than a GB. I wonder if it even got included in the training data earlier, or if it will be.