E/01·How it's built

A real dev environment,
in your cluster, in two seconds.

Threaded ships as a Helm chart you install on your own Kubernetes — EKS, GKE, AKS, OpenShift, or self-managed. Each thread runs in an isolated pod inside that cluster, with your repo cloned, dependencies cached, and a long-lived terminal session. Builds, tests, and previews execute against the same workspace the agent is editing. No simulation, no shared multi-tenant plane.

01/The runtime

Production-grade isolation per thread.

Every thread is a pod. Every pod is a sandbox. The agent's filesystem, the test runner, the dev server, and the preview all live inside it. Workspaces hibernate when idle and wake on the next message.

Compute

Your Kubernetes

One pod per thread, scheduled on your cluster. Region, node pool, and sizing are your call. 2 vCPU / 4 GB is a sensible default; configurable per repo.

Storage

Your persistent volumes

Dependencies cached on a per-repo PV in your cluster's storage class. Cold starts only fetch the diff. Average warm boot: 1.2 seconds.

Network

Stable preview URLs

Each thread gets a named subdomain on your ingress — internal-only, VPN-gated, or public, your call. TLS via your cert manager.

Source

GitHub bidirectional

Threads commit via your GitHub App installation. Branches named for the thread ID. The PR opens, updates, and merges from inside the thread.

Agent

Bring your own model

Anthropic Claude, OpenAI, or any provider behind an AI Gateway via OpenCode. Your API key, your terms, your training opt-out. Threaded routes; we don't see the prompt.

Realtime

CRDT sync

The doc, the whiteboard, and the chat are CRDTs. Edits merge offline. Presence shows who is reading and writing.

Cold start

1.2s

Median time from thread open to ready terminal, p50, on a warm 4 vCPU node pool.

Agent context

200k

Token window the agent reads on every run. Thread, repo summary, and run history fit inside.

Cluster footprint

3 nodes

Minimum to run Threaded in production. Scales horizontally; no Threaded-operated services in the path.

02/The agent loop

Read the thread. Run. Post the diff.

The agent is not a one-shot prompt. It reads the brief, the chat history, the doc, and the most recent diffs every time it's called. It plans, executes, runs your tests, and posts results back into the thread.

Comments left on a preview URL or a diff line become inputs on the next run. The agent doesn't need to be re-briefed. It picks up where the team left it.

Each run produces an artifact: run_id, files touched, tests passed, time elapsed. Replayable. Auditable. Permanent.

# inside the thread workspace, on a pod in your cluster $ bun install # 1.2s, cached $ bun dev --host → https://thread-abc123.preview.acme.internal $ bun test pricing ✓ 14 pass · 0.4s # agent posts run_8f3a back to the thread $ threaded post-run --run run_8f3a \ --files "pricing.tsx,Button.tsx"

03/Integrations

It plugs into what you ship with already.

/git

GitHub

One PR per thread. Branches named for the thread ID. Required checks gate the merge.

/ci

Your CI

Threaded runs your existing pipeline against the workspace. Failures show up inline in the thread.

/secrets

Vault, 1Password, Doppler

Secrets are mounted into the pod, never read by the agent. Rotated per session.

/figma

Figma

Frame links resolve inside chat. Drop a frame on the whiteboard and the agent reads its layers.

/linear

Linear, Jira

Threads link bidirectionally to issues. Status updates flow both ways.

/slack

Slack

Post a thread to a channel. Replies in Slack post back into the thread, attributed.

A real dev environment,in your cluster, in two seconds.