Getting started

From nothing to a real, verified result in about fifteen minutes.

1 · Install

On Linux and macOS, one line. It picks the right build for your machine, checks it against the release checksums, and refuses to install on a mismatch.

curl -fsSL https://akilios.dev/install.sh | sh

On Windows, take the .zip from the download page and put both executables on your PATH. Full detail in Install.

akili-code --version

2 · Activate your models

Akili Fundi (Code) and Akili Core are served by Akili's own gateway. There is no provider key to obtain or paste — and deliberately no field in Settings offering to take one. Whoever administers your organization issues you a personal access token:

export AKILI_API_BASE="https://api.akilios.dev/v1"
export AKILI_API_KEY="akili_live_…"

Or put those two lines in a .env file beside your project. Open Settings and the Akili provider should read Active — models included.

3 · Let it read before it writes

From any project directory:

akili-code inspect
akili-code ask "what does this project do, and where would I add an HTTP route?"

ask seeds a context pack from your question, spreads relevance across the dependency graph, and sends only the files that matter. It cites the paths it relied on. Nothing is written.

4 · Make a change you can check

akili-code edit src/main.rs "add a --version flag" \
  --apply --verify --revert-on-fail

Those flags are the point: --apply writes it, --verify runs your project's build and test ladder, and --revert-on-fail puts the file back if verification fails. The worst case is that nothing happened. Add --repair=2 to let it read the failure and try twice.

5 · Let the agent build something

akili-code-ui

Open… a folder, tick Agent · write files, and describe an outcome rather than a task:

It writes a plan and ticks steps off as it goes; if it notices it is repeating itself it re-plans rather than grinding to the step limit. When it finishes, open the Diff tab: red/green counts per file, Keep to commit, Revert to discard. A checkpoint was taken before the run either way.

Working well with it

• Describe the outcome, not the steps. "Add a dark-mode toggle that persists" beats a list of files to edit.
• Start on Core, move to Fundi when the thinking gets hard. Switch from the chat bar mid-conversation.
• Let it verify. Asking it to "run the tests and fix what breaks" costs a few more tokens and saves the round trip.
• Prefer targeted edits. A run that rewrites whole files burns budget; edit_file sends a snippet diff instead.