SDK overview
Drive a crouter daemon from a Node or browser application with the typed SDK.
@north-light/crouter-sdk
The ESM-only client an application installs to drive a crouter daemon: create agent runs, watch streamed events, wait for typed results, read and write memory, and reach the rest of the daemon's /v1 API.
One package, one class. new Crouter() in Node talks to the owner's unix socket. new Crouter({ baseURL, token }) in a browser or a remote process talks to the daemon's TCP listener with a bearer token. Resource methods issue /v1 requests; createAndWait, parse, and auth.status compose more than one request. crtrd stays the sole owner of canvas state.
import Crouter from '@north-light/crouter-sdk';
import { z } from 'zod';
const client = new Crouter();
const run = await client.nodes.parse({
prompt: 'Summarize the failing tests in this repo.',
cwd: '/path/to/repo',
output_schema: z.object({ failures: z.array(z.string()), root_cause: z.string() }),
});
if (run.kind === 'result') console.log(run.output_parsed.root_cause);
Pages
| Page | Covers |
|---|---|
| Getting started | Install, new Crouter() on the owner's socket, client.auth.status() and crtr sys connect for a browser or remote app, Chrome's local-network prompt |
| Client construction | Every constructor option and its environment-variable fallback; per-request options |
| Nodes | create parameters, the outcome union, parse() with a zod schema, waitForOutcome, message, cancel, nested resources |
| Streaming | The event table, stream() / events(), the activity helper, resume with after, stream_gap and stream_dropped |
| Memory | The scope object and every client.memory method |
| Files | Absolute-path reads, writes, and one-level lists |
| Bash | One bounded command and its output result |
| Resource map | Every namespace with its phase, what is deliberately excluded, and the client.request() escape hatch |
| Errors | The error class table and the retry policy |
| Docker environment | start(), attach(), connection() from @north-light/crouter-env-docker |
| Migration | Moving off generate() and local() — a hard cut, with before/after |
Phases
The surface ships in three cuts. Phase 3 memory methods are shipped.
| Phase | What lands | State |
|---|---|---|
| Phase 1 | Client construction and transports; client.auth.status(); client.nodes.create, retrieve, list, outcome, waitForOutcome, createAndWait, parse, message, cancel, and interrupt; nodes.reports.list; profiles.ensure and retrieve; system.status and health; the error hierarchy; per-request options; crtr sys connect; and env-docker.connection() | Shipped |
| Phase 2 namespaces | Node lifecycle, job, worktree, and result; canvas and canvas history; crons; human requests and inbox; models; client.files.read through /v1/files/peek, write, and list; and client.bash.run | Shipped |
| Phase 2 streaming | GET /v1/nodes/{id}/events, nodes.stream(params, options?), nodes.events(id, options?), NodeStream, and the activity helper | Shipped |
| Phase 3 | Memory routes and client.memory, plus the review, comment, and chat-inventory namespaces | Memory shipped; remaining namespaces not shipped |
The per-run scopes create field ships in phase 1. nodes.update scope support remains phase 2 and is not in the shipped client or wire declarations.
Verification status
The SDK declarations, streaming examples, and memory examples are verified.
Where the agents read this
The same content routed for agents lives in the builtin memory document crouter-sdk, which ships with the crtr binary. An agent working in an application's repository reaches it with crtr memory read crouter-sdk and does not need this repository checked out.
Why a daemon
When deciding how an application should host or reconnect to an agent, read this because the daemon keeps the durable canvas and broker lifecycle in one place while terminals and SDK clients come and go.
Getting started
Connect to a local or remote daemon and run your first agent with the SDK.