Configuration

Both agents are configured from inside themselves — slash commands in the terminal, menus in the browser — and keep what they learn about a repository in files you can read and commit.

Models

The agent handles the engineering workflow: the plan, the isolated copy, the tests, the reviews and the approvals. The model you choose does the reasoning. You can change models at any time, even between two tasks in the same session.

In AlbertCode SWE Agent, /disconnect removes a saved key and /disconnect all removes every key (Settings… → Providers in the browser).

The key or address is checked before it is saved, and a provider is shown as connected only once that check has passed.

Local models

Start your model server, then connect it by address. The usual addresses:

With a local model, your code never leaves your computer.

What a model needs

The model must support tool calling reliably: that is how it reads files, runs tests and makes changes. Most current hosted models do; among local models, results vary with size and quantisation. Check one before relying on it:

albertcode models test      # or: albert-mini models test

How much the model thinks

Keys and privacy

• Keys are kept by your operating system: the macOS Keychain, Windows data protection, or your Linux desktop keyring. Without a keyring (servers, containers, SSH sessions) they go in a file only your user can read.
• A key goes only to the provider it belongs to, is never shown again, and is never given to the commands a task runs.
• If a saved key turns up in a file or command output, AlbertCode SWE Agent masks it before anything goes to the model.
• There is no telemetry and no account.

The repository contract

AlbertCode SWE Agent. A repository can carry a contract that sets what AlbertCode may do there: which paths a change may touch and how big it may be, which commands may run, which checks must pass, which reviews are required, and who may approve. With no contract, sensible defaults apply: a change keeps to the files its plan named, files that look like secrets are never changed, credentials are never written into files, and both reviews run.

AlbertCode reads the first of these at the repository root: albertcode.contract.toml, albertcode.contract.json, .albertcode/contract.toml, .albertcode/contract.json. It is read from your repository, never from the isolated copy, so a task cannot widen its own limits.

version = 1
name = "shop"

[scope]
forbidden_paths = ["src/payments/**", "infra/**", "**/migrations/**"]
max_files_changed = 15

[verification]
required = true
must_pass = [["npm", "test"]]

[approvals]
require_admin_for_risk = ["high"]

Commit it, and a plan that wants to touch src/payments is refused at once, a change that fails npm test cannot be accepted, and a high-risk plan waits for an administrator.

You don't have to write it by hand: /contract (or Contract and memory… in the browser) drafts one from a description, shows it in full, and saves it when you say so. Every saved version is kept and can be restored.

The full format is in docs/contract.md.

Custom commands

A command is a prompt you write once and call by name — a Markdown file. Both agents support them.

---
description: Review a file for correctness bugs
agent: reader          # optional: run as this custom agent
mode: ask              # optional: ask, governed or direct
argument-hint: <file>
---
Review $ARGUMENTS for correctness bugs, not style. Start with $1.

Saved as .albertcode/commands/review.md, it is /review. Keep commands in .albertcode/commands/ in a repository (shared when you commit it) or in commands/ in your settings folder (every repository, for you only). $ARGUMENTS is everything typed after the command; $1 to $9 are its words. A command is text: running one runs no program — it is sent as your own message, and the mode and approvals apply as if you had typed it.

Custom agents

An agent is a role a task works as. It can only narrow what the agent may do, never widen it.

---
description: Reads and reports; never edits
tools: read, run
---
You are reviewing someone else's change. Find correctness bugs, with file and line.

Keep agents in .albertcode/agents/ or in agents/ in your settings folder; choose one with /agent. With no tools line, an agent changes only the instructions. An agent that cannot edit answers questions only.

AlbertCode SWE Agent also has saved tools, skills and plugins — see docs/extending.md.

MCP servers

Both agents can use MCP servers: outside tools such as Git, browsers, databases and your company's services. The quickest way is the connectors gallery (/connectors or /mcp in AlbertCode SWE Agent; albert-mini mcp connectors in mini-AlbertCode). To add any server:

# A local server: a command the agent starts, with its variables
albertcode mcp add docs --command "npx -y @example/docs-mcp" --env DOCS_TOKEN=xyz

# A remote server that signs you in with OAuth (a browser window opens)
albertcode mcp add tracker --url https://mcp.example.com/mcp

mini-AlbertCode uses the same shape: albert-mini mcp add NAME --command "…" or --url URL. Remote sign-ins ask only for the scopes the server names, and tokens are kept in your system's key store. What an MCP server's tools are given goes to that server.

Environment variables

AlbertCode SWE Agent:

Where things are kept

In your repository — yours to read, edit and commit: custom commands and agents in .albertcode/commands/ and .albertcode/agents/. AlbertCode SWE Agent also keeps the contract, .albertcode/requirements.json, .albertcode/memory.md (what it has learned about the repository) and .albertcode/skills/ there.

On your computer, outside the repository:

These hold task history, sessions, the isolated copies and settings. uninstall --all removes them.