Get Started
Guide

Configuration

Where credentials live, and the small config file you commit

Two places matter:

FileWhat it holdsCommit?
~/.local/share/thespider/auth.toml (and the OS keychain)Who you are, on one or more serversNo
.thespider/config.toml in the repoServer, project, profile, model bindingsYes

thespider-agent setup writes both. You almost never edit auth.toml by hand.

Project config

.thespider/config.toml
# Optional. Public Cloud is the default.
# server  = "https://thespider.xyz"

project = "acme/payments"
profile = "security"

[[model]]
code  = "xai/grok-4.6"
agent = "grok"                 # grok, claude, codex, or opencode
timeout_seconds = 1200

code is a models.dev id in <lab>/<model> form: who made the model, not who serves it. The same string is what you bind, what the server catalogs, and what reports group by.

TheSpider offers models that can actually run an audit slice (text in and out, recent, 200k+ context, reasoning). The CLI caches the catalog for 24 hours; --refresh re-downloads it.

A block may set agent, command, or both. When both are present, command wins. Any agent other than the four built-ins needs a command. harness still works as a deprecated alias of agent. Full field table: runner contract.

Another agent, or a freeform command

[[model]]
code    = "alibaba/qwen3.8-max"
agent   = "pi"
command = "pi run --model qwen3.8-max {prompt_path}"
timeout_seconds = 1200

See custom runners for the stdout contract and check-models.

Commands you will actually run

thespider-agent setup --model xai/grok-4.6 --agent grok --profile security
thespider-agent check-models              # offline; no server, no model
thespider-agent run --once --max-slices 1

--code and --harness still work as aliases of --model and --agent.

On run / daemon, the agent walks up from the checkout to find .thespider/config.toml, loads the org token for that server, then uses --profile if you passed it, else the file's profile, else the project's default.

Running both profiles

profile in the file is only a default. A campaign is pinned to one profile, so auditing the same repo for Security and Bugs means two campaigns, and the flag always wins over the file:

thespider-agent run --once --profile security
thespider-agent run --once --profile bugs

For unattended runs, start one daemon --profile ... per profile; each polls only its own profile's campaigns. When you continue a specific campaign with --campaign N, the profile comes from the campaign and you can drop the flag. If you never want a default, leave profile out of the file entirely.

The [[model]] bindings say how this machine runs a model — they apply to every profile. Which of them actually get used for a given profile is the project's decision, set per profile in the web UI under Settings → Models (one switch per profile, per model). run claims the intersection, refine picks its fix and retest models from it, and thespider-agent models prints it — so you can give Security and Bugs different models without touching this file, and everyone on the project gets the same answer.

A model enabled for a profile but not bound here is reported by run as a warning: its slices are planned and this agent cannot claim them.

More than one server

SituationWhat to do
Public Cloudsetup with no --server
On-premsetup --server https://spider.corp.example and set the same server in the file
Local devsetup --server http://localhost:8080

logout clears the project's server by default. logout --server URL or logout --all for others.

Copyright © 2026