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 | 32 GB minimum, 48 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 — see the context floor below |
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.
Claude Code sends its own system prompt and tool schemas with every
request: ~36,778 tokens before any of your code. A model loaded at the
commonly-quoted 32,768 therefore cannot start at all — the runtime refuses
the very first request with n_keep: 36778 >= n_ctx: 32768. Load 98,304.
(The “32k floor, 64k sweet spot” advice circulating online assumes a 6–10k
preamble; 64k would leave about one large file’s worth of working room.)
That floor is what moves the RAM requirement. The KV cache is charged on top of the model weights, and it scales with layers and attention heads — not with how many parameters are active — so a mixture-of-experts model does not make it cheaper:
| Context | KV cache (fp16) | KV cache (q8_0) |
|---|---|---|
| 32,768 | ~4 GB | ~2 GB |
| 98,304 | ~12 GB | ~6 GB |
So a 16 GB machine running a ~16 GB model at 98,304 is already over budget
before the OS. q8_0 halves the cache for well under 0.1 perplexity, but
only with flash attention enabled — without it the cache is dequantized
on every attention step and can end up slower than not quantizing at all.
Model generation matters more than size. A model that answers well in chat can still be unable to drive an agentic loop: some emit a correct tool call as ordinary text instead of as a tool call, so the agent reports success having changed nothing. Setup will not offer those for an execution lane whatever their size — a 5 GB model that fails this is worse than no local lane, because it fails silently.
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.