jrswab

Yes, I've used it with on OpenAI compatible API from an internal LLM at my job.

Sorry, I need to update that. I just added MCP support a day or so ago.

You don't have all the Claude Code overhead. It only gets what you give it.

I'm excited to see how this plays out. Keep me updated on x(twitter)

Love to hear it! Thanks for checking it out and feel free to put up an issue on GitHub if you have any ideas for improvements.

Yes, I think it will be quite trivial to make a output allow list. That's a great idea!

I've shared a few flows I use a lot right now in some other comments.

That's my dream.

Not yet but it will be easy to add. If you need it can you create an issue in GitHub? I should be able to get that in today.

> Curious if you’ve experimented with workflows where agents produce artifacts (files, reports, etc.) rather than just returning text.

Yes! I run a ghost blog (a blog that does not use my name) and have axe produce artifacts. The flow is: I send the first agent a text file of my brain dump (normally spoken) which it then searched my note system for related notes, saves it to a file, then passes everything to agent 2 which make that dump a blog draft and saves it to a file, agent 3 then takes that blog draft and cleans it up to how I like it and saves it. from that point I have to take it to publish after reading and making edits myself.

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.

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.

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.

Thank you for your service.

I am pretty proud of this one :)

nooo! lol but thanks, I'll go hunt it down.

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.

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.

Exactly! I also made it to chain them together so each agent only gets what it needs to complete its one specific job.

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.

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.

hahaha; this is what I was going for.

This is not an LLM but a Binary to run LLMs as single purpose agents that can chain together.

> 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.

Me too! I just shared with a coworker that the binary is only 6.57MB and running in a Alpine Docker container is only 24MB.

Hi everyone, I built Axe because I got tired of the "everything is a chatbot" pattern in AI tooling.

Axe treats LLM agents like Unix programs. Each agent is a TOML config with a focused job such as a code reviewer, a log analyzer, or a commit message writer. You run them from the CLI, pipe data in, get results out. Chain them together. Trigger them from cron, git hooks, CI.

Whatever you already use.

Some things that make it different:

- No framework lock-in: it's a single binary with two dependencies

- Stdin piping: `git diff | axe run reviewer` just works

- Sub-agent delegation: agents can call other agents via tool use

- Persistent memory: agents remember across runs without you managing state (if you need)

- Path-sandboxed tools: file ops are locked to the agent's working directory

Written in Go because I wanted fast cold starts and easy distribution. No daemon or GUI.

This is early stage to solve a need I have. I would love feedback on the agent config format and the skill system.

What's missing? What would make you actually use this?

This is a great thought. I'll have to do some planning around this. Though I'd assume if you don't like light roasts you'd not be buying them and then would have nothing to rate. But trusting the users to not "hate rate" may not be the bust idea.

haha yes, thank you for sharing. I wanted to get out an MVP to see if people would actually want something like this. It was a balance between spending too much time making it perfect upfront vs. getting something out to test the desire for a site link this.

Thanks for giving it a look! And thank you for the kind words

Yes, scaling is going to be in interesting problem to solve. I may need accounts for things in the future such as saving beans and making lists or something but for the functionality of rating and finding beans I want to stay account-less.

I love your suggestion about adding some gamification to the site. I'll have to think about how that could be done well in the context of coffee.

The go-htmx-forge is the base for this web app :)