Review in the live session, not the diff.

Stop reviewing a static patch that has already moved on. Join the running session, inspect the app in the integrated browser, annotate the element you mean, send the note to the agent, and watch the fix land.

Start free

Why review in the session

The diff is a snapshotAsync comments land on a static patch that has already moved on. By the time the author reads them, the running app looks different.

The session is aliveIn Coshell the review happens where the work happens: one live session, one running filesystem and terminal, with the agent in the loop.

Fixes land in front of youYou annotate, the agent works, and you watch the change land in the same live session, then it pushes to your real git.

Review used to be async comments on a diff that had already moved on.

Now you review the running app, live, and watch the fix land.

AReview: rate limiter branch

Open

Review: rate limiter branch

feat/rate-limit TRLF

Review the rate limiter branch against main before we merge. Be picky.Priya Nair

Shellgit diff --stat main...feat/rate-limit

ReadrateLimit.ts

ReadrateLimit.test.ts

Three findings. The Redis key embeds the raw API key, so hash it. There is no test for the 429 path. And Retry-After is sent in seconds while the docs say milliseconds. Details are in the Deep Review tab.

Fix the first two. Leave the header, the docs are wrong, not the code.Tom Reyes

EditrateLimit.ts /src/middleware/+6−2

EditrateLimit.test.ts /src/middleware/+18−0

Shellbun test

Key is hashed with SHA-256 before it hits Redis. Added two tests for the 429 path. 16 passing.

Approving. I’ll fix the docs in a follow-up.Lena Fischer

Marked the review resolved. Two findings fixed, one dismissed with Tom’s reason attached to the PR.

Claude Sonnet 5

ChatPlanDeep ReviewReview

Morning. Plan is approved, I’m starting the orders dashboard on acme-web.8:52

Tom Reyes8:55I’ll take the limiter then. Which drive?

office-mac-mini has Redis running, use that one.8:55

Lena Fischer9:10Back online. Anything blocked?

Tom Reyes9:11Nope. OrdersDashboard.jsx is Priya’s, limiter is mine, webhooks are free if you want them

Lena Fischer9:12Taking webhooks.

Lena the Refunded pill should be amber, not red. I queued a prompt for it9:30

Tom Reyes9:41Picking up rateLimit.ts for the webhooks route

Lena Fischer9:42Tom I already touched the 429 path there, check the overlap note before you push

Step 4 in the plan is mine, I’ll ping when the tests are green

Sounds good. I’ll review after, then we roll the flag.9:44

Rate limiter rolloutDetailsWorking

Spec approvedPlan approvedExecuting 3/5

Goal

Protect /v2 from bursty API keys without slowing normal traffic. One key should never be able to starve the others.

Approach

A token bucket per API key, 100 requests per minute, stored in Redis so all three replicas share state. Over-limit requests get a 429 with a Retry-After header. Ship behind the rate_limit_v2 flag and roll out gradually.

Constraints

No new dependencies beyond ioredis, which we already run.
p99 latency budget: +2 ms on the hot path.
Existing tests stay green at every step.

Verification

bun test after every step. Load test with 1k keys before the flag moves to 50%. Watch 429 rate and p99 in the dashboard for a day at 10%.

Steps

Token bucket middleware with testsVerified

Add

Redis-backed bucket, atomic across replicasVerified

Add

Retry-After header on 429 responsesVerified

Add

Apply the limiter to /v2/webhooksLena, in progress

Add

Roll out behind the rate_limit_v2 flagWaiting

Add

on step 5, Roll out behind the flag

Priya Nair2m

Roll out to 10% of keys first, then 50%. Add both as substeps.

Lena Fischernow

Agreed, updating the step before the agent gets there.

Deep Review

feat/rate-limit against main

Run again

HighRaw API key stored in the Redis bucket keyrateLimit.ts:22

The bucket key is bucket:{apiKey}. A Redis dump would leak every customer key. Hash it before use.

Send fix to agentDismiss

MediumNo test covers the 429 responserateLimit.test.ts

Every test stays under the limit. Add one that exhausts the bucket and asserts the status and Retry-After header.

