BosunCadre

BosunCadre can handle any AI automation task.

Work is described as a pipeline: a sequence of stages drawn from a fixed vocabulary — scope, brief, execute, review, land — and a pipeline is itself configurable data, which an operator can list, validate and replace with bosun pipeline from a JSON definition. A stage definition can set a minimum difficulty — a pipeline may raise the floor its review is held to, and never lower it — and a failure ladder can be declared per pipeline; six shapes ship as defaults, and a seat with no pipeline scope serves exactly those six. Two things are roadmap rather than shipped: stages outside those five, which validation rejects, and gates of your own — a declared gate is checked for a non-empty kind, and auto-land is the one kind the coordinator acts on.

BosunCadre pools the models already on hand — a local Qwen on a GPU, a Claude/GPT API key, a spare computer — and offers each task first to a worker rated for its difficulty: a complexity-strict task waits for one, while an ordinary task may go to a lower-tier worker with the capabilities it needs after a two-minute grace window. Routine drafting can run on a local model, and review goes to a stronger one. Self-hosted: you own the hardware and the data.

Bulk mechanical work drafts on a local model. A frontier model reviews it, and nothing lands until a human approves it — "cheap builds, frontier reviews".

Doing the work on a local LLM and having it checked by a paid frontier LLM can reduce AI costs. How much depends on your hardware, your models and your work, and it is not guaranteed: a stronger local model can widen the class of work that never reaches a paid API at all. Your own install keeps a ledger, so you can measure it: bosun cost prints what the frontier models were spared, beside what they were paid.

Status

Working software, pre-release. Live today: the coordinator and runners, the agentic executor with a human land gate, multi-project routing, a self-update channel, licensing and activation, and an MCP server so an AI session can drive it as tools.

Quickstart

One machine, from a checkout of this repository. Needs Go 1.25+ and git, and ~/.local/bin on your PATH.

make install                                  # builds and stamps into ~/.local/bin
bosun version                                 # 0.1.0+<build>.<commit>

mkdir -m 700 -p ~/.bosun                      # the coordinator opens the db, it never creates the dir
bosun-coordinator --db ~/.bosun/bosun.db &    # HTTP + SQLite, listens on :7000
for i in $(seq 30); do curl -fsS http://localhost:7000/healthz >/dev/null 2>&1 && break; sleep 1; done
curl -fsS http://localhost:7000/healthz >/dev/null || echo "the coordinator is not answering on :7000"
bosun init                                    # writes the CLI config, prints a join token
bosun project create demo --use               # work is queued into a project, so make one
bosun task add "summarize README.md in one sentence"
bosun board

This runs without login and listens on all interfaces; keep it on a trusted network, or see REMOTE_ACCESS.md to turn on token auth.

The console is at http://localhost:7000/app.

To route work to a local model, with Ollama already listening on :11434:

bosun endpoint add-ollama                     # registers each Ollama model as a $0 endpoint
bosun endpoints                               # id, model, tier, price, availability

If Ollama was already listening when you ran bosun init, its models are registered for you (at tier 3). add-ollama registers them at the tier you give it (--tier, default 45). Which tasks a runner takes depends on the runner's own tier against each task's difficulty, not on an endpoint's tier, so a plain task runs on a newly joined runner with or without add-ollama. An endpoint is somewhere work can run, not something that runs it: you still need a runner (bosun runner join …, printed by bosun init) before anything leaves the queue.

bosun doctor prints the fleet's health and flags queued work that no worker can run, as [!!! UNSTAFFED !!!] — expected on a fresh one-machine install until a runner joins, and it still exits 0. Of everything it checks, only three make it exit non-zero, and each is something you must fix: insecure permissions on the config, a host stranded behind its update channel, and version drift across the fleet. docs/USER_GUIDE.md covers the rest: more machines, tokens, activation, and the review-and-land loop.

Docs

• docs/USER_GUIDE.md — install it, drive it, review its work, keep it licensed.
• docs/DANGER-ZONES.md — the parts that fail silently, and what to verify instead of trusting a passing test.

Architecture (one line)

A small always-on Go coordinator (HTTP + SQLite) holds the task, runner and endpoint state, a priority queue with an atomic-claim scheduler that offers each task first to workers whose tier meets its difficulty (strict tasks wait for one; others fall back after a two-minute grace period), and a cost ledger. Runners (AI sessions, local-LLM daemons) and endpoints (Ollama, frontier APIs) register and pull tasks.

---

Copyright © 2026 Acribayik Synapsis LLC. Source-available under the Business Source License 1.1 — see LICENSE.md. It is not open source; SOURCE-AVAILABLE.md explains why that distinction is deliberate. Each version converts to the GNU Affero General Public License, Version 3.0 (AGPL-3.0-only) two years after it is first made publicly available, as LICENSE.md states.