Everything a solo developer needs to run the full stack on one machine — hardware, setup, task division, and the switches that stay off until you flip them. For the short hardware-only reference, see Prerequisites. For the separate team/central path, see the Team Setup Guide.
| Preset | RAM | GPU | Disk | Notes |
|---|---|---|---|---|
| Claude only (default) | 8 GB floor | not required | ~1 GB (toolkit) | all inference is remote |
| Claude + one cloud provider | 8 GB floor | not required | ~1 GB (toolkit) | same footprint — inference stays remote |
| Claude + one local runtime | 16 GB minimum, 32 GB recommended | Apple Silicon, or NVIDIA with 8–24 GB VRAM on Windows/Linux | +50 GB for model weights | the only preset with a real local footprint |
Running Arth Intelligence and/or arth-memory locally (Docker) adds +2–4 GB RAM on top of whichever preset you picked, and needs no GPU — that cost is independent of which model-execution preset you’re on.
A local model may claim at most total RAM − 12 GB. The 12 GB reserves
room for the OS, your IDE, Claude Code itself, and Docker if Intelligence or
Memory are running locally (Docker itself is capped around ~4 GB of that
reserve).
This isn’t just a guideline — setup enforces it mechanically. The
local-runtime menu in /provider-setup only ever shows models that fit
inside your actual free RAM at the moment you run it; a model that doesn’t
fit is never offered, not offered-with-a-warning. Two more constraints keep
this predictable:
| Platform | Support |
|---|---|
| macOS, Apple Silicon | native — every preset, every layer |
| Linux | native — every preset, every layer |
| macOS, Intel | cloud presets only — Claude only / Claude + one cloud provider. The local-runtime preset is not offered (no Metal, and CPU-only inference on Intel Macs is impractical). |
| Windows, via WSL2 | supported — install Ollama and Docker inside the WSL2 distro. Ollama may instead run Windows-native and be reached from WSL2 over localhost, if you prefer managing it outside the distro. |
| Windows, native (no WSL2) | out of scope — not a supported target for any local-runtime or Docker-backed layer. |
/arth-setup asks exactly two questions to place you on this map:
stack in ~/.arthai/config.json, additive beside
posture and never colliding with the memory-tier mode key.The substrate rule: one place runs everything. If you pick the local
preset, the same local runtime serves execution, the Explain-LLM prompt,
and memory extraction — there’s no scenario with two different local
runtimes active for different jobs. Embedding models are the one
exception: they’re pinned per memory store (nomic-embed-text today),
chosen for you, and never surfaced as a setup choice.
/provider-setup probes :11434 (Ollama) and :1234
(LM Studio) before offering anything — it never presents a runtime it
hasn’t seen answer.brew install ollama for you, but only after you explicitly confirm, and
it always states the model’s download size up front before pulling it.Model recommendation is RAM-derived:
| Your RAM | Recommended model | Alternates |
|---|---|---|
| 16 GB | Qwen-Coder 7B | — |
| 32 GB+ | Qwen3-Coder 30B-A3B (quantized) | Devstral, gpt-oss-20b |
Every recommendation — default or alternate — is still gated by the conformance probe (§4 of the provider-registry proposal): a model that fails the tool-use probe is offered for one-shot use only, never wired into an execution lane.
Mixing in a cheaper model isn’t “let it do whatever” — the default division
of labor is fixed, and it’s what the stack preset actually generates as your
model-policy.override.yml:
| Role | Who does it | Why |
|---|---|---|
| Planning | Claude, always | the tier that needs judgment stays on the strongest model |
| Code review | Claude, always | code-reviewer stays pinned, never inherit — review never silently follows whatever wrote the code |
| Execution | the cheap model | this is the tier that benefits from cost/latency wins |
| Scanning / bulk I/O | the cheap model | low-judgment, high-volume work |
| Protected paths (migrations, billing, auth) | Claude, always | never delegated, regardless of tier — no override changes this |
| Two consecutive failures | escalate back to Claude | the cheap model doesn’t get a third try; Claude takes over |
You can hand-edit the generated override after the fact — setup writes a
default, not a lock — but a re-generate regenerates it from the same
rules, so a hand edit and a re-run can diverge; check the diff.
Skip /router-setup by default. For one person, the toolkit’s built-in
triage routing already does the job — a central router’s value (budgets,
pools, org policy, decision audit) is org-shaped, not solo-shaped.
Adopt it later only when one of three signals shows up:
Running /router-setup later costs nothing structurally and fails open
(a router outage never blocks you) — delaying adoption is never a one-way
door.
The cloud preset needs exactly one credential: the API key for whichever
provider you picked, stored in ~/.arthai/.env (mode 600), referenced by
name only everywhere else (descriptors, proxy config, catalog rows —
never the value itself). Conformance-probe runs cost cents — they’re a
handful of short completions per probe, not a benchmark suite.
Two different kinds of “switch” exist, and they’re deliberately not the same mechanism:
ARTH_ORCHESTRATE_ENABLED or a future ARTH_EVAL_VIEWS_ENABLED for
arth-intelligence’s eval views — are environment variables, default
OFF, and are written only by a setup skill as the side effect of a
choice you made (e.g., picking the local-runtime preset flips the
execution-adjacent flags it needs). You never hand-edit one into
~/.arthai/config.json, and in a team setting they are never
seat-flippable centrally — each seat’s local choices stay local.ARTH_MEMORY=off|local|cloud for a one-off A/B
test) stay scoped to the run that set them — they don’t persist into
config and don’t need setup to touch.