Use case

Onboard in a live session, not a setup doc.

Drop a new engineer into a warm drive that already has the repo, the dependencies, and a running environment, and let them *follow a teammate* through the codebase in a live session. Day one is building, not configuring.

Day one, without setup

Nothing to installThe drive is already warm, with the files, the terminal, and the dependencies ready. A new hire opens it in the browser and the environment is running.
Someone to followInstead of reading a stale setup doc alone, a new engineer joins a live session and follows a teammate's view through the codebase.
An agent that knows the repoThe drive already holds the repo warm from the team's work, so the agent in the session can answer a new hire's questions about the code without loading it from cold.

Day one used to be a setup doc, a dozen installs, and a broken local build.

Now it is a warm drive and a teammate to follow in a live session.

BWhere does billing live?
Open
Who can access
Openeveryone on the drive
SharedTom, Lena
Privatejust me
Where does billing live?
main TR
First day. Where does billing live in this repo, and how do I run its tests?Lena Fischer
Explored14 reads

Billing is packages/billing. Stripe webhooks land in webhooks.ts, subscriptions in lifecycle.ts, and every money value is integer cents by convention. Tests run with bun test from the package directory.

Also read .coshell/review/dod.md for her, that’s our definition of done.Tom Reyes
Readdod.md

Definition of done, in short: integer cents, every promise handled, focused tests for the change, no dead exports. I’ll hold your changes to that.

Set me up to run the billing tests here.Lena Fischer
Shellcd packages/billing && bun install
Shellbun test

42 tests pass. Redis and the seed data were already on this drive, so nothing else to install. You can start.

Claude Sonnet 5
Model
Claude Sonnet 5
Claude Opus 5
GPT-5.5
Gemini 3.5 Pro
Muse Spark 1.3 Free
Big Pickle
ChatPlanDeep ReviewReview
TR
Tom Reyes9:05Welcome Lena. This drive has everything: Redis, seed data, the Stripe test keys.
Start with dod.md and then ask the agent anything, I’m following your session for the first hour
LF
Lena Fischer9:06Thanks. Following the agent instead of a setup doc is new.
Lena first ticket is queued on the plan tab, small one9:20
Mention
CScoshellassistant
TRTom Reyeson the drive
LFLena Fischeron the drive
CheckoutForm.tsxfile
priceOrder.tsfile
rateLimit.tsfile
webhooks.tsfile
dod.mdfile
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
PN
Priya Nair2m
Roll out to 10% of keys first, then 50%. Add both as substeps.
LF
Lena Fischernow
Agreed, updating the step before the agent gets there.
Deep Review
feat/rate-limit against main
Run review
No review yet. Run one when the branch is ready.
HighExport button colour is hardcodedOrdersDashboard.jsx:41
The Export button sets #5B4CF0 inline while every other control reads var(--brand). Tom’s follow-up prompt fixes it; verify once that edit lands.
Send fix to agentDismiss
MediumNothing tests the stat cardsOrdersDashboard.jsx
No test asserts that the three stat cards render or that a delta shows its direction. A render test with the card labels would catch a regression.
Send fix to agentDismiss
LowUnused importApp.jsx:3
useMemo is imported and never used.
Send fix to agentDismiss
Port 5173
Dev servers on this drive
Port 5173vite
Port 3000next
Port 8080api
Port...ShareInspect
acme
DashboardOrdersCustomersSettings
Orders
Last 7 days · updated just now
FilterExport
Revenue today$18,420+12% vs last week
Orders342+8%
Average order$53.86−3%
Revenue, last 7 days7 days30 days
MonTueWedThuFriSatSun
OrderCustomerStatusTotal
#10428Maya Osei$128.40
#10427Theo LindqvistRefunded$64.00
#10426Ada Mensah$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 new engineer gets on day one.

No machine to configure and no stale doc to decode. A warm drive, a live session to join, and an agent that already knows the repo. Every line below is running in production today.

A drive that is ready, not a laptop to configure

A cloud drive stays warm with the repo cloned, dependencies installed, and the environment running. A new engineer opens it from any device and starts. No local setup, and idle time is never billed.

Join from any browser, or the CLI

Open the drive in a browser, or log in once from the terminal with a device code and attach to the drive by name. The stock OpenCode CLI attaches unchanged, so a new hire uses whatever they are comfortable with.

Learn the codebase live, not from a doc

Presence shows who is in the session. Follow a teammate's view to watch where they look and what they prompt, ask questions in the in-session chat overlay, and see the same shared, auto-reloading localhost preview they do.

The agent already knows the repo

The repo was read into the session long before the new hire arrived, and it stays warm. A new engineer prompts the same agent everyone else does and gets answers grounded in the real code, with no context to load of their own.

Set up the drive once, onboard everyone from it.

The repo is read into the drive once and kept warm for everyone who joins. The drive holds the whole team, so a new hire joins the same drive your team already works in, in the same live session, with the same agent. Sessions push to your real git, and access is controlled per session, so you decide what a new engineer can see and join.

Onboarding, answered

No. The drive is a cloud workspace that stays warm with the repo, the dependencies, and a running environment ready. A new engineer opens it in the browser, or attaches from the CLI, and starts in a working environment. There is nothing to install locally, and the drive sleeps when idle, so idle time is never billed.

Several people share one live session on one running filesystem and terminal. Presence shows who is in the session, and you can follow a teammate to see their view as they move through the codebase and prompt the agent. There is an in-session chat overlay for questions, and the localhost preview is shared and auto-reloading, so a new hire sees exactly what a teammate sees.

Yes. Access is controlled per session. Keep a session private to you, share it with named teammates, or open it to the whole drive. A mentor can run a private session and invite the new engineer by name, or open a shared session for the whole team to join.

Onboard your next hire in a live session.

Launch a warm drive with the repo and environment ready, invite a new engineer, and let them follow a teammate from the first hour. Open it in the browser, or attach from the OpenCode CLI.