Local-first by construction, not by setting

The honest way to protect code is to not move it. The daemon, the Ledger, the Project Brain, and your rules all live on your machine. This page lists what runs where, what can leave, and the controls in your hands, written to be checked against the source, which you can read.

Architecture diagram: the haybox daemon, Ledger, Project Brain, rules and local models all sit inside your machine, and no cross-project path exists at all. Three things can leave: frontier calls direct on your keys, the routing service connection, and a telemetry export that is dashed and off by default.
Architecture diagram: the haybox daemon, Ledger, Project Brain, rules and local models all sit inside your machine, and no cross-project path exists at all. Three things can leave: frontier calls direct on your keys, the routing service connection, and a telemetry export that is dashed and off by default.

What sits inside your machine, and the three things that can leave it. Illustrative.

What runs where

On your machine

  • The daemon (single binary)
  • The Project Brain
  • The SQLite Ledger
  • Your rules and policy files
  • The dashboard, running locally
  • Sandboxed agent workspaces (planned)

Nothing on that list has a cloud counterpart.

On our side

  • The routing service the subscription connects to
  • The website you are reading

That is the whole list.

What can leave, and only how

  • Frontier calls go directly from your machine to the provider you configured, on your keys. They never pass through our servers. What’s sent is the routed request; the Ledger records that it happened and what it cost.
  • No telemetry ships in Stage A. When it arrives it will be off by default and opt-in, you will see the exact payload before anything is sent, and it will be derived categories (task class, hardware class, outcome), never code, filenames, or prompts. We will market that as privacy-preserving, not “anonymous,” because those are different claims and the difference matters.
  • The subscription connection exchanges what routing requires and is documented in the docs at field level.

Isolation between projects

Everything Haybox learns stays with the project it came from, and in v1 that is enforced by there being no cross-project path at all: not a default that can be changed, an absence that can be audited. For agencies and consultancies this is the headline: client A’s code cannot inform suggestions in client B’s repo, and the reason is structural rather than configural.

Blast-radius controls

Native-agent edits will run in isolated git workspaces with per-step checkpoints and one-click revert. Budget caps with alerts and a hard stop will bound frontier spend. Best Quality and Local Only modes are being built to do exactly what they say.

Planned — these arrive with the router and the native agent, and none of them is in the Stage A build.

Supply chain

Model recommendations are pinned and tested before they’re offered; installs run through established runtimes (Ollama, LM Studio, llama.cpp). We treat a model recommendation as an executable-software decision, because it is one.

For security reviewers

The 30-day team audit runs entirely in Shadow Mode: no routing control, no code egress, a report at the end. The daemon core is source-available for review.

Responsible disclosure: security@haybox.ai. A PGP key is published and an acknowledgments page is maintained.

Questions

Where are my API keys stored?

Locally, in your OS keychain where available; details in the docs.

Can my org forbid frontier escalation?

Local Only is a policy setting; org-level policy distribution arrives with team plans.

What about GDPR?

The free product processes personal data on your device; the site and subscription privacy details are in the policy, written in sentences.

Open source · Ledger · Privacy policy