Build with darting.dev

What darting.dev is, the gap it fills, and where to start.

Create a project from a repo or from scratch — then watch the sandbox configure itself and prove it runs.

The end-to-end loop, from creating a project to merging a pull request.

Where everything lives — the Project Map, the chat, the right panel, Collections, and the Inbox.

How threads map to git branches, and how parallel work stays organized.

Living plans — how complex work becomes a versioned plan document you review, revise, and Build.

One thread ships one pull request — forks and detached agents are how work continues after that.

Every message is a checkpoint — stop mid-run, continue later, or rewind the thread to an earlier state.

How a long-running thread stays under the model's context limit without you pruning the conversation.

Pick a model per thread, let Auto route per task, and control what your sub-agents run on.

One lead agent per thread — it assesses complexity, plans when needed, and builds with the full toolset.

How the lead agent delegates to specialized sub-agents that share its sandbox — and why that keeps it fast.

Every role the lead can spawn — what it does, what it may touch, and what they all share.

How the lead fans work out safely — frozen interfaces, ownership boundaries, and review of every returned diff.

See exactly what an agent knows this turn — every fragment, rule, skill, and the live token count.

Why every thread runs in its own cloud environment, and what that buys you.

How darting.dev remembers the way your app installs and runs, and why new threads boot in seconds.

Project secrets, per-sandbox overrides, and how environment variables reach a running sandbox.

The live surfaces of a sandbox — a streamed desktop, a terminal you can type into, and dev-server logs.

How darting.dev captures project knowledge and keeps every agent's context from overflowing.

The living map of your product — how documents cluster into areas and stay organized without a librarian.

Every durable document — knowledge, plans, and your own collections — versioned, browsable, and attributable.

One queue of everything waiting on you — proposed documents, merge suggestions, and flagged contradictions.

Standing agents that wake on a schedule or an event, maintain living documents, and route decisions to you.

The standing automations every project ships with — the Organizer, Knowledge sync, and Skills.

Wire a role to a trigger and a collection, set a budget, and you have a standing loop.

The shared event stream automations subscribe to — git activity, system events, tool events, and inbound hooks.

Implementation work comes with a recording of the feature actually working in a real browser.

Reviewing agent work and integrating it with Commit Thread.

What happens after you open a PR — CI tracking, capped fix-only turns, and auto-merge on green.

How many open PRs land without conflicts — file-overlap grouping and oldest-first ordering.

Staying current while main moves — the behind-count, one-click update, and conflict resolution in-thread.

Accounts, teams, private threads, shared projects, and per-user usage limits.

What darting.dev meters, where you watch it accrue, and what happens when you reach a cap.

Owners, managers, and members — who administers a team, and what stays yours alone.

Teach the swarm your conventions with project rules, and reusable techniques with Agent Skills.

Drive the swarm from outside the browser — a REST + SSE API, GitHub webhooks, inbound hooks, and hosted previews.

The /api/v1 surface — create threads, send turns, read state, and stream events over SSE.

Sign-in, the GitHub App, per-user git credentials, and how reconnection works when access breaks.