We spent 229 prompts asking an editor extension to manage windows before we built a session host instead.
The session ran 20h 16m and opened with a complaint that the work log truncates mid-word. We liked the Claude extension in Cursor, but when working with Claude it couldn’t spawn and manage windows (“…manage these windo…”).
What the extension route cost
The log titles the session “Claude extension window management”. It ran from 2:25 PM to 10:40 AM and used out=311,750 tokens with cache_read=69,682,562.
The close-out summary records the decision. We dropped the extension route and built our own session host.
What the session host does
Every spawned session now gets its own controllable window, with live progress, approvals and restart recovery.
Our session dashboard can run sessions on the host behind a flag, and one test session has switched over.
The secretary no longer sends refused permission requests to our phones.
Two small sessions in the host project
The host project shows up in the log at 12:37 AM and 12:39 AM. Both sessions have the same first prompt: “Reply with exactly the digit 0.” The first took 10 prompts and 3,352 output tokens. The second took 9 prompts and 2,619.
What isn’t proven yet
The follow-ups are filed. The log marks two things as not yet proven live:
The secretary hook on the phone path.
Placement ladder steps 2 to 4.
So the claim the log supports is narrow. Every spawned session gets its own controllable window with live progress, approvals and restart recovery, and one test session has switched over behind the flag.
Counting the workaround
The session started with a complaint about what a tool couldn’t do. Every prompt after that went into working around the gap, until the effort piled up enough that building the thing was the obvious move. Until the secretary hook and the placement ladder steps are proven live, treat those two parts as unverified.
AI Skills
Use this lesson with the AI assistant you already use
A session that opened with a complaint about the Claude editor extension, which could not spawn and manage windows, ran 20h 16m and took 229 prompts. The author then dropped the extension route and built their own session host.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Count The Prompts Spent Asking A Tool For What It Cannot Do, Then Build It Yourself
SOURCE: dxdev.com/blog/session-host-vendor-exit
WHAT HAPPENED: The session was titled "Claude extension window management" and ran from 2:25 PM to 10:40 AM. It used 311,750 output tokens and 69,682,562 cache read tokens while trying to get the extension to do something it could not. The author's closing summary records the decision to drop the extension route and build a session host. Every spawned session now gets its own controllable window with live progress, approvals and restart recovery. The cockpit can run sessions on the host behind a flag, and one test session has switched over. The secretary hook on the phone path and placement ladder steps 2 to 4 are marked as not yet proven live, so the author claims only what was shown.
THE RULE: When a session opens with a complaint about what a tool cannot do, count the prompts spent asking it to do that anyway, and treat a high count as the signal to build the missing capability. When you report the result, claim only what has been shown live and list the rest as unproven.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. For any session that began with a complaint about a tool's limitation, the prompt count spent trying to work around that limitation is recorded, along with a threshold at which you stop and build instead.
2. The close-out summary of a build-versus-keep-using decision states the decision and the evidence behind it, such as prompt count, duration and token totals.
3. Every capability claimed for the new system is either demonstrated live or explicitly listed as not yet proven, with a follow-up filed for each unproven item.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
