[flagged]
Zerostack – A Unix-inspired coding agent written in pure Rust
311–320 of 334 posts
Re: Zerostack – A Unix-inspired coding agent written in pure Rust
#312No extensions? I think you've missed the point
Re: Zerostack – A Unix-inspired coding agent written in pure Rust
#313Earlier quoted context omitted.
I've been playing with running Claude Code inside a Vagrant VM. I can't be certain it was getting OOM killed when I allowed the VM 4GB of RAM, but when I went to 16 it did seem to be more stable...
> I can't be certain it was getting OOM killed when I allowed the VM 4GB of RAM Of it's actually getting OOMed (and not backing off by itself), I'm pretty sure that's logged in dmesg. Or earlyoom or systemd-oomd if userspace is in play and getting there first.
Thanks for the tip, I will probably try shrinking it back to 4 to see, as that seems like it should be enough RAM for anybody (:
Re: Zerostack – A Unix-inspired coding agent written in pure Rust
#314Earlier quoted context omitted.
Ok, what about having tools be discoverable from the environment, similar to how $PATH works in POSIX? There could be an env var $AGENT_TOOLS, a string of paths delimited by `:` and tools would be discovered as some specific format of file. Maybe a JSON that contains tool name, list of parameters and the command to run it. This is essentially decoupling tools from the agent, allowing more customization and per-projec…
I understand the concept, but I don't get what's the advantage over adding in the prompt instructions to use a specific bash command for a specific task, acting as a "custom tool".
The harness clamps what the agent can do. `bash` allows full code execution; a dedicated `mvn` tool might only allow `mvn compile` but not `mvn spring-boot:run`. You could probably implement this with an `allow` list attached to your `bash` tool, but by doing it this way, you can enhance the outputs or perform mandatory checks too.
For instance, Claude likes to run little Python scripts; reviewing them is tedious. Removing `bash` and adding a `python` tool would allow the harness to pre-review and grep for common harmful patterns, or run the `python` script in a `krunvm` or `muvm` to isolate it, etc. This review/isolation would be handled programatically as it's part of the harness; leaving the agent to choose what to do as a skill means the agent can conveniently forget to enforce its own checks.
Re: Zerostack – A Unix-inspired coding agent written in pure Rust
#315Earlier quoted context omitted.
Creator of Dirac here. Glad to see it mentioned and even more glad that you found it useful. I am currently in deep refactor mode to introduce modular tooling to Dirac since the concept of 'fixed' set of tools is starting to feel antiquated, adding tools on demand would be super convenient and a likely replacement for MCP (I understand not all use-cases of it)
Curious how you’re handling prompt caching, as I understand it most LLM providers essentially inject tool definitions in the system prompt, so changing tools dynamically breaks the cache. This has been a big annoyance for me in a separate project; I currently just implemented my own tool-ish system that defines schemas in user messages and instructs the LLM to return matching JSON, but it’s less reliable than using t…
Native tool calling indeed. By modular, I meant the tool defs are loaded dynamically per task and stay the same during the task
Re: Zerostack – A Unix-inspired coding agent written in pure Rust
#316Earlier quoted context omitted.
Over time software grows. Once big rewriting it in another language is hard and gets harder as the project grows in size. Starting with a resource-saving attitude may be a very good long term strategy. Also: with Rust there are many features of high-level, modern, type-safe, FP-inspired languages that you do not have to miss.
Most FP languages cannot work without GC unless you're willing to give up idiomatic FP programming. There is a reason Haskell has a garbage collector.
Hence I used FP-inspired (to point at languages like Rust, Kotlin, Ruby, Swift)
Re: Zerostack – A Unix-inspired coding agent written in pure Rust
#317I love these. Coding agents aren't very difficult to build, it's a TUI + tools + getting a nice agent loop working. The hardest part seems to be supporting all of the different providers and model quirks. What is interesting is seeing the experimentation: some provide tons of tools, others provide a single python interpreter and have the agent use tools via sandboxed python scripts, others use minimal tools and lean…
Pi.dev is pretty good in giving tons of control to the use and has extensions that you can easily build. Although people are complaining about its RAM usage in this thread, I haven't bothered to check how much RAM it uses.
I refuse to run npm slop on my hardware
Re: Zerostack – A Unix-inspired coding agent written in pure Rust
#318Re: Zerostack – A Unix-inspired coding agent written in pure Rust
#319Earlier quoted context omitted.
Lamenting any 'not even criticism' of Rust as 'denialism' is just evidence of the insane cult that is Rust. Rebuilding Claude Code in Rust will make almost no difference in terms of real world performance. V8 is 'relatively fast', and there wouldn't be any noticeable improvements there, and probably not memory footprint either. The source for Claude Code was leaked and it's a vibe-coded mess, there's not much thought…
You're the delusional one for bringing up the memory usage of the inference server that clearly isn't running inside the coding agent. The problem with your comments is that you're showing off a fundamental lack of understanding between managed languages and unmanaged languages. The vast majority of GCs are optimized for throughput and allocate big chunks of memory. They also tend to never release it if there was a t…
1) I'm not 'delusional' for bringing up 'What Memory is Used Where' - I'm clarifying for the people who seem a bit confused (see above) as to 'where the context lives' - and trying to provide a simple mental model for that.
That's the opposite of delusional.
It's just information.
Attacking people for anything 'Rust related' however - is the quintessential reason why everyone hates the Rust community.
2) 'The problem with your comment' is that it's presumptive and arrogant - as if I 'don't know the difference between GC and managed languages'.
I've been writing software since 1990.
Embedded (on custom Silicon), UI, SaaS, backend, some embedded work I've done is still in production today from almost 30 years ago.
I've written a scripting languages (for production), and cyclic ref-count gc (didn't make it to production).
Your comments about GC etc. are fine - but they but they don't really offer any insight into the actual problem.
There's one critical detail aka 'memory not released after spikes', yes, this is observed behaviour, but it's usually accommodated with a little bit of decent Engineering.
If you're going to make the comparative basis an an 'Idiomatic Rust' solution (aka good patterns), the we should make the assumption of an 'Idiomatic Node' solution for Claude Code.
3) 'The other problem with your comment' is that your conclusion is wrong - by your own hand.
Right here: "Claude Code has severe architectural issues causing it to leak hundreds of gigabytes of RAM," - the implication being that Claude Claude does not inherently have to 'leak all that RAM' - and would run just as fine with some basic work.
An 'Idiomatic Node' implementation of Claude Code wouldn't exhibit those problems, and would perform pragmatically just as well as an Idiomatic Rust implementation.
From a memory management situation, Rust might use significantly less memory, but a 150Mb footprint vs 350Mb foot print for an average session is 'pragmatically immaterial'.
The difference in 'perceived performance' would be negligible - if any.
The 'cost' of writing a the 'kind of program that Claude code is' in a systems-level language would be quite a lot, for not really much benefit.
The 'Rust or C++' solution would not 'run circles' around the 'node' implementation in anything but some 'preformative', inward looking benchmarks, aka 'the worst kind of Engineering'.
Consider pondering why almost nobody writes such applications in Rust or C++.
Re: Zerostack – A Unix-inspired coding agent written in pure Rust
#320"RAM footprint: ~8MB on an empty session, ~12MB when working" I like this, Claude Code is using multiple gigabytes, which is really annoying on lowend laptops
I've been trying to migrate over the zed and think they're Agent Client Protocol[1] is pretty neat, I wonder how much memory pressure Claude Code exerts if it is going through that mechanism instead 1: https://zed.dev/acp
My understanding is that zed wrote a wrapper around 'claude -p' for ACP support so I imagine there isn't too much of a memory savings there since it's still actually running claude code.