HN Explorer

11 comments

[ 5.9 ms ] story [ 59.7 ms ] thread
fractorial
I’m not quite sure why the harness itself needs to be small. Isn’t the system prompt and management of system prompt the bit you want lightweight?
paoloanzn
What about running agents on embedded devices with small resources? maybe even multi agents flows? good luck trying to do that with codex, let alone claude code
bitbasher
Here I was thinking 1MB still feels way too large.
tmzt
Are there any with small system prompts that are still useful, especially with local models and subagents?
orliesaurus
i love the idea, but you also need to maintain it long term: in today's world what is the best practice to do that... do you spin up an agent anytime codex-cli updates and mirror the updates in c++ and push a new release? or idk... set up an automated process that does this on a worker on CF in a sandbox when npm updates @openai/codex?
paoloanzn
there is already a wrapping script when you install it, every time i publish a new release it will detect it a prompt it to update (if you want to).
realexweb
Nice size. I've been fighting the same fight in Rust and landed at 1.9 MB for a static-pie musl binary, which is about as far as I could push it without giving up features.

Two things that cost me the most, curious if they hit you the same way in C++: shelling out to curl and tar for HTTPS and decompression instead of linking them, which saved maybe 15 MB but means those tools have to exist on the host, and staying static, since musl won't dlopen from a static binary at all, so there's no plugin split available as an escape valve.

What's actually in your 1 MB, and did you have to give anything up to stay under it?