Kin / Overview

Kin

Kin is a terminal-based AI peer for working in a real project. It reads and changes files, runs tools, coordinates agents, and runs headlessly under host schedulers.

Read as Markdown

Kin is a terminal-based AI peer for working in a real project. It reads and changes files, runs tools, searches the workspace, coordinates agents, and keeps durable local sessions. For unattended or recurring work, cron, systemd, launchd, CI, or another host scheduler can start a fresh local kin -p run.

“Peer” describes an engineering philosophy, not a claim about sentience. Design for understanding and collaboration, calibrate before blaming the model, and verify every important claim.

Start here

  1. Install Kin.
  2. Connect a model and launch. The in-app /providers flow is the recommended route.
  3. Send your first message.

Kin welcome screen showing the compact emblem, active model, workspace, trust posture, and message composer.

The welcome screen is the final connection check: confirm the model and workspace, then send a message.

Work with Kin

Start with a concrete outcome: “explain this failure,” “change the parser and test it,” or “find every caller of this function.” Kin streams its answer, keeps reasoning collapsed, and renders tool calls as a compact work log.

Kin timeline showing completed reasoning, expanded shell and edit details, a one-context-line edit diff, and settled interruption states.

Continue with First session, then keep Files & tools, modes and approvals, and keybindings nearby.

Choose the right kind of delegation

  • Use a local subagent for parallel investigation or a bounded independent task while Kin is running.
  • Use a skill for a reusable set of instructions.
  • Use a host scheduler when recurring work should start a fresh local kin -p process.

All three remain inside the same tool, permission, repository, and verification boundaries. Delegation never manufactures authority.

Find the right depth

  • Use Kin covers files, search, modes, sessions, commands, web tools, research, and MCP.
  • Agents & automation covers skills, subagents, and scheduled headless runs.
  • How Kin works explains architecture, permissions, agents, tasks, and visual identity.
  • Reference is the provider, workspace-trust, CLI, environment, settings, and event surface.
  • Maintainers contains testing, decisions, and extension guidance.

If something looks wrong, first confirm the model and workspace in the welcome screen. Provider failures belong in Connect a model and first run; permission prompts belong in Modes & approvals; scheduled-run issues belong in Scheduled jobs.