nanobots

Self-improving agent loops for any GitHub repo. An outer loop triages, dispatches, reviews, and learns; nanobot workers claim cards and build inside a disposable Daytona sandbox, then ship PRs. GitHub is the only state store. When the bots are out of their depth, they summon-human.

1

install the looprequired

Scaffolds your repo: prompts and policy into .nanobots/, the Actions workflows, the Projects board, labels, and your secrets. A browser can't do any of that, so this part is a terminal.

# one OpenAI-compatible endpoint
export OCR_LLM_URL=https://api.deepseek.com/chat/completions
export OCR_LLM_TOKEN=sk-...            # ← your provider key
export OCR_LLM_MODEL=deepseek-v4-flash

curl -fsSL nanobots.sh/install | sh

Run it in the repo you want the loop on, with your real key in place of sk-.... That's everything you need to start — init asks for the rest in conversation.

2

add the extensionoptional

Feeds the loop. Screenshot any page, annotate it in place, file it as an issue the board picks up. The loop runs fine without it — GitHub issues are intake either way — but this is the fastest way to get a real bug in front of it.

Chrome Web Store →

It will tell you if a repo you file to has no loop installed yet.

credentials

One OpenAI-compatible endpoint covers the first three. The rest init gathers in conversation, so you don't need them in hand before you start.

the three you export first

These name the endpoint Open Code Review (OCR) uses to review the loop's PRs — and nanobots reuses them for its own agentic work rather than asking for a second key. The same endpoint runs the init conversation, the review, and the optional autofix responder.

OCR_LLM_URL
Any OpenAI-compatible /chat/completions endpoint — DeepSeek, OpenAI, Together, Fireworks, or a local server.
OCR_LLM_TOKEN
Your provider key. init stores it as a repo secret via gh, on stdin — it never passes through a command line.
OCR_LLM_MODEL
Any model with tool calling. Cheap is fine; this is reviewing and asking questions, not writing your code.

the ones init collects

Asked for, explained, and verified during setup.

CLAUDE_CODE_OAUTH_TOKEN or ANTHROPIC_API_KEY
A separate credential, and the one that actually writes code — it powers the outer loop and the workers. Subscription or metered; any Anthropic-compatible base URL also works, and NANOBOTS_WORKER_CMD swaps the engine entirely.
DAYTONA_API_KEY
Required. Workers only ever build in a Daytona sandbox. init proves the key works by creating and destroying a real sandbox before it stores it.
PROJECTS_PAT
A classic PAT with repo + project + read:org. The default GITHUB_TOKEN cannot touch org Projects v2 at all.

the opinions

Most of this is a small number of choices held firmly. Disagree with them and you'll fight the tool.

  1. GitHub is the only state store. Issues are intake, a Projects board is the kanban, PRs are the audit trail. No database, no dashboard, no account. If it isn't on GitHub it didn't happen — so you can always see what the loop did, and always override it by hand.
  2. Workers never run on your machine. Every worker builds in a disposable Daytona sandbox, destroyed when the run ends. Not an option — the only worker runtime. Agent-written build commands don't touch your laptop.
  3. The sandbox gets a credential that can't do much. A short-lived, repo-scoped GitHub App token per run, revoked after. It grants contents:write and deliberately not pull_requests: a leaked token can push to a branch nobody watches, and that's the whole blast radius. The controller opens the PR.
  4. Review is not optional. Every PR a nanobot opens gets an independent review on that exact head SHA. Critical and high findings block the merge; a failed or unparseable review blocks too, and is never read as clean. Your team's own pull requests are left alone — installing nanobots does not take over your review process.
  5. Humans are a gate, not a bottleneck. Nothing is built until someone replies /nanobots start <hash> to a versioned plan. The hash covers the plan text, so an edited plan invalidates the approval instead of quietly shipping.
  6. Hard gates come from reading your repo. No canned list of scary categories. init reads your code and proposes specific paths with reasons, and you edit them. "Payments" is not a gate; src/billing/stripe.ts is.
  7. The loop edits its own policy. Every outcome appends to LEARNINGS.md; periodically it distills those into the triage rubric and recipes, and commits that. The policy docs are its weights. Your rubric is supposed to drift from the template.
  8. Billing is an env var. CLAUDE_CODE_OAUTH_TOKEN runs on a subscription, ANTHROPIC_API_KEY is metered, NANOBOTS_WORKER_CMD swaps the engine entirely. Cheap models for labour, a frontier model for judgment.