Rind

A lightweight local coding agent — automate it, delegate to it, extend it, reach it from anywhere.

Website · English | 简体中文

Rind is a lightweight, open-source AI coding agent with persistent specialist workspaces, scriptable sessions, and a shared runtime for terminal, desktop, browser, and messaging clients. It runs on your machine and connects to your chosen model provider.

See Rind in action on the website: watch the CLI, built-in guide, specialist teams, and one-shot runs before installing.

• Build a reusable team. Give specialists a lasting role, a working directory, and files they can build on across tasks.
• Put sessions into your workflow. Run an agent from a script or send new instructions into a live terminal session.
• Build on a lean worker. Separate the interface from execution, load sessions on demand, and extend the engine through clear interfaces.

Choose one of three ways to install the CLI:

Download the installer for Windows x64, macOS Intel / Apple Silicon, or Linux x64 from Releases. After installation, open a terminal in your project and run rind.

Requires Node.js 18+:

npm install -g @rind-ai/cli
cd your-project
rind

Requires Python 3.12+, Node.js 18+, and Git:

git clone https://github.com/Azzurroooo/rind.git
cd rind
python -m venv .venv

Activate the environment with source .venv/bin/activate on macOS/Linux or .\.venv\Scripts\Activate.ps1 in Windows PowerShell, then:

python -m pip install -r requirements-runtime.txt
node frontend-cli/bin/rind.js

For the examples below, source users can substitute node /absolute/path/to/rind/frontend-cli/bin/rind.js for rind.

Inside Rind, run /login to connect a provider, then /model to choose a model. Built-in adapters cover OpenAI, Anthropic, Google, DeepSeek, and more; custom OpenAI-compatible endpoints are configurable too. See the setup guide for configuration and other clients.

Explore before spending tokens. The interactive tour demonstrates real CLI layouts with simulated tasks: pause, rewind, and jump straight to a feature. It makes no model calls and needs no API key.

rind tour team.create

The tour is available on main, after v0.8.0; use the source setup to try it today. Run rind tour for the catalog, or /tour inside a session.

Give recurring work to a specialist with a place to keep it. A test specialist can maintain fixtures and testing notes; a researcher can preserve findings and source material. Their workspaces remain available for the next assignment.

A Team lives in ordinary directories. The main agent coordinates specialists, and shared/ holds the files they exchange:

my-project/
├── .aiteam/project.yaml         # Team identity and main-agent selection
├── agents/
│   ├── main-agent/              # Coordinator workspace
│   └── test-specialist/
│       ├── .aiteam/agent.yaml   # Specialist identity
│       ├── .aiteam/prompts/     # Role instructions
│       ├── memory/             # Notes worth keeping
│       ├── work/               # Working files
│       └── outputs/            # Local deliverables
└── shared/                     # Inputs and published handoffs

Each execution creates a separate, persisted session. Continuity comes from the specialist's role and files: new tasks can inspect previous work, while old conversations remain separate records. The main agent gets a concise result and paths to published artifacts it can verify.

Independent assignments can run concurrently. A specialist works within its own workspace and the shared area through the file tools, keeping private working material separate from published handoffs.

In a Rind session at your project root:

/team create
/exit

Creation leaves the current session in place. Start a new one in the coordinator's workspace:

cd agents/main-agent
rind

Then, inside Rind:

/team add A test specialist that writes regression tests and maintains testing notes
/team list

Put the material to work on in the project's shared/ directory, then ask the main agent:

Delegate to the test specialist: inspect shared/parser/, write Unicode regression tests, and publish the tests and a short handoff under shared/.

Use the agent ID shown by /team list when naming a specialist. Ctrl+B opens the delegate monitor. For future projects, /team blueprint creates specialists from templates you install under ~/.rind/blueprints/.

Let a script start the work—or contribute to work already in progress. Rind exposes both paths:

# Produce an answer that another program can consume.
rind run --prompt "Review the current diff for breaking API changes" > review.md

# Send an update from another terminal to an open Rind CLI session.
rind send --session <id> "The integration tests failed; investigate before continuing."

run writes the final answer to stdout, progress to stderr, and a Markdown run summary to logs/ in the launching directory. User questions are disabled; failures return a nonzero exit code. Add --session <id> to continue a saved session or --dir <absolute-path> to choose the workspace.

With a current Worker, run waits for its managed background tasks and necessary follow-up turns, including tasks started during those turns, then prints one final answer. Long commands automatically release their initial waiting window and report completion without polling. Services started with notify="manual" do not hold the request open and stop when the Worker exits. Older Workers report that automatic background continuation is unavailable.

send addresses a running CLI session on the same machine: it starts a turn when idle and steers the current turn when busy. Find the session ID in the startup banner or /status. Delivery is acknowledged immediately; the answer appears in the target session. This lets a test watcher or local script contribute findings without taking over your terminal.

The interface handles interaction. The worker runs the agent. In the CLI, these are two separate processes: a Node.js surface and a Python worker, connected by JSONL requests and streamed events. The desktop app also launches the worker separately from its UI; Web and gateway clients connect to a long-lived worker over WebSocket.

This boundary keeps rendering and input handling out of the execution loop. A new client implements the protocol and reuses the engine's model calls, tools, delegation, and cancellation.

The worker is stateless with respect to durable session history. Disk is the source of truth; active execution and coordination live in memory:

• Load on demand. A turn loads its session and creates the model client and execution objects it needs.
• Release when idle. Once a session has no active or queued work, its execution container is released and its model client is closed. Saved sessions do not each require a resident agent.
• Keep the work on disk. Messages and tool-call history persist as JSONL; subsequent turns reopen the saved session. Shared runtime services are reused across executions.

The result is a small idle execution footprint and clear extension boundaries: add clients, tools, or providers without coupling them to the UI. Running tasks still retain transient state for queues, cancellation, and live updates.

Choose where you work; reuse the agent underneath. The clients share the session protocol and runtime implementation:

With the Web client, closing the browser leaves the worker running; reconnecting restores the session view. Local clients can reopen saved sessions when configured to use the same session store.

Rind separates clients, execution, and infrastructure. A custom interface consumes requests and session/update events; a new capability plugs into the tool registry.

For the design behind these boundaries, see Architecture, CLI rendering, and Tour internals. For commands and shortcuts, use /help and ? inside Rind.

The development guide covers setup and tests.

Keep contributions lightweight and complete, with clear interfaces, one-way dependencies, and no redundant code. Read the contribution guidelines before opening a pull request; issues are welcome too.

MIT