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 MarkdownKin 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
- Install Kin.
- Connect a model and launch. The in-app
/providersflow is the recommended route. - Send your first message.
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.
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 -pprocess.
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.