Skip to main content
That last step is the one worth getting to, so this page takes the short route to it rather than covering everything base can do. Five commands, in order, and then the loop runs on its own.
base works with Claude Code today. Codex and Antigravity support is on the way. Where a step below names Claude Code specifically, it is because the install target has to be concrete — everything else applies to whichever agents you run.

Install

base is one Rust binary. You can build it from source on any platform, or take the prebuilt archive on Windows.
The Windows build script imports the MSVC developer environment and resolves LLVM and libclang, which bindgen needs for the vendored RocksDB. If you would rather not set up a toolchain, take the prebuilt archive instead.

What base install does

Running the installer is the only step that touches anything outside the current directory, so it is worth knowing exactly what it changes:
  • It puts the binary at ~/.local/bin/base.
  • It creates ~/.base-gbl/, which holds your global configuration and the global tier of the graph.
  • It wires base into Claude Code’s hook pipeline by editing ~/.claude/settings.json.
  • It offers to install the starter star commands — *handoff, *fork, *base and *end — so there is something to type on day one.
Two flags are worth knowing about up front:
Use --starter-commands to accept them without being asked instead.

Set up a workspace

A workspace is any directory you want base to know about. Scaffolding one creates a .base/ directory for its configuration and registers it globally, so base can resolve it later from anywhere on the machine.
base scaffold takes an optional path if you would rather not change directory first.

Teach it one thing

Everything base knows arrives through commands like this one. Start with a rule, because a rule is the shortest path to seeing the whole loop work.
A rule belongs to a domain. A domain is a named subject with triggers attached to it — keywords and file paths that decide when its rules are relevant. Rules live in the graph; the domain’s triggers live in domains.toml. You can add the reasoning as well, which is worth doing when the rule would otherwise read as arbitrary:
Ask for it back to confirm it landed:

Map the code

Registering a project tells base which directory it covers. Syncing the AST reads that directory with tree-sitter and records every function, class, import and call relationship.
Now questions about the code are queries rather than searches:
Every command has a short alias, so the same four lines are base a q -c "auth", --calls, -f and -i. Run base help <command> for the rest.

Watch it arrive on its own

The commands above are the part you drive. The part you do not drive is the reason base exists. Open Claude Code in the workspace you just scaffolded and touch a file inside the mapped directory. The file’s shape — its entities, its imports, what depends on it — arrives in the turn before the agent reads its contents. Then type a prompt that mentions migrations. The rule you wrote arrives with it, because the prompt matched the domain. Nobody asked for either one. That loop is the product: you teach the graph once, and it speaks up on its own from then on. To see what would arrive for a given piece of text before you send it, ask directly:

If something looks wrong

base doctor checks graph health across both tiers and exits nonzero when it finds a problem. Add --repair to quarantine malformed lines and rewrite the good set, which backs up first. Add --json if you are reading it from a script.

Where to go next

How it works

The four points in an agent’s turn where context gets placed, and what the graph holds.

Command reference

Every command, grouped by whether it is safe to run without thinking about it.