Aside but 12 MB is ... large ... for such a thing. For reference, an entire HTTP (including crypto, TLS) stack with LLM API calls in Zig would net you a binary ~400 KB on ReleaseSmall (statically linked).
You can implement an entire language, compiler, and a VM in another 500 KB (or less!)
I don't think 12 MB is an impressive badge here?
show comments
stpedgwdgfhgdd
“ MCP support. Axe can connect any MCP server to your agents”
I just don't see this in the readme… It is not in the Features section at least.
Anyway, i have MCP server that can post inline comments into Gitlab MR. Would like to try to hook it up to the code reviewer.
bensyverson
It's exciting to see so much experimentation when it comes to form factors for agent orchestration!
The first question that comes to mind is: how do you think about cost control? Putting a ton in a giant context window is expensive, but unintentionally fanning out 10 agents with a slightly smaller context window is even more expensive. The answer might be "well, don't do that," and that certainly maps to the UNIX analogy, where you're given powerful and possibly destructive tools, and it's up to you to construct the workflow carefully. But I'm curious how you would approach budget when using Axe.
show comments
boznz
I will give it a try, I like the idea of being closer to the metal.
A Proper self-contained, self improving AI@home with the AI as the OS is my end goal, I have a nice high spec but older laptop I am currently using as a sacrificial pawn experimenting with this, but there is a big gap in my knowledge and I'm still working through GPT2 level stuff, also resources are tight when you're retired. I guess someone will get there this year the way things are going, but I'm happy to have fun until then.
btbuildem
I really like seeing the movement away from MCP across the various projects. Here the composition of the new with the old (the ol' unix composability) seems to um very nicely.
OP, what have you used this on in practice, with success?
> Each agent is a TOML config with a focused job. Such as code reviewer, log analyzer, commit message writer. You can run them from the CLI, pipe data in, get results out.
I'm a bit skeptical of this approach, at least for building general purpose coding agents. If the agents were humans, it would be absolutely insane to assign such fine-grained responsibilities to multiple people and ask them to collaborate.
show comments
swaminarayan
Axe treats LLM agents like Unix programs—small, composable, version-controllable. Are we finally doing AI the Unix way?
show comments
armcat
Great work! Kind of reminds me of ell (https://github.com/MadcowD/ell), which had this concept of treating prompts as small individual programs and you can pipe them together. Not sure if that particular tool is being maintained anymore, but your Axe tool caters to that audience of small short-lived composable AI agents.
show comments
0xbadcafebee
Nice. There's another one also written in Go (https://github.com/tbckr/sgpt), but i'll try this one too. I love that open source creates multiple solutions and you can choose the one that fits you best
show comments
mark_l_watson
If I have time I want to try this today because it matches my LLM-based work style, especially when I am using local models: I have command line tools that help me generated large one-shot prompts that I just paste into an Ollama repl - then I check back in a while.
It looks like Axe works the same way: fire off a request and later look at the results.
show comments
TSiege
This looks really interesting. I'm curious to learn more about security around this project. There's a small section, but I wonder if there's more to be aware of like prompt injection
show comments
jedbrooke
looks interesting, I agree that chat is not always the right interface for agents, and a LLM boosted cli sometimes feels like the right paradigm (especially for dev related tasks).
One thing I’ve noticed when experimenting with agent pipelines is that the “single-purpose agent” model tends to make both cost control and reasoning easier. Each agent only gets the context it actually needs, which keeps prompts small and behavior easier to predict.
Where it gets interesting is when the pipeline starts producing artifacts instead of just text — reports, logs, generated files, etc. At that point the workflow starts looking less like a chat session and more like a series of composable steps producing intermediate outputs.
That’s where the Unix analogy feels particularly strong: small tools, small contexts, and explicit data flowing between steps.
Curious if you’ve experimented with workflows where agents produce artifacts (files, reports, etc.) rather than just returning text.
show comments
dumbfounder
Now what we need is a chat interface to develop these config files.
creehappus
I really like the project, although I would prefer a json5 config, not toml, which I find annoying to reason about.
punkpeye
What are some things you've automated using Axe?
show comments
a1o
Is the axe drawing actually a hammer?
show comments
let_rec
Is there Gemini support?
show comments
saberience
I’m having trouble understanding when/where I would use this? Is this a replacement for pi or codex?
show comments
zrail
Looks pretty interesting!
Tiny note: there's a typo in your repo description.
show comments
ufish235
Why is this comment an ad?
show comments
Lliora
12MB for an "AI framework replacement"? That's either brilliant compression or someone's redefining "framework" to mean "toy model that works on my laptop." Show me the benchmarks on actual workloads, not the readme poetry.
Cool work!
Aside but 12 MB is ... large ... for such a thing. For reference, an entire HTTP (including crypto, TLS) stack with LLM API calls in Zig would net you a binary ~400 KB on ReleaseSmall (statically linked).
You can implement an entire language, compiler, and a VM in another 500 KB (or less!)
I don't think 12 MB is an impressive badge here?
“ MCP support. Axe can connect any MCP server to your agents”
I just don't see this in the readme… It is not in the Features section at least.
Anyway, i have MCP server that can post inline comments into Gitlab MR. Would like to try to hook it up to the code reviewer.
It's exciting to see so much experimentation when it comes to form factors for agent orchestration!
The first question that comes to mind is: how do you think about cost control? Putting a ton in a giant context window is expensive, but unintentionally fanning out 10 agents with a slightly smaller context window is even more expensive. The answer might be "well, don't do that," and that certainly maps to the UNIX analogy, where you're given powerful and possibly destructive tools, and it's up to you to construct the workflow carefully. But I'm curious how you would approach budget when using Axe.
I will give it a try, I like the idea of being closer to the metal.
A Proper self-contained, self improving AI@home with the AI as the OS is my end goal, I have a nice high spec but older laptop I am currently using as a sacrificial pawn experimenting with this, but there is a big gap in my knowledge and I'm still working through GPT2 level stuff, also resources are tight when you're retired. I guess someone will get there this year the way things are going, but I'm happy to have fun until then.
I really like seeing the movement away from MCP across the various projects. Here the composition of the new with the old (the ol' unix composability) seems to um very nicely.
OP, what have you used this on in practice, with success?
Reminded me of this from my bookmarks.
https://github.com/chr15m/runprompt
> Each agent is a TOML config with a focused job. Such as code reviewer, log analyzer, commit message writer. You can run them from the CLI, pipe data in, get results out.
I'm a bit skeptical of this approach, at least for building general purpose coding agents. If the agents were humans, it would be absolutely insane to assign such fine-grained responsibilities to multiple people and ask them to collaborate.
Axe treats LLM agents like Unix programs—small, composable, version-controllable. Are we finally doing AI the Unix way?
Great work! Kind of reminds me of ell (https://github.com/MadcowD/ell), which had this concept of treating prompts as small individual programs and you can pipe them together. Not sure if that particular tool is being maintained anymore, but your Axe tool caters to that audience of small short-lived composable AI agents.
Nice. There's another one also written in Go (https://github.com/tbckr/sgpt), but i'll try this one too. I love that open source creates multiple solutions and you can choose the one that fits you best
If I have time I want to try this today because it matches my LLM-based work style, especially when I am using local models: I have command line tools that help me generated large one-shot prompts that I just paste into an Ollama repl - then I check back in a while.
It looks like Axe works the same way: fire off a request and later look at the results.
This looks really interesting. I'm curious to learn more about security around this project. There's a small section, but I wonder if there's more to be aware of like prompt injection
looks interesting, I agree that chat is not always the right interface for agents, and a LLM boosted cli sometimes feels like the right paradigm (especially for dev related tasks).
how would you say this compares to similar tools like google’s dotprompt? https://google.github.io/dotprompt/getting-started/
There is no "session" concept?
The Unix-style framing resonates a lot.
One thing I’ve noticed when experimenting with agent pipelines is that the “single-purpose agent” model tends to make both cost control and reasoning easier. Each agent only gets the context it actually needs, which keeps prompts small and behavior easier to predict.
Where it gets interesting is when the pipeline starts producing artifacts instead of just text — reports, logs, generated files, etc. At that point the workflow starts looking less like a chat session and more like a series of composable steps producing intermediate outputs.
That’s where the Unix analogy feels particularly strong: small tools, small contexts, and explicit data flowing between steps.
Curious if you’ve experimented with workflows where agents produce artifacts (files, reports, etc.) rather than just returning text.
Now what we need is a chat interface to develop these config files.
I really like the project, although I would prefer a json5 config, not toml, which I find annoying to reason about.
What are some things you've automated using Axe?
Is the axe drawing actually a hammer?
Is there Gemini support?
I’m having trouble understanding when/where I would use this? Is this a replacement for pi or codex?
Looks pretty interesting!
Tiny note: there's a typo in your repo description.
Why is this comment an ad?
12MB for an "AI framework replacement"? That's either brilliant compression or someone's redefining "framework" to mean "toy model that works on my laptop." Show me the benchmarks on actual workloads, not the readme poetry.