Send fix to agentDismiss

LowRetry-After unit disagrees with the docsrateLimit.ts:41

The header is sent in seconds, which is correct per RFC 9110. The API docs say milliseconds. Fix the docs.

Send fix to agentDismiss

Port 5173Port...ShareInspect

acme

DashboardOrdersCustomersSettings

Orders

Last 7 days · updated just now

Revenue today$18,420+12% vs last week

Orders342+8%

Average order$53.86−3%

Revenue, last 7 days7 days30 days

MonTueWedThuFriSatSun

#10428Maya OseiPaid$128.40

#10427Theo LindqvistRefunded$64.00

#10426Ada MensahPaid$212.75

#10425Ravi ShankarPending$39.90

3 Changed files+112 −3

src/pages/OrdersDashboard.jsx+77−0

38 <div className="toolbar">

39+ <button className="btn">Filter</button>

40+ <button className="btn primary" style={{ background: '#5B4CF0' }}>

41+ Export

42 </div>

src/index.css+33−0

112+ .stat { border: 1px solid #e6e6e6; border-radius: 10px; }

113+ .stat .delta.up { color: var(--ok); }

114+ .status.refunded { background: var(--danger-bg); }

src/App.jsx+2−3

3- import { useMemo, useState } from 'react'

3+ import { useState } from 'react'

18- <Summary />

18+ <Summary />

19+ <OrdersDashboard />

What a live review looks like in Coshell.

Every line below is a shipped part of the session your team reviews in: the running app, the annotations you send to the agent, presence and follow, per-session privacy, and a push to your real git.

Review the running app, not just the patch

The integrated localhost browser shows the app running inside the session, shared with everyone on the drive and auto-reloading as the agent works. You review behavior, not only the diff.

Inspect an element, comment, send to the agent

Inspect an element in the preview, leave a comment on it, and send the note straight to the agent in the session. Your feedback becomes work the agent picks up, in front of the whole room.

Presence, follow, and chat in the thread

See who is in the session, follow a teammate's view to look at exactly what they are looking at, and talk it through in the in-session chat overlay. The review is a place you all stand in, not an inbox.

Per-session privacy for review threads

Keep a review session private to you, share it with named teammates, or open it to the whole drive. Per-session access control means a sensitive review stays with the people you name.

Pushes to your real git, so your PR flow stays

Coshell pushes to your real git. Reviewing live in the session does not replace your pull-request flow, it feeds it: the agent lands the fix and pushes the branch you already review against.

It feeds your pull-request flow, it does not fight it.

A drive stays warm in the cloud with your files, terminal, and dependencies ready, and you open it from any browser or attach from the CLI. The repo is already read into the drive and kept warm, so a reviewer drops into a session that knows the code instead of waiting for context to load. The review happens live, then Coshell pushes to your real git, so the branch still arrives the way your reviewers expect.

See the product Why multiplayer Pricing Enterprise and on-prem

Live code review, answered

How is live review different from leaving comments on a pull request?

A pull request comment lands on a static diff that has already moved on. In Coshell the reviewer joins the live session instead, sees the app running in the integrated localhost browser, inspects an element, comments on it, and sends that note to the agent in the session. The fix lands in front of everyone and is pushed to your real git, so it still arrives as a normal branch your pull-request flow reviews.

Can two reviewers be in the same session without clobbering each other?

Yes. Several people prompt one agent at once on one running filesystem and terminal, not parallel copies. When two reviewers' edits reach for the same lines, the overlap layer catches it and steers the second before it overwrites the first. Presence and follow show who is in the session and let you watch a teammate's view, and the in-session chat overlay keeps the conversation in one place.

Does reviewing in the session replace pull requests?

No. Coshell pushes to your real git, so a live review feeds your existing pull-request flow rather than replacing it. You review the running app in the session, the agent lands the fix, and it pushes the branch you already review against. Keep a review session private to you, share it with named teammates, or open it to the whole drive.

Bring the review into the live session.

Start free

Open a drive in the browser, or attach from the CLI. Inspect the running app, annotate the element, send it to the agent, and watch the fix land, then push it to your real git.