Show HN: Axe – A 12MB binary that replaces your AI framework

A new open source tool called Axe aims to turn large language model “agents” into small, composable Unix-style CLI programs defined via TOML, enabling users to chain focused tasks like code review, blog drafting, or log analysis without heavyweight frameworks or daemons. Commenters are intrigued by this lighter-weight, automation-centric alternative to chat UIs and MCP-based systems, comparing it to similar tools and sharing pipelines where agents pass files and artifacts between steps. Key questions center on cost control, persistent state, security and prompt-injection safeguards, directory and config layout, and whether a 12MB Go binary is truly “minimal” in practice.

Overall Concept and Positioning

  • Axe is a small Go binary that treats LLM “agents” like Unix commands: each agent is defined in TOML, does one focused job, and is composed via the shell (pipes, files, scripts).
  • It is not an LLM itself but a runtime that calls LLM APIs (including OpenAI-compatible ones, and others like Gemini planned).
  • Compared to other tools:
    • Different from in-code prompt templates (e.g., dotprompt) because it’s a CLI execution layer, not an app framework.
    • Closer to shell-based “tiny agents” or claude -p workflows, but with a more structured agent/config and chaining model.
    • Seen as more automation-oriented than interactive tools like sgpt, Pi, Codex, or Claude’s full IDE integrations.

Use Cases and Pipelines

  • Several multi-step flows described:
    • YouTube transcript → blog-style post → Instapaper.
    • Voice notes → related note lookup → blog draft → cleanup (e.g., remove em dashes).
    • “Ghost blog” with each step saving artifacts to files between agents.
  • People propose:
    • Code refactoring, test generation, build harnesses, and PR prep as a “junior dev in the repo.”
    • Git commit message generation.
    • RPG character creation workflows and invoice-like processing.

State, Artifacts, and “Memory”

  • Agents commonly pass data via files between steps; some users archive and summarize artifacts with git integration.
  • Session support is requested but not yet implemented; current use skews toward explicit file-based state.
  • Some enthusiasm for “persistent memory”; others criticize the term as vague and potentially overcomplicated, asking for clearer, minimal explanations.

Cost Control

  • Single-purpose agents are seen as helpful for keeping prompts small and behavior predictable.
  • Concerns raised about accidentally fanning out many agents and cost explosions; token or budget limits per agent are discussed but not yet fully designed.

Security and Safety

  • Prompt injection and destructive actions (e.g., with calendars, email, GitLab) are core worries.
  • Suggested mitigations:
    • Running agents in containers (e.g., Docker) and path-sandboxed file skills.
    • Network egress allowlists for outbound connections.
  • Some skepticism about relying on chroot or similar as true security boundaries; security primitives at this layer are still evolving.

Implementation Details and Trade-offs

  • 12MB binary size triggers debate:
    • Some see it as large compared to ultra-small Zig binaries.
    • Others note Go’s runtime overhead and consider 12MB acceptable or minor.
  • Config details:
    • Uses TOML; a few would prefer JSON5.
    • Default agent location under ~/.config feels wrong to some; they want per-repo agents for better versioning.
  • Mixed preferences on UX:
    • Some prefer chat interfaces for iterative planning, then Axe-like tools for deterministic execution.
    • Desire expressed for a chat-based helper that generates Axe configs and for a shared “Awesome Axe” agent catalog.

Conceptual Debates

  • Debate over very fine-grained agents for coding:
    • Critics argue human analogues would be inefficient.
    • Supporters counter that narrow LLM responsibilities increase reliability and trust.
  • Terminology disputes appear (e.g., “clankers” for AIs), with some finding it funny and others off-putting.