// honest

What Bonfire can't do yet.

If we admit what's broken, you can believe what we claim. Every other section of this site claims capability. This page earns the right to claim. Updated whenever a limitation shifts.

• No public API. Runs locally via CLI.

  Bonfire is a Python package you install locally. There is no hosted dispatch API, no SaaS endpoint, no web console. A hosted API is designed in the framework's architecture spec as a Phase 2 target, but it is not implemented today. If you need to trigger pipelines from another service, you write a subprocess call.

• Single operator. No team billing, no shared workspaces.

  Bonfire v1 is designed for one developer on one machine. Multi-seat billing, shared workspaces, team Vault, SSO, and audit logs are Phase 2 and Phase 3 targets. If you are buying for a team today, you are buying one seat per engineer with their own local Vault.

• Vault is local-only. Collective intelligence is designed, not implemented.

  The Vault (LanceDB-backed local knowledge graph) stores YOUR patterns on YOUR machine. A shared / collective intelligence layer where multiple operators benefit from each other's Vault accumulation is documented in the v1 architecture spec but not shipped. Fork the framework, start fresh: your new Vault is empty.

• Python only. TypeScript, Go, Rust on the roadmap. Not today.

  Bonfire orchestrates agents written as Python modules with structural prompts in markdown. Other language runtimes for agent implementations are a Phase 2-3 target. If your team does not run Python, Bonfire is not yet a fit.

• Requires Anthropic API key. Bring your own keys and budget.

  Bonfire talks to the Claude Agent SDK. You pay Anthropic directly for every token. The framework ships per-agent, per-stage cost tracking and budget caps so you never get surprised by the bill, but it does not include credits or proxy billing. `max_budget_usd` is a hard cap, not a suggestion.

• Token estimation uses a heuristic, not the real tokenizer.

  The priority-prompt-compilation layer estimates tokens via a simple `chars / 4` rule with a 15% safety margin. Real tiktoken counts are a known-limitation Phase 2 upgrade. The safety margin absorbs most under-estimations, but exotic prompt shapes (long Unicode, heavy code blocks) may fall outside it. The 15% margin is tuned for the common case, not the adversarial one.

• No community forum yet. GitHub Issues and a README.

  There is no Discord, Slack, or forum at launch. Community infrastructure needs critical mass to not feel dead, and critical mass takes traffic first. A community channel arrives when there are at least 100 weekly-active users to welcome a newcomer. Until then: open a GitHub issue, the maintainer reads them.

• No Windows support. macOS and Linux only.

  Bonfire uses POSIX subprocess semantics for its git / test / CLI orchestration. It has not been tested on Windows, and WSL2 is the only supported path if you must run from Windows. Native Windows support is a Phase 3 target dependent on real demand from the disillusioned-professional persona.

• Tree-sitter queries are not finished.

  The framework's Cartographer parser uses tree-sitter for language-aware code chunking. The full query set across all supported languages is in active development at the time of launch (framework-lane tickets BON-228 through BON-232). Expect incomplete coverage on languages beyond Python and TypeScript until that chain lands.

• No SOC 2. No compliance certifications of any kind.

  Bonfire is an open-source framework running on your own machine with your own API keys. There is nothing to certify at the framework layer. If your employer requires SOC 2 / ISO 27001 / HIPAA / GDPR compliance for software you run locally during development, talk to your security team about running Bonfire inside your existing compliant environment. A hosted SaaS tier with SOC 2 would be a Phase 2-3 target predicated on enterprise demand that does not exist yet.