I built Axe because I got tired of every AI tool trying to be a chatbot.
Most frameworks want a long-lived session with a massive context window doing everything at once. That's expensive, slow, and fragile. Good software is small, focused, and composable... AI agents should be too.
Axe treats LLM agents like Unix programs. 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. You can use pipes to chain them together. Or trigger from cron, git hooks, CI.
What Axe is:
- 12MB binary, two dependencies. no framework, no Python, no Docker (unless you want it)
- Stdin piping, something like `git diff | axe run reviewer` just works
- Sub-agent delegation. Where agents call other agents via tool use, depth-limited
- Persistent memory. If you want, agents can remember across runs without you managing state
- MCP support. Axe can connect any MCP server to your agents
- Built-in tools. Such as web_search and url_fetch out of the box
- Multi-provider. Bring what you love to use.. Anthropic, OpenAI, Ollama, or anything in models.dev format
- Path-sandboxed file ops. Keeps agents locked to a working directory
Written in Go. No daemon, no GUI.
What would you automate first?
bensyverson 1 hours ago [-]
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.
jrswab 42 minutes ago [-]
> how you would approach budget when using Axe
Great question and it's something that I've not dig into yet. But I see no problem adding a way to limit LLMs by tokens or something similar to keep the cost for the user within reason.
punkpeye 1 hours ago [-]
What are some things you've automated using Axe?
jrswab 19 minutes ago [-]
I have a few flows I'm using it for and have a growing list of things I want to automate. Basically, if there is a process that takes a human to do (like creating drafts or running scripts with variable data) I make axe do it.
1. I have a flow where I pass in a youtube video and the first agent calls an api to get the transcript, the second converts that transcript into a blog-like post, and the third uploads that blog-like post to instapaper.
2. Blog post drafting: I talk into my phone's notes app which gets synced via syncthing. The first agent takes that text and looks for notes in my note system for related information, than passes my raw text and notes into the next to draft a blog post, a third agent takes out all the em dashes because I'm tired of taking them out. Once that's all done then I read and edit it to be exactly what I want.
zrail 32 minutes ago [-]
Looks pretty interesting!
Tiny note: there's a typo in your repo description.
jrswab 19 minutes ago [-]
nooo! lol but thanks, I'll go hunt it down.
ufish235 59 minutes ago [-]
Why is this comment an ad?
ForceBru 54 minutes ago [-]
This is the OP promoting their project — makes sense to me
stronglikedan 39 minutes ago [-]
How can it be an ad if it's not selling anything? Seems like a proud parent touting their child to me.
jrswab 18 minutes ago [-]
I am pretty proud of this one :)
zrail 38 minutes ago [-]
It's a Show HN. That's the point.
lovich 5 minutes ago [-]
Because they had an AI write it. Their other comments seem organic but the one you’re responding to does not
Orchestrion 16 minutes ago [-]
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.
0xbadcafebee 36 minutes ago [-]
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
jrswab 1 minutes ago [-]
Thanks! Looks like sgpt is a cool tool. Axe is oriented around automation rather than interaction like sgpt. Instead of asking something you define it once and hook it into a workflow.
TSiege 28 minutes ago [-]
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
jrswab 14 minutes ago [-]
I'm happy you brought this up. I've been thinking about this and working on a plan to make it as solid as possible. For now, the best way would be to run each agent in a docker container (there is an example Dockerfile in the repo) so any destructive actions will be contained to the container.
However, this does not help if a person gives access to something like Google Calendar and a prompt tells the LLM to be destructive against that account.
armcat 1 hours ago [-]
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.
jrswab 39 minutes ago [-]
Thanks for checking it out! And yes the tool is indeed catering to that crowed. It's a need I have and thought others could use it as well.
mark_l_watson 1 hours ago [-]
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.
jrswab 32 minutes ago [-]
Exactly! I also made it to chain them together so each agent only gets what it needs to complete its one specific job.
jedbrooke 54 minutes ago [-]
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).
I've not heard of that before but after looking into it I think they are solving different problems.
Dotprompt is a promt template that lives inside app code to standardize how we write prompts.
Axe is an execution runtime you run from the shell. There's no code to write (unless you want the LLM to run a script). You define the agent in TOML and run with `axe run <agent name> and pipe data into it.
saberience 21 minutes ago [-]
I’m having trouble understanding when/where I would use this? Is this a replacement for pi or codex?
jrswab 4 minutes ago [-]
This is not a replacement for either in my opinion. Apps like codex and pi are interactive but ax is non-interactive. You define an agent once and the trigger it however you please.
nthypes 1 hours ago [-]
There is no "session" concept?
jrswab 40 minutes ago [-]
Not yet but is on the short list to implement. What would you need from a session for single purpose agents? I'm seeing it more as a way to track what's been done.
a1o 1 hours ago [-]
Is the axe drawing actually a hammer?
hundchenkatze 55 minutes ago [-]
Looks like an axe to me. The cutting edge of the axe is embedded into the surface. And the handle attaches near the back of the head like an axe. Most hammers I've seen the handle attaches in the middle.
jrswab 41 minutes ago [-]
hahaha; this is what I was going for.
jjshoe 31 minutes ago [-]
Just FYI, your handle is on backwards.
devmor 50 minutes ago [-]
I believe it's actually trying to render a splitting maul, which people often confuse for an axe.
parineum 51 minutes ago [-]
There are many different styles of axe and some don't flair out much.
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.
jrswab 42 minutes ago [-]
This is not an LLM but a Binary to run LLMs as single purpose agents that can chain together.
ozgurozkan 49 minutes ago [-]
The Unix-philosophy framing resonates — focused, composable, single-purpose agents are genuinely safer architecturally than monolithic long-lived sessions with massive context windows.
That said, composability introduces its own attack surface. When agents chain together via pipes or tool calls, each handoff is a trust boundary. A compromised upstream output becomes a prompt injection vector for the next agent in the chain.
This is one of the patterns we stress-test at audn.ai (https://audn.ai) — we do adversarial testing of AI agents and MCP tool chains. The depth-limited sub-agent delegation you mention is exactly the kind of structure where multi-step drift and argument injection can cause real damage. A malicious intermediate output can poison a downstream agent's context in ways that are really hard to audit after the fact.
The small binary / minimal deps approach is great for reducing supply chain risk. Have you thought about trust boundaries between agents when piping? Would be curious whether there's a signing or validation layer planned between agent handoffs.
r_lee 43 minutes ago [-]
wow, like 10 posts within 5 minutes, how great! love me some AI slop on HN @dang
hrimfaxi 24 minutes ago [-]
Yeah ive been going and flagging everything until they're banned. Old account too.
jrswab 17 minutes ago [-]
Thank you for your service.
r_lee 16 minutes ago [-]
salute!
Rendered at 15:45:31 GMT+0000 (Coordinated Universal Time) with Vercel.
Most frameworks want a long-lived session with a massive context window doing everything at once. That's expensive, slow, and fragile. Good software is small, focused, and composable... AI agents should be too.
Axe treats LLM agents like Unix programs. 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. You can use pipes to chain them together. Or trigger from cron, git hooks, CI.
What Axe is:
- 12MB binary, two dependencies. no framework, no Python, no Docker (unless you want it)
- Stdin piping, something like `git diff | axe run reviewer` just works
- Sub-agent delegation. Where agents call other agents via tool use, depth-limited
- Persistent memory. If you want, agents can remember across runs without you managing state
- MCP support. Axe can connect any MCP server to your agents
- Built-in tools. Such as web_search and url_fetch out of the box
- Multi-provider. Bring what you love to use.. Anthropic, OpenAI, Ollama, or anything in models.dev format
- Path-sandboxed file ops. Keeps agents locked to a working directory
Written in Go. No daemon, no GUI.
What would you automate first?
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.
Great question and it's something that I've not dig into yet. But I see no problem adding a way to limit LLMs by tokens or something similar to keep the cost for the user within reason.
1. I have a flow where I pass in a youtube video and the first agent calls an api to get the transcript, the second converts that transcript into a blog-like post, and the third uploads that blog-like post to instapaper.
2. Blog post drafting: I talk into my phone's notes app which gets synced via syncthing. The first agent takes that text and looks for notes in my note system for related information, than passes my raw text and notes into the next to draft a blog post, a third agent takes out all the em dashes because I'm tired of taking them out. Once that's all done then I read and edit it to be exactly what I want.
Tiny note: there's a typo in your repo description.
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.
However, this does not help if a person gives access to something like Google Calendar and a prompt tells the LLM to be destructive against that account.
It looks like Axe works the same way: fire off a request and later look at the results.
how would you say this compares to similar tools like google’s dotprompt? https://google.github.io/dotprompt/getting-started/
Dotprompt is a promt template that lives inside app code to standardize how we write prompts.
Axe is an execution runtime you run from the shell. There's no code to write (unless you want the LLM to run a script). You define the agent in TOML and run with `axe run <agent name> and pipe data into it.
[0]https://inchbyinch.de/wp-content/uploads/2017/08/0400-axe-ty...
[1]https://i.pinimg.com/originals/da/14/80/da148078cc1478ec6b25...
That said, composability introduces its own attack surface. When agents chain together via pipes or tool calls, each handoff is a trust boundary. A compromised upstream output becomes a prompt injection vector for the next agent in the chain.
This is one of the patterns we stress-test at audn.ai (https://audn.ai) — we do adversarial testing of AI agents and MCP tool chains. The depth-limited sub-agent delegation you mention is exactly the kind of structure where multi-step drift and argument injection can cause real damage. A malicious intermediate output can poison a downstream agent's context in ways that are really hard to audit after the fact.
The small binary / minimal deps approach is great for reducing supply chain risk. Have you thought about trust boundaries between agents when piping? Would be curious whether there's a signing or validation layer planned between agent handoffs.