What you can do with a recorded session.
kcap records every coding-agent session as an immutable stream. Continue it after a crash, hand it to another agent, review the PR it produced, score the run, or ask what it cost — from the dashboard, the CLI, or inside the agent.
Share the session, then work together.
Multi-player is not another status update. It is a teammate opening the same agent session, the same spec in progress, or the same hosted agent and moving the work forward.
The next person reconstructs the conversation from Slack fragments.
Alex pasted a wall of context. Nina has to reverse-engineer the spec from the thread. The session itself is not shareable.
I started the webhook replay spec but I want another read before the agent writes code. Here’s a dump of the last 20 turns…
Which version of the spec is current? I’ll start from the last message in this chat.
Without a session link, handoff is a paste.
Send the session, not a wall of context.
Nina opens the session Alex shared and picks up the work where it stands. A link replaces the paste.
I added the missing acceptance case to the spec. Can you continue from that version?
I see the spec update: duplicate delivery after a timeout must replay safely. I’ll update the test matrix first.
With the session, the second person joins the work, not the thread.
Session links, shared hosted agents, and recaps all point at the same durable session stream. Visibility decides who can open it. See Hosted agents and Session recall.
Switch coding agents without starting over.
One coding agent gets stuck. The next one reads the recap, sees what was tried, and continues from there — not from turn one.
The next agent starts at turn one again.
codex › ran out of room in the context windowcodex › /new
You switch to Claude Code. It has none of the prior reasoning.
Here’s the failing test again. Please try another fix for the race in flush().
I’ll start by checking whether the lock-free swap is losing writes under contention.
Without the session, switching tools means repeating old work.
The handoff keeps the failed hypotheses failed.
Claude Code reads the Codex recap. The four hypotheses Codex already ruled out stay ruled out.
Continue from the Codex session. Keep the same failing test open.
Codex ruled out the lock-free swap, the channel rewrite, the timer reset, and the retry loop. I’ll try the staged-commit approach next.
With the session, changing agents does not erase the investigation.
Every session is tagged with its vendor and serialized to the same event stream. The next agent starts a new session, pulls the prior recap through the same MCP tool, and continues from there — regardless of who wrote the original. A hosted agent can also be forked from any turn: the fork starts from that turn's code and context, on the harness you pick, with the change you want made. See Recap and Session recall.
Review PRs with the reasoning, not just the diff.
Your agent already reads the code. Now it can read what your teammate tried before they wrote it.
Another PR you don’t have time to understand.
− batchSize: 500+ batchSize: 5You ask your agent why Sam changed batchSize to 5. It only has the code.
Why did Sam drop the batch size to 5?
Every other job in this repo uses 500. At 5, throughput drops by two orders of magnitude. Looks like a debug value. Restore it.
Without the session, the agent confidently guesses wrong.
The reason was in Sam’s session all along.
Your agent pulls the session behind the PR and reads the load tests that led to the change.
Why did Sam drop the batch size to 5?
Sam load-tested 500 — the database locked up at p99. They tried 200 next, but the writer OOM’d. At 5, the job stayed stable for 30 minutes. Trading throughput for stability until the writer is sharded.
With the session, the agent stops guessing.
kcap review <pr-url> launches your agent with the kcap mcp review tools, which hand it the PR’s linked sessions at review time: file context, prior test runs, and the FTS-indexed transcript. See PR review.
Stop teaching agents the same repo rules twice.
kcap scores sessions against your rubric and turns durable lessons into repo guidance loaded before the next agent starts.
The same mistake comes back next week.
+ jest.mock("./db", () => ({ ... })) // session 87+ jest.mock("./db", () => ({ ... })) // session 134Your team never mocks the database in this repo. Every new session has to relearn that rule.
Please don’t mock the database in this repo. Use the integration test harness.
I’ll mock the db module so the checkout tests run faster.
Without evals, lessons stay trapped in individual sessions.
The useful lesson becomes repo guidance.
The rule moves from a reviewer comment into the repo’s agent guidance. The next agent reads it before writing code.
Score the session and promote the db-mocking finding.
This repo’s guidance says not to mock ./db in checkout tests. I’ll use the integration harness instead.
With evals, the floor rises without asking every reviewer to repeat themselves.
Evaluations run per session, score against your questions, and emit judge facts. Repeated high-signal facts can be promoted into curatable guidelines that ship at SessionStart. See Evaluations.
Launch a coding agent from any browser.
A daemon on your machine spawns your coding agent in an isolated worktree. You start the work from the dashboard — phone, laptop, anywhere — and a teammate can join the same prompt.
Starting work means opening a terminal on the right machine.
No SSH, no waking the laptop, no “are you on the billing-service checkout?”. Without a daemon, the agent lives where you happen to be sitting.
Can you pick this up? I’m on my phone. The repo is on my desk machine.
I can only run where this shell is. You’ll need to open a terminal on that laptop.
Without a hosted agent, remoting is a meeting or a hop.
Start an agent without opening a terminal.
Run kcap daemon start -d once. The dashboard sees every running daemon and lists only the vendors it can actually spawn. A teammate can join the same session.
Open checkout-api on my laptop daemon, hand the agent the spec, and start.
Checked out spec/webhook-replay in a new worktree. I’ll read the spec and propose the first acceptance case before touching code.
With a hosted agent, the work is on the dashboard, not on whoever has the laptop open.
kcap daemon start on your machine. The daemon advertises itself to your kcap server; the dashboard’s launch dialog picks a vendor, repo, and branch, and the daemon spawns the agent in an isolated worktree. See Hosted agents.
Ask your agent: have we worked on this before?
kcap gives the agent six MCP tools — search past sessions, list a repo’s sessions, summarise one, read its transcript, walk it turn by turn, drill into the exact turn — so prior decisions show up in this conversation instead of getting re-litigated.
The agent only knows this chat.
You ask a question that touches a decision your team already made. The agent has no idea it has been argued.
Should we put a queue in front of the rate-limiter, or call it directly?
A queue would give you backpressure and retry semantics — usually the safer default. I’ll sketch a Redis-backed queue.
Without recall, every new session re-opens decisions your team has already closed.
The prior decision shows up in this chat.
The agent searches every session you can see, defaults to the current repo, and chains search → summarise → drill in until it has the actual turn.
Should we put a queue in front of the rate-limiter, or call it directly?
Priya already ran this. The 24h shadow at direct call stayed within p99 budget, so the team chose direct over a queue. Revisit if shed rate climbs above 1%.
With recall, the agent cites the prior call instead of starting the argument over.
The kcap mcp sessions server gives the agent six chained tools: search_sessions, list_repo_sessions, get_session_summary, get_session_transcript, list_turns and get_turn. It’s repo-aware by default and respects the same visibility rules as the dashboard. See Session recall.
Don’t let one agent grade its own homework.
The agent that wrote the code has the same blind spots when it reviews the code. A review flow hands your spec or diff to a separate reviewer — and loops until the findings are gone.
It reviews its own work and calls it clean.
You ask the agent that just wrote the handler to check its own work. One agent can’t catch the blind spot it just wrote in.
Review your change before I open the PR.
Clean handler — it follows the existing route style and reads well. No issues. Good to merge.
Without a second agent, the merge looks reviewed and isn’t.
The reviewer catches it. Your agent fixes it.
Your agent hands the diff to a hosted reviewer — a vendor you choose — and waits for the verdict. Round two comes back clean.
Get an independent review before I open the PR.
The reviewer flagged the missing authorization check. I added an org-admin guard and re-submitted. Second round came back clean.
With a review flow, work gets checked, fixed, and re-checked before it’s done.
The kcap mcp flows server hands your spec or diff to a hosted reviewer you choose, independent of the agent driving the flow. It returns findings, your agent addresses them, and it re-reviews until it signs off — the whole loop event-sourced on your server. See Hosted agents and PR review.
What did your agents cost last month?
Token spend scatters across providers, repos, and developers. Ask in plain English — the analytics agent answers with a number you can audit, not a guess.
The spend is scattered across provider bills.
anthropic console $?openai console $?by repo / by dev —You ask which repo burned the budget. The bills don’t say.
Which repo cost the most in tokens last month?
I can’t tell from here — provider billing isn’t broken down by repo or developer. You’d have to export each console and reconcile it by hand.
Provider bills total the spend. They don’t tell you where it went.
Ask in plain English. Audit the number.
You ask the analytics agent, and it queries your session read model. Each row keeps the query behind it, so the number is auditable.
What did each repo cost in tokens last month?
Last month checkout led at ~$58 (4.2M tokens), then web at ~$16 and infra at ~$5. Each row keeps the query_read_model call behind it.
With analytics, the spend has a name, a repo, and a receipt.
The analytics agent turns your plain-English question into a query_read_model call over the projections kcap builds from every session — counts, tokens, timings — and answers with a table or chart plus the exact query behind it. It reads aggregates only, never your transcripts. See Analytics.
Start with a session you already have.
Create a workspace in the browser. Import your history when you install the CLI — searchable in minutes, not an empty tool.
Fix flaky auth-token refresh test
Tried mocking the clock first — abandoned after the race persisted. Root cause: token cache TTL rounding. Patched in auth/cache.ts, added regression test. Two approaches rejected, one shipped.