Bash is All You Need for a language model REPL

Hacker News

Share card

Bash is All You Need for a language model REPL

I’ve recently just started tinkering with using local large language models, focusing on simple, low-dependency CLI setups. I ended up going down a bit of a rabbit hole: I wanted to see if I could build a functional model interaction REPL using exclusively standard command-line building blocks. I tried to abide by the Unix philosophy, breaking the REPL into the composition of a few small, single-purpose program. Because the data flow is just text streams fed through pipes, at any step you can inject tools to inspect or modify the data—like using `grep` to filter out strings before they hit the model, or `pv` to benchmark model throughput. Everything is ultimately tied together into an `agent` Bash script that codifies the interaction into a REPL. To my surprise, this setup seemed to be sufficient to get a working “agent” that largely resembles ones built by more complex frameworks. One motivation I have for sharing this here is to embed some semi-rhetorical questions: is that really all there is to a “modern agent”? Are the frameworks and libraries being tossed around overly complex and we really just need to keep it simpler? A few more details of potential interest: - Zero heavy dependencies: No `pip`, `npm`, package managers, virtual environments, etc. It just requires `bash`, `jq`, and `curl` to talk to the local model server. These should be available in most modern CLI environments. - Transparent, file-based state: The agent's memory is just an append-only `.jsonl` file (like `.bash_history`). If you want to rewind the agent's memory, you just run head on the log to drop the last few lines. - Standard exit codes for control flow: Tool execution is handled by checking standard Unix exit codes within a basic bash while loop. I suspect there are scaling limits to doing this all in shell, and I'm still figuring out the most elegant way to handle some of the edge cases, particularly around tool calling - but those appear to mostly be limitations of the underlying models. Nevertheless it's been a really fun experiment in stripping out bloat, and as I mentioned above, somewhat surprising at least from a neophyte perspective. Would love to hear thoughts and comments, particularly around the limitations to this orchestration and what features are otherwise missing due to bypassing the popular frameworks and libraries.