# How Speedwave works

[What is Speedwave](/docs/) covers the shape from the outside: one installable app, two front ends, and a model provider you pick per project. This page goes a level down, into what actually runs when you open a project and how the pieces stay apart.

Three ideas carry the rest: a project is the unit everything is scoped to, workers are the only thing that touches your services, and the gateway sits between Claude and those workers.

## Projects keep work apart

Everything in Speedwave is organized per project, a registered workspace with a name and a host directory. Each project gets its own container network, tokens directory, and Claude home directory, so work in one stays apart from work in another. If one project's worker were compromised, it could not reach another project's network or credentials. See [Isolation](/docs/security/isolation/) for how these boundaries hold up.

## [Workers do the reaching, Claude does not](/docs/under-the-hood/workers/)

Claude runs in a container that holds no tokens and no credentials, and it cannot reach any service directly. When a project connects a service such as GitLab or Slack, that service gets its own worker container, mounting only that one service's credentials, read-only. The model that writes and reasons never sees a real credential, and a problem in one worker cannot spread to another service's access.

That integration traffic passes through the [Tool Gateway](/docs/under-the-hood/tool-gateway/). No matter how many integrations a project enables, Claude sees exactly two tools, `search_tools` and `execute_code`, so its context window does not fill up with tool definitions as you connect more services. The gateway is also where calls are logged and [results are tokenized](/docs/security/tokenization/) before Claude reads them.

## What ships in the box

Every project runs Claude inside a container that already carries a set of Claude Code resources: skills, a default output style, a status line, and baseline settings, plus five official Anthropic plugins installed at container start on top of any [signed Speednet plugin](/docs/plugins/) your project enables. You do not install or configure any of it, and it sits alongside any `.claude/` directory your team commits, with your team's files taking precedence. See [Built-in skills and plugins](/docs/features/built-in-skills-and-plugins/) for the full inventory.

Claude Code itself runs pinned to a fixed version with a fixed set of CLI flags, so a session behaves the same way on every machine:

| What | Value |
|---|---|
| Version | `2.1.206`, never `latest` |
| Binary | `/usr/local/bin/claude` |
| CLI flags | `--dangerously-skip-permissions`, `--mcp-config`, `--strict-mcp-config` (ignores workspace `.mcp.json`), `--thinking-display summarized`, `--ide` |
| Baseline env | telemetry and auto-update off, sandbox mode on, no terminal flicker, clipboard shim, 30 minute MCP tool idle timeout |

Speedwave never sets `ANTHROPIC_MODEL` itself, only your own `claude.env` does. See [Binary authenticity](/docs/security/binary-authenticity/) for how the pinned version is verified.
**Why bundling the runtime matters:** Because the container runtime ships inside the app, a team member gets a working, isolated setup by installing one thing, not by assembling a runtime, a CLI, and a set of Claude Code resources by hand.