DEV Community: Sungwoo Lee

Playwright connect_over_cdp Hangs 100s? Check for One Dead Tab

Sungwoo Lee — Sat, 07 Nov 2026 01:06:38 +0000

If connect_over_cdp hangs for 100 seconds while /json/version answers instantly, Chrome is not dead. One open tab has a hung renderer, and Playwright's auto-attach is waiting on it. Find that tab over a raw browser-level websocket, close only that tab, and connect again. Do not restart Chrome.

I got this wrong the first time. The write-up of the original incident is in this post on my blog; this is the version for people who just want the diagnosis and the commands.

The symptom: a 100-second hang with a healthy endpoint

Chrome was running with its debugging port on 9401. My script did the usual thing:

from playwright.sync_api import sync_playwright

CDP = "http://127.0.0.1:9401"
with sync_playwright() as p:
    b = p.chromium.connect_over_cdp(CDP)   # sits here for 100 seconds, then times out

The call did not fail fast. It stalled until the 100-second timeout. Meanwhile this returned immediately:

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:9401/json/version
# 200

That combination is the whole puzzle: the HTTP side of the debugging port is fine, and the Playwright handshake is not.

Why "Chrome is dead" was the wrong diagnosis

My first conclusion was that Chrome had died and needed a restart. That does not fit the evidence. A 200 from /json/version means the browser process is up and its DevTools server is serving requests. A dead browser does not answer.

So the question changes from "is the browser alive?" to "what is Playwright waiting for?"

The real cause: auto-attach to a tab that cannot answer

When connect_over_cdp connects, Playwright automatically attaches to every page that is already open. If one of those pages has a hung renderer, the attach step for that page never completes, and the whole connection is dragged along until the timeout.

So one bad tab, out of however many you have open, is enough to make the entire connect call look like a browser failure. The browser is fine. The tab is not.

Telling browser failure from tab failure

Check three layers, from the outside in:

Layer	Probe	What a healthy answer means
HTTP endpoint	`/json/version`	Browser process and CDP server are up
Browser target	`Target.getTargets`	The browser itself responds over the websocket
Individual page	`Runtime.evaluate` with a trivial expression	That page's renderer is responsive

If the first two answer and one page does not answer the third, the browser is not the problem. That tab is.

The trick is to run these probes without going through Playwright, because Playwright's own connect is the thing that hangs.

Finding and closing the dead tab

Connect straight to the browser websocket URL that /json/version reports, list the page targets, and probe each one with a short timeout. Three to five seconds per page is plenty; the sketch below uses five. This sketch uses the websocket-client package:

import json, urllib.request, websocket

PORT = 9401
ver = json.load(urllib.request.urlopen(f"http://127.0.0.1:{PORT}/json/version", timeout=3))
ws = websocket.create_connection(ver["webSocketDebuggerUrl"], timeout=5)
_id = 0

def send(method, params=None, session=None):
    global _id
    _id += 1
    msg = {"id": _id, "method": method, "params": params or {}}
    if session:
        msg["sessionId"] = session
    ws.send(json.dumps(msg))
    while True:  # raises WebSocketTimeoutException if nothing answers in time
        reply = json.loads(ws.recv())
        if reply.get("id") == _id:
            return reply.get("result", {})

pages = [t for t in send("Target.getTargets")["targetInfos"] if t["type"] == "page"]
for t in pages:
    try:
        sid = send("Target.attachToTarget", {"targetId": t["targetId"], "flatten": True})["sessionId"]
        send("Runtime.evaluate", {"expression": "1+1"}, session=sid)
        send("Target.detachFromTarget", {"sessionId": sid})
        print("ok  ", t["targetId"], t["url"][:60])
    except websocket.WebSocketTimeoutException:
        print("HUNG", t["targetId"], t["url"][:60])

Note the code is syntax-checked but I have not re-run it against a live hung tab for this write-up. Whatever line prints HUNG gives you the targetId to write down. Then close just that tab on the same browser connection:

send("Target.closeTarget", {"targetId": "<the id you wrote down>"})

Now call connect_over_cdp again. With the dead tab gone there is nothing for auto-attach to choke on, and the connect returns normally.

If the connect works but you want a clean slate, pg.goto('about:blank') on a page and pg.close() are the Playwright-level equivalents once you are attached.

Why not just restart Chrome

Restarting looks simpler, but if several jobs share one Chrome profile, a restart wipes the logged-in sessions and in-progress state of all the other jobs, to fix a problem that lived in one tab. Closing a single target costs nothing to the others.

If you really do need to shut the browser down, ask it to leave politely with the CDP Browser.close command, for example s.send("Browser.close") on a CDP session, rather than killing it by process name. Killing by name hits every Chrome on the machine, including ones you did not mean to touch.

When this diagnosis does not apply

/json/version does not respond at all. Then the browser or its debugging server really is down, and a restart is the right move.
You are closing the last tab. Chrome exits when its last tab closes. Open a blank tab first.
The hung tab is doing real work. Save whatever result it has before you close it, because closing discards it.

A short pre-connect checklist

Before pointing Playwright at a long-lived Chrome:

Run the curl check and confirm you get 200.
If connect still stalls, stop waiting and probe Target.getTargets over the raw websocket.
Probe each page with a trivial Runtime.evaluate and a 3 to 5 second cap.
Close only the page that does not answer.
Reconnect.
Restart the browser only if step 1 fails.

The longer walk-through, including the misdiagnosis and the FAQ, is in the original post: Claude Code CDP connect hang, one tab at fault.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.

Claude Code Auto-Compact: 12 of 22 Drops Were Real, Half Were One Turn

Sungwoo Lee — Tue, 27 Oct 2026 23:33:33 +0000

If Claude Code keeps summarizing your session, the usual explanation is "the conversation got long." In our transcripts that was only half the story. We re-judged 22 sudden context drops across two projects (2026-08-09). Only 12 were real auto-compactions, and half of those 12 came from one large input landing in a single turn, not from slow accumulation. All six of those surge cases were turns where we had called the advisor, a stronger model consulted with the full conversation.

That changes the fix. Raising the context cap helps accumulation. It does nothing for a single turn that is big enough to cross the line again. Below is how we told the cases apart, what the trigger point turned out to be, and what we do first now. The full write-up, including the parts we got wrong twice, is in the original post on my-blog.org.

What counts as a real compaction

Auto-compact summarizes the conversation when context reaches a policy limit. It works in two stages: it first discards old tool output, and only if that is not enough does it summarize the conversation itself. That order matters later, because it means big tool output is exactly what gets thrown away first.

Of our 22 drops, 12 were real compactions, 3 were advisor round-trips that bounced back, and 7 were artifacts of session resume. If you count every dip in a context graph as a compaction, you will blame the wrong thing.

Do not classify by ratio

Our first attempt was a ratio. A compaction rewrites the prefix, so we expected cache_write / context-after to be close to 1. It wasn't. Across real compactions that ratio swung from 0.58 to 1.00.

The reason is the denominator. During back-to-back compactions the system prompt and tool schemas are cache hits, so the ratio drops to 0.6 to 0.75. On the first compaction after a long gap everything is rewritten and the ratio approaches 1.00. That cached portion was about 31.5k in both projects (116,310 minus 84,459 is 31,851; 92,999 minus 61,454 is 31,545). The ratio was measuring cache state, not whether a compaction happened.

An absolute cache_write value separates the cases cleanly:

Verdict	Condition	What it is
Real compaction	cache_write of roughly 50,000 or more	The conversation was actually summarized
Advisor round-trip	cache_write of roughly 10,000 or less	Context swelled briefly and came back
Resume artifact	cache_write 0 and context-after 0	A recording artifact of resuming a session

The classification script

Transcripts record the same request on two or three rows. Deduplicate by requestId first, or usage is overcounted by about 1.9x. Then compute per-turn context as input + cache_read + cache_creation, find the adjacent-turn drops, and classify. The order of the checks matters, so resume artifacts are not mislabeled as advisor round-trips.

def ctx_of(u):
    # field names depend on your transcript schema
    return u["input"] + u["cache_read"] + u["cache_creation"]

def classify(cw, ctx_after):
    if cw == 0 and ctx_after == 0:
        return "resume artifact"
    if cw >= 50_000:
        return "real compaction"
    if cw <= 10_000:
        return "advisor round-trip"
    return "undecided"

seen, rows = set(), []
for row in transcript_rows:        # one line = one assistant response
    if row["requestId"] in seen:   # same request is logged 2-3 times
        continue
    seen.add(row["requestId"])
    rows.append(row)

Run this outside the conversation. Reading a whole transcript inside the session inflates the very context you are trying to measure. We also had a PreCompact hook that archives the full transcript at each compaction, which let us cross-check seven verdicts against archive timestamps. All seven matched, with a 2 to 6 minute offset from the KST/UTC difference. Without a hook like that you are relying on the formula alone.

Why the advisor is the usual surge

An advisor call sends the whole conversation to a stronger model, so the turn's context becomes 2.05 to 2.20 times larger (six observed cases). The mechanism is simple: multiply your context at call time by 2.2. If the result is past the trigger line, compaction fires on the spot. If not, context returns to normal after the response.

Regime	Advisor calls	Outcome
After setting a cap	5	5 compactions
Before the cap (trigger at the model limit)	4	3 reverted, 1 compacted

"I used to call the advisor all the time and it was fine" is not a counterexample. It is a record from a regime where the trigger sat at 1M tokens, so 2.2x never reached it. The next largest turn-inflators are the same category: reading a 123KB file whole (about 35k tokens), full log reads, multi-page PDFs, big JSON dumps, ls -R, and unbounded database queries.

Where the trigger actually sits

Setting a 240,000 cap does not mean compaction at 240,000. In our environment it fired at about 165,000 tokens, roughly 0.69 times the cap. We saw the transition from "not fired" to "fired" three times: 160,806 to 165,002, then 162,475 to 165,693, then 164,792 to 168,736.

We also made a mistake here. We overlaid the three observations and wrote "the trigger is above 164,792 and at most 165,002, a 210-token window." Nothing guaranteed the three observations shared the same conditions, and the trigger is not provably a function of the cap alone, since model and tool schema size are mixed in. We dropped the precision claim and kept two things: trigger T is about cap times 0.69, and headroom is T minus the floor after compaction.

The floor is a project constant driven by your fixed head (global instructions, project instructions, memory), so do not copy someone else's numbers:

	Project A	Project B
Fixed head	89KB	69KB
Floor after compaction	about 130,000	about 91,000
Headroom (T minus floor)	about 35,000	about 102,000
Cost per compaction	about 125,000	about 85,000

One compaction costs roughly 25k of summary output plus rewriting the floor. With about 35,000 of headroom, reading one 123KB file whole fills it.

What to do, in order of effect

Raising the cap is not at the top of the list.

Call the advisor less often. Drop the habitual "one more check." Keep it before irreversible work such as DDL, deploys, and external changes, where one bad DDL costs more than ten compactions.
Cap the largest single-turn increase: no whole-file Reads, use offset/limit, and use Grep to locate things.
Never take tool output whole. Use grep, head, and tail. Stage one of compaction discards exactly this output, so trimming output and the cap are one set.
Raise the cap only if headroom is genuinely short.
Shrink the fixed head. A lower floor reduces both headroom pressure and per-compaction cost.
Write big artifacts to files and pull back only a summary line.
Make subagents return conclusions only. A report stays in the parent context permanently, about 3.8k each as measured.

Two settings worth pairing with the cap:

{
  "autoCompactWindow": 240000,
  "showClearContextOnPlanAccept": true
}

If compaction is already looping, look at what went into the previous turn before touching the cap, and do not call the same thing again. Otherwise the loop keeps spinning.

What does not transfer

The general parts are the shape of the classifier and the relations T about cap times 0.69 and headroom equals T minus floor. Everything else is our environment. The 50,000 threshold means "about one floor rewrite," so with a much thinner fixed head, lower it to match your own floor. The method also assumes transcripts with per-turn usage values. We have not observed the natural compaction cycle under a cap, which is why we manage the advisor by how many times we call it, not by when.

The original post, with the extra FAQ and the reasoning behind each number, is here: Claude Code auto-compact is caused by one turn, not a full context.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.

Cloudflare Workers Pricing: $5 Minimum, 10M Requests Included

Sungwoo Lee — Sun, 25 Oct 2026 08:17:03 +0000

As of October 2026, Cloudflare Workers has a Free plan capped at 100,000 requests per day and a Paid plan with a $5 per month minimum that includes 10 million requests and 30 million CPU milliseconds. Past that, requests cost $0.30 per additional million and CPU time costs $0.02 per additional million CPU ms. There is no charge for data transfer or bandwidth.

I run my own site, my-blog.org, on Workers with D1 and R2, so this is the table I check before adding anything that runs on every request.

The two plans side by side

	Free	Paid (Standard)
Requests	100,000 per day	10 million per month included, then $0.30 per additional million
CPU time	10 ms per invocation	30 million CPU ms per month included, then $0.02 per additional million CPU ms
Duration	No charge	No charge or limit
Minimum charge	$0	$5 per month per account

Paid has a default max CPU of 30 seconds per invocation, configurable up to 5 minutes. Cron Trigger and Queue consumer invocations can run up to 15 minutes of CPU.

What is billed and what is not

Static assets: requests to static assets are free and unlimited, and they do not count toward Worker request billing.
Subrequests: Cloudflare does not bill for subrequests your Worker makes.
WebSockets: a connection is billed as one request (the initial upgrade). Messages routed through the Worker are not counted.
Bandwidth: no charge for data transfer or bandwidth.
Caching: with Workers Caching enabled, cache hits are billed at the request rate, but CPU time is billed only on cache misses or bypasses.

The practical consequence: a site that serves most pages as static assets pays almost nothing per page view, and the thing to watch is CPU milliseconds on the dynamic routes.

The limits that decide your architecture

Limit	Free	Paid
Subrequests per invocation	50	10,000 (configurable up to 10M)
Memory per isolate	128 MB	128 MB
Worker size (uncompressed)	64 MiB	64 MiB
Workers per account	100	500
Simultaneous open connections	6 per invocation	6 per invocation

The 50-subrequest cap on Free is the one that surprises people. A route that fans out to 60 API or database calls fails on Free and works on Paid. The 6 simultaneous connections cap means a seventh is queued, so a Promise.all over 20 fetches runs in waves.

A worked estimate

Take 25 million requests in a month, with CPU time inside the included 30 million ms. Requests over the included 10 million: 15 million. Overage: 15 x $0.30 = $4.50. Added to the $5 minimum, that is about $9.50 for the month, before any other Cloudflare product you attach.

That is my own arithmetic from the published rates, not a quote from Cloudflare, and it assumes the $5 minimum is the base charge that includes the allowances. D1 and R2 are billed separately and I have not priced them here.

Guardrails worth setting

You can cap CPU time per invocation in your Wrangler config or the dashboard to guard against runaway costs. For a first Paid month, set a cap and read the usage page after a few days instead of trusting an estimate.

If you want to see what a Workers-hosted site feels like from the outside, the tool pages on mine are at my-blog.org/tools.

Limits of this post

Every figure is from Cloudflare's Workers pricing and limits pages as of October 2026. I did not look up D1, R2 or KV prices, and the Workers limits page I used does not list them. Prices change, so confirm on the pricing page before you budget.

FAQ

Is Cloudflare Workers free? Yes, up to 100,000 requests per day and 10 ms CPU per invocation.

What does the Paid plan cost? A minimum charge of $5 per month per account, which includes 10 million requests and 30 million CPU ms.

Do static assets cost anything? No. Requests to static assets are free and unlimited.

Is bandwidth billed? No. There is no charge for data transfer or bandwidth.

Why does my Worker fail with many fetches on Free? The Free plan allows 50 subrequests per invocation; Paid allows 10,000.

Cloudflare Workers AI: 10,000 Free Neurons a Day, Then $0.011

Sungwoo Lee — Sun, 25 Oct 2026 08:01:26 +0000

As of October 2026, Cloudflare Workers AI gives every account 10,000 Neurons per day at no charge, and anything above that costs $0.011 per 1,000 Neurons on the Workers Paid plan. The free allocation resets daily at 00:00 UTC. If you only need the number to plan around: 10,000 free Neurons per day is 300,000 over a 30-day month, and the first 1,000,000 Neurons beyond that cost $11.

This post covers the pricing rules, the rate limits that bite before the money does, and the smallest Worker that calls a model.

What you get for free, and what happens at the limit

Item	Value
Free allocation	10,000 Neurons per day
Price above the free allocation	$0.011 per 1,000 Neurons
Reset	Daily at 00:00 UTC
Billing above free	Requires the Workers Paid plan

Workers Free accounts get the same 10,000 daily Neurons. Going past that requires upgrading to Workers Paid, which has a $5 per month minimum charge. Some models also accept prepaid AI Gateway credits as an alternative to the Paid plan.

A quick budget check, using only the prices above:

1,000,000 Neurons above the free allocation = 1,000 x $0.011 = $11.
Because the allocation resets daily at 00:00 UTC, a batch job that straddles midnight UTC draws on two separate daily allocations.

Per-token prices differ a lot by model

The same Neuron billing sits behind very different per-token prices. Input and output are priced separately, per million tokens:

Model	Input	Output
@cf/meta/llama-3.2-1b-instruct	$0.027	$0.201
@cf/meta/llama-3.1-8b-instruct-fp8-fast	$0.045	$0.384
@cf/openai/gpt-oss-120b	$0.350	$0.750
@cf/deepseek-ai/deepseek-v4-pro-0813	$1.320	$3.960

The cheapest and most expensive rows differ by about 49x on input price ($1.320 divided by $0.027). Pick the smallest model that passes your own test set before you look at anything else.

Rate limits hit before the bill does

Text generation is limited to 300 requests per minute, unless the model requires the Workers Paid plan. For models that do require it, the limit is per account and per model:

20 requests per minute on standard Workers AI billing.
50 requests per minute with prepaid AI Gateway credits (unified billing).

Other task types have their own ceilings, for example text embeddings at 3,000 requests per minute (1,500 for @cf/baai/bge-large-en-v1.5) and translation at 720 requests per minute. A queue consumer that fans out 100 text-generation calls in one minute to a paid-only model will be throttled at 20 or 50, whatever your budget says.

The smallest Worker that calls a model

Add the binding to your Wrangler config:

{
  "ai": {
    "binding": "AI"
  }
}

Then call a model from the fetch handler through env.AI.run. The model name below is the one used in Cloudflare's getting-started guide:

export default {
  async fetch(request: Request, env: { AI: Ai }) {
    const response = await env.AI.run("@cf/google/gemma-4-26b-a4b-it", {
      messages: [
        { role: "system", content: "Answer in one sentence." },
        { role: "user", content: "What is a Neuron in Workers AI billing?" },
      ],
    });
    return Response.json(response);
  },
};

Deploy with npx wrangler login and then npx wrangler deploy. npx wrangler dev runs locally, but local runs still use your Cloudflare account and incur usage charges, so the free allocation is spent while you test.

What I would do first

Run your real prompts on the smallest model in the table and compare answers before moving up.
Log the Neuron usage per call for a day so the $0.011 per 1,000 figure turns into your own number.
If a feature needs a paid-only model, plan around 20 requests per minute, not 300.

I run my own site, my-blog.org, on Cloudflare Workers with D1 and R2. The browser tools on it are served from that stack, and you can try them at my-blog.org/tools.

Limits of this post

Prices change. Every number here is from Cloudflare's documentation as of October 2026; check the Workers AI pricing page before you commit a budget. I did not convert Neurons to tokens, because the documentation page I used does not publish a conversion.

FAQ

Is Workers AI free? Yes up to 10,000 Neurons per day, on Workers Free or Paid. Beyond that you need Workers Paid at $0.011 per 1,000 Neurons.

When does the free allocation reset? Daily at 00:00 UTC.

Do I need the Paid plan to try it? No. The Free plan includes the 10,000 daily Neurons.

Why do I get throttled before I run out of Neurons? Per-minute rate limits apply separately: 300 requests per minute for text generation, or 20 for paid-only models on standard billing.

AI Coding Assistant Free: What 2,000 Completions and 50 Chats Buy

Sungwoo Lee — Sun, 25 Oct 2026 07:45:46 +0000

As of October 2026, the free AI coding assistant with a published hard number is GitHub Copilot Free: 2,000 code completions and 50 chat requests (including Copilot Edits) per month. Cursor's free plan is "limited" with no number, and Claude Code has no free plan at all. If your goal is to pay nothing, the realistic options are Copilot Free, Cursor Free, or an open-source agent such as Cline pointed at a local model.

I checked each vendor's own pricing or repository page on 2026-10-19. Anything I could not confirm is listed at the end instead of guessed.

The comparison

Tool	Free option	Published limit	Catch
GitHub Copilot Free	Yes	2,000 completions and 50 chat requests (including Copilot Edits) per month	Agent usage is described only as "limited", no number
Cursor Free	Yes	"Limited" Agent and Chat usage, no number	Third-party models (Claude, GPT, Gemini) are not available on Free
Cline	Yes (software)	None, Apache 2.0 license	You supply the model: Anthropic, OpenAI, Google, OpenRouter, or local via Ollama or LM Studio
Claude Code	No	n/a	The free claude.ai plan does not include Claude Code
Gemini CLI	Open source, Apache 2.0	Not published on the repository page	Its README says it was replaced by Antigravity CLI for the unpaid tier on June 18th, 2026

Reading the Copilot numbers

2,000 completions a month is about 67 a day over 30 days (2,000 divided by 30, rounded). That is a few hours of light editing, not a full-time workload. 50 chat requests is under 2 a day. Paid Copilot starts at Pro for $10 per month, with Pro+ at $39 per month, if you outgrow Free.

Use Free for: tab-completion in one project, a handful of chat questions when you are stuck. Do not plan around it for: refactors that need dozens of chat turns.

Cursor Free and the third-party model rule

Cursor's pricing page lists Free at $0 with limited Agent and Chat, and states that third-party models are not available on it. Paid plans start at Plus for $8 per month. On the Free plan you are therefore not choosing Claude or GPT; you are using what Cursor provides.

Cline: the only one where the limit is yours

Cline is an open-source coding agent (Apache 2.0) available as a VS Code extension, a JetBrains plugin, a CLI, a desktop app, and an SDK. It is not locked to one provider. With a local model through Ollama or LM Studio there is no per-token bill, and the ceiling becomes your hardware and the quality of the model you can run. With a hosted provider you pay that provider's API rate.

A decision rule

Want completions in an editor, zero setup: Copilot Free.
Want an agent-style editor and can live without Claude or GPT: Cursor Free.
Want no vendor quota and have hardware for a local model: Cline plus Ollama or LM Studio.
Want Claude Code specifically: it needs a Pro, Max, Team, Enterprise or Console account; Free does not qualify.

Why the word "free" needs a number

Every one of these tools is free to start and capped in a different unit: monthly requests, an unquantified "limited", or your own compute. Before you build a habit around one, find its unit and watch how fast you use it. I write up AI tooling comparisons like this on my English blog, Tangents, at my-blog.org/tangents.

Limits of this post

Vendors change plans often. Cursor's page in particular lists plan names that differ from older write-ups, so check the live page. I did not test output quality of any tool here; this is a limits and pricing comparison only. Other free offerings exist that I did not verify, and I left them out.

FAQ

Is there a fully free AI coding assistant? Copilot Free and Cursor Free cost $0 but are capped. Cline is free software but needs a model, which is free only if you run one locally.

How many completions does Copilot Free include? 2,000 per month, plus 50 chat requests including Copilot Edits.

Can I use Claude Code for free? No. Claude Code requires a Pro, Max, Team, Enterprise or Console account.

Does Cursor Free include Claude models? No. Third-party models are not available on the Free plan.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.

Claude Code Install: 3 Shell Commands, and the 2 Errors That Trip You

Sungwoo Lee — Sun, 25 Oct 2026 07:30:04 +0000

As of October 2026, the recommended way to install Claude Code is the native installer, and the command depends on your shell. macOS, Linux and WSL use curl -fsSL https://claude.ai/install.sh | bash. Windows PowerShell uses irm https://claude.ai/install.ps1 | iex. Windows CMD uses curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd. Run the wrong one and you get an error that looks like a broken installer but is not.

Everything below is from Anthropic's setup documentation at code.claude.com, read on 2026-10-19.

Before you start

OS: macOS 13.0+, Windows 10 1809+ or Windows Server 2019+, Ubuntu 20.04+, Debian 10+, or Alpine Linux 3.19+.
Hardware: 4 GB+ RAM, x64 or ARM64.
Network: an internet connection is required.
Account: Claude Code needs a Pro, Max, Team, Enterprise or Console account. The free claude.ai plan does not include it.

Install: pick your shell

macOS, Linux, WSL

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell (the prompt shows PS C:\)

irm https://claude.ai/install.ps1 | iex

Windows CMD (the prompt shows C:\ without PS)

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

The installer shows no progress while it downloads. When it finishes, open a new terminal window and run:

claude --version

A working install prints a version number such as 2.1.211 (Claude Code). For a fuller check, run claude doctor.

The 2 errors that are really a shell mix-up

Error	What it means
`The token '&&' is not a valid statement separator`	You pasted the CMD command into PowerShell
`'irm' is not recognized as an internal or external command`	You pasted the PowerShell command into CMD

Check the prompt: PS C:\ is PowerShell, C:\ without PS is CMD. If the install fails with syntax error near unexpected token '<' or a 403, the docs point to their troubleshooting page for alternative install methods.

If claude is "not found" after a successful install, the install directory is not on your PATH yet. Open a new terminal first; if that does not fix it, follow the "Fix your PATH" section of the troubleshooting guide.

Other install methods

Method	Command
Homebrew	`brew install --cask claude-code`
WinGet	`winget install Anthropic.ClaudeCode`
npm (needs Node.js 22 or later)	`npm install -g @anthropic-ai/claude-code`
apt, dnf, apk	Signed repositories for Debian, Fedora, RHEL and Alpine

Do not use sudo npm install -g; the docs warn it can cause permission issues and security risks. Native installs auto-update in the background. Homebrew, WinGet and Linux package manager installs do not, so run brew upgrade claude-code or winget upgrade Anthropic.ClaudeCode yourself. claude update applies an update immediately.

First run

cd your-project
claude

Claude Code prompts you to log in on first use through the browser. Git for Windows is recommended on native Windows so Claude Code can use the Bash tool; without it, Claude Code uses PowerShell as the shell tool.

Uninstall

On macOS, Linux and WSL:

rm -f ~/.local/bin/claude
rm -rf ~/.local/share/claude

Settings live in ~/.claude and ~/.claude.json; removing them deletes your settings, allowed tools, MCP server configurations and session history.

Limits of this post

I did not run the installers for this post; the commands are copied from the documentation as of October 2026, and the sample version number is the one shown there. Commands and URLs can change, so prefer the live setup page if anything fails. I write more Claude Code notes, mostly in Korean, at my-blog.org/claude-code.

FAQ

What is the Claude Code install command? For macOS, Linux and WSL: curl -fsSL https://claude.ai/install.sh | bash.

How do I install Claude Code on Windows? In PowerShell, run irm https://claude.ai/install.ps1 | iex. In CMD, use the curl-based install.cmd command shown above.

How do I check it worked? Open a new terminal and run claude --version.

Does it need Node.js? Not for the native installer. The npm package requires Node.js 22 or later.

Can I use the free Claude plan? No. Claude Code requires a Pro, Max, Team, Enterprise or Console account.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.

Cursor vs Claude Code: $8-$200 Plans, but Claude Bills Extra

Sungwoo Lee — Sun, 25 Oct 2026 07:14:27 +0000

As of October 2026, the biggest difference between Cursor and Claude Code is not the interface, it is how Claude is paid for. Cursor's plans run from $8 to $200 per month, but its included usage pool covers Cursor's own models, and third-party models such as Claude are billed separately at API list price from prepaid credit. Claude Code is included in a Claude Pro ($20 per month, or $17 billed annually) or Max (from $100 per month) subscription, with usage limits that reset on a rolling five-hour window.

All numbers below come from cursor.com and claude.com / code.claude.com pages I read on 2026-10-19.

Side by side

	Cursor	Claude Code
What it is	An AI editor and coding agent	A terminal agent that also runs in VS Code, JetBrains, a desktop app, and the web
Free option	Free, $0, limited, no third-party models	None: the free claude.ai plan does not include it
Entry paid plan	Plus, $8 per month	Pro, $20 per month ($17 per month billed annually at $200 up front)
Middle tiers	Premium $30 (4x Plus), Super $100 (15x Plus)	Max from $100 per month (5x or 20x Pro usage)
Top tier	Ultra $200 (50x Plus)	Max, up to the 20x option
Usage reset	Weekly pool	Rolling five-hour session window, plus weekly limits on paid plans
Claude models	Third-party, billed at API list price from prepaid credit on Premium and above	Native

The billing detail that changes the math

On Cursor, paid plans include one weekly pool for Cursor models, shared across Grok and Cursor. The pool lists Grok 4.7, Grok 4.6, Grok 4.5 and Composer 2.5. Claude, GPT and Gemini models are not in the pool. On Premium and above they are billed at API list price from prepaid credit. The Free plan has no third-party models at all, and the Plus plan on the pricing page is described as Grok models only.

So "Cursor for $30 with Claude" is not one number. It is $30 for the pool plus whatever the Claude tokens cost at API rates.

On Claude Code, a Pro or Max subscription covers Claude Code usage against limits shared across web, desktop, mobile and Claude Code. If you instead sign in with a Console account, Claude Code charges by API token consumption. Anthropic's cost page gives the average across enterprise deployments as around $13 per developer per active day and $150-250 per developer per month, with costs below $30 per active day for 90% of users.

They are not mutually exclusive

Claude Code ships a VS Code extension, and the docs link an install for Cursor as well (cursor:extension/anthropic.claude-code). Some people run Cursor as the editor and Claude Code as the agent inside it. You pay for each side separately.

Which one to pick

You want the cheapest paid start and are fine with Cursor's own models: Plus at $8 per month.
You want Claude as the default model with predictable subscription pricing: Claude Pro at $20 per month, then Max at $100 if you hit limits.
You want Claude inside an editor you already like: Claude Code's extension in VS Code or Cursor.
You are optimizing for team administration: Cursor Teams starts at $30 per seat per month; Claude Team Standard seats are $20 per seat per month billed annually ($25 monthly).

Limits of this post

I compared pricing structure, not output quality. Cursor's plan names differ from older articles (it listed Pro and Pro+ previously; those are now marked legacy), so check the live pricing page. I did not benchmark either tool on a task.

More notes on AI tooling are on my English blog Tangents at my-blog.org/tangents.

FAQ

Is Cursor or Claude Code cheaper? Cursor starts at $8 per month, Claude Code at $20 per month (Pro). If you want Claude models in Cursor, they bill separately at API list price.

Can I use Claude in Cursor? Yes on paid tiers above the entry plan, billed at API list price from prepaid credit. Not on Free.

Is Claude Code included in Claude Pro? Yes. It is included in Pro, Max, Team and Enterprise, and not in Free.

How do Cursor usage limits reset? The pool refreshes weekly.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.

Claude Code Pricing: $20 Pro, $100 Max, and a $13/Day API Average

Sungwoo Lee — Sun, 25 Oct 2026 06:58:50 +0000

As of October 2026, you can pay for Claude Code in three ways: a Claude Pro subscription at $20 per month ($17 per month billed annually), a Max subscription from $100 per month, or per-token API billing through a Console account. Anthropic's own cost page puts the average API cost at around $13 per developer per active day and $150-250 per developer per month, with costs below $30 per active day for 90% of users. The free claude.ai plan does not include Claude Code.

Prices below are from claude.com/pricing and code.claude.com/docs/en/costs, read on 2026-10-19.

The plans

Plan	Price	Claude Code included
Free	$0	No
Pro	$20 per month, or $17 per month billed annually ($200 up front)	Yes
Max	From $100 per month, billed monthly only, 5x or 20x Pro's usage	Yes
Team Standard seat	$20 per seat per month billed annually, $25 monthly	Yes
Team Premium seat	$100 per seat per month billed annually, $125 monthly	Yes
Enterprise	US$20 per seat per month billed annually, 20-seat minimum, usage charged at API rates on top	Yes
Console (API)	Per token	Yes

How the limits work on a subscription

Every plan has usage limits that reset on a rolling five-hour session window, and paid plans also have weekly limits. The usage is shared across claude.ai on the web, desktop, mobile, and Claude Code, so a long chat in the browser eats the same allowance as a coding session.

When you hit it, Claude Code tells you "You've hit your session limit" or "You've hit your weekly limit". These are shared across all models, so switching models with /model does not restore access. After a model-specific message such as "You've hit your Opus limit", switching to a model outside that family does keep you working. Usage credits let you continue past the plan limit; run /usage-credits to manage them.

What drives the bill

Claude Code sends your full conversation with every request. The cost page lists these causes of usage climbing in a long session:

Long context: a one-line question in a session open all day still draws usage for the whole conversation.
Cache misses: your first message after a break longer than the cache lifetime reprocesses the full context. The lifetime is an hour on a subscription and drops to five minutes once you draw on usage credits; on an API key it is five minutes by default.
Subagents and agent teams: each runs its own context. Agent teams use approximately 7x more tokens than standard sessions when teammates run in plan mode.
Extended thinking: thinking tokens are billed as output tokens.

Five habits that cut the bill

Run /clear when you switch to unrelated work.
Use Sonnet for most coding and reserve Opus for complex architecture or multi-step reasoning. Switch with /model.
Lower the effort level with /effort for simple tasks.
Check /usage to see where plan usage goes. It flags behaviors such as long context or cache misses when one accounts for 10% or more of recent usage.
Keep CLAUDE.md under 200 lines and move specialized instructions into skills, which load only when invoked.

Which plan to start on

If you code a few hours a week, Pro at $20 per month is the entry point. If you hit the five-hour or weekly wall repeatedly, the next step is Max at $100 per month, which is 5x Pro's usage on the lower option. If you want to pay only for what you use, the Console route bills per token and /usage shows an estimate computed locally at list price, which is not an invoice.

My practice notes on Claude Code are written in Korean at my-blog.org/claude-code.

Limits of this post

The $13 and $150-250 figures are enterprise-deployment averages from Anthropic, not a forecast for one person. I did not verify the Max 20x monthly price, so it is not listed. Plans change; check the pricing page before you subscribe.

FAQ

How much does Claude Code cost? $20 per month on Pro ($17 billed annually), from $100 per month on Max, or per token via the API.

Is Claude Code free? No. The free claude.ai plan does not include it.

What is the average API cost? Around $13 per developer per active day, according to Anthropic's cost page.

Why did I hit my limit so fast? Long contexts, cache misses and subagents all multiply usage. Run /usage to see which one applies.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.

Why Idle Claude Code Sessions Burn Tokens: 4.7 Turns per Alert

Sungwoo Lee — Sun, 25 Oct 2026 06:43:14 +0000

Your Claude Code session can lose tokens while you are away from the keyboard. The reason is simple: every request re-sends the whole conversation, so anything that creates a new turn costs as much as a turn you typed yourself. In one session we measured, a single cross-session alert triggered 4.7 turns on average. Here are the five things that open turns in an idle session, how to measure them in your own logs, and what to change.

The cost model in one line

Each request carries the full context. So a session's cost is roughly:

session cost ~ average context size x number of turns

You control the first factor with /clear and by splitting work. The second factor is where idle sessions leak: the system can create turns when you are not typing. In a representative session from our logs (471 requests, about 458k tokens of average context), the cache-read total was 216.5M tokens against 0.43M output tokens. The product of context and turns explained almost all of it.

Five ways an idle session gets new turns

The first message after the cache expires. The prompt cache has a limited lifetime. On a subscription it is 1 hour; with an API key or usage credits the default is 5 minutes. Your first request after that gap re-processes the full context.
Scheduled tasks such as /loop. A loop fires on its interval even when you are not working, and each firing sends the full context.
Messages from another session. If you run several sessions that talk to each other, a message landing in an idle session becomes a new turn there.
Goal check-ins. A goal that is waiting on background work opens status-check turns. The original post reports a cap of 3 check-ins per goal between your prompts, introduced in v2.1.246; before that there was no limit.
Background-task and watcher notifications. A completion notice, or one line of output from a watch script, wakes the session for a turn each.

The cache expiry is the biggest single line item

We scanned 107 conversation transcripts from one project. Cache-expiry rewrites were the number one source of waste at 11.8%. The largest single rewrite was 778,949 tokens, after a gap of 10.6 hours.

The practical rule: if you are coming back after more than an hour, /clear and restart with a short brief instead of typing a follow-up into the old thread. A fresh start is free, and the old context would have been re-written in full anyway. The transcript scan behind these numbers has the method and the caveats.

One alert, 4.7 turns

Alerts are the cause people underestimate, because each one looks tiny. A notification arrives, and the chain that follows is: the session wakes, reads it, calls a tool, reads the result, and replies. Every step is a full-context request.

In one session on 2026-08-23 (172 requests after de-duplication):

15 alerts arrived from other sessions.
Those alerts triggered 70 requests, which is 70 / 15, about 4.7 turns per alert.
The same session had 4 cache-expiry rewrites totaling 619,876 tokens.
Alert-triggered requests made up 40.9% of that session's cost.

Compared head to head, 2 alerts cost about as much as one cache rewrite. If a watcher pings you on every item in a 50-item batch, you have bought 50 wake-ups, not one.

One more trap: if the alert text is truncated (ours was cut at 200 characters), the session often spends an extra turn reading the rest. Check that your notifier sends the whole message.

Measure your own sessions

Session logs are JSONL files under ~/.claude/projects/. Lines can be huge, so parse them as JSON line by line; do not grep them with wide regexes. Two details matter. First, one request can span several assistant lines, so de-duplicate by requestId. On 2026-10-10 one of our files had 463 assistant lines but only 218 unique request IDs; skipping de-duplication more than doubles your numbers. Second, count a request as an expiry rewrite when the gap from the previous request exceeds the cache lifetime.

import json, sys
from datetime import datetime

ttl = 3600  # seconds; use 300 for API key / usage credits
seen, reqs = set(), []
with open(sys.argv[1], encoding="utf-8") as f:
    for line in f:
        try:
            d = json.loads(line)
        except ValueError:
            continue
        if d.get("type") != "assistant":
            continue
        rid = d.get("requestId")
        usage = (d.get("message") or {}).get("usage") or {}
        if not rid or rid in seen or "timestamp" not in d:
            continue
        seen.add(rid)
        ts = datetime.fromisoformat(d["timestamp"].replace("Z", "+00:00"))
        reqs.append((ts, usage.get("cache_creation_input_tokens", 0)))

reqs.sort()
rewrites = [c for (a, _), (b, c) in zip(reqs, reqs[1:])
            if (b - a).total_seconds() > ttl]
print(f"requests={len(reqs)} expiry_rewrites={len(rewrites)} tokens={sum(rewrites)}")

This infers expiry from the time gap alone. It does not verify that the cache really expired, so treat the output as an estimate.

Cut the idle spend

In rough order of impact:

Run /clear when the topic changes.
Run /clear before resuming after a long break instead of continuing the old thread.
Check the Loops entry in /usage for scheduled tasks that keep firing while you are idle.
Hold cross-session messages that do not need an immediate answer.
Make watchers wake the session once, on completion or on abort, rather than on every success line.
Make sure alerts include the full text so no extra turn is needed to read the rest.

The full write-up, including the cost-model derivation and the transcript scan, is in the original post on my-blog.org.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.

Claude Code Automation: Publish Gates Blocked 23 Bad Posts in 10 Days

Sungwoo Lee — Sun, 25 Oct 2026 05:00:58 +0000

If Claude Code runs anything that publishes, posts, or deletes for you, don't rely on a prompt that says "be careful." Put a small script between the model and the irreversible step, and make that script read the actual output. In 10 days (2026-09-28 to 2026-10-07) one such gate ran 248 times on my Claude Code-run blog pipeline and blocked 37 of those runs. That stopped 23 different posts before they went live.

None of those numbers come from a model's "done!" message. They come from append-only JSON ledgers that every script writes on every run. Below are the counts, the four failures that forced each rule, and the steps to copy. The longer write-up, with the full tables, is on the original post.

What I measured in 10 days

Claude Code writes and edits the Python scripts, a Windows scheduler runs them, and each script appends one JSON line per run under data/ops/. I counted the ledgers line by line on 2026-10-07.

Measure	Value
Gate runs (247 Tistory, 1 dev.to)	248
Passed (exit 0)	206
Blocked (exit 1, defect found)	37
Checker itself broke (exit 2)	5
Distinct posts checked	57
Posts blocked at least once	23
Blocked, later fixed and passed	11

Over a longer window, 49 days with runs, the scheduled jobs logged 1,243 unattended runs across 44 jobs. 997 reported success with output, 207 reported success with zero output, and 39 reported failure.

Why the gate blocked posts

One run can carry two defects, so the reasons add up to 38 across the 37 blocked runs:

kw-demand (21): the keyword-demand research file was missing or older than 45 days.
fig-embed (6): charts were rendered but never inserted into the post body.
rel-date (4): relative dates like "this weekend" that turn false if publishing slips a day.
kw-grade (3): the target keyword was below the 200 monthly-search bar.
fig-numbers (3): a number in a chart appeared nowhere in the post text.
fig-count (1): fewer than 2 charts in the post.

Most blocks are boring. That is the point: they are the cheap, mechanical mistakes a model will make while reporting that everything is fine.

The 4 failures that created the rules

Every gate exists because something went wrong while every check said fine.

1. 132 posts shipped with zero images. The pipeline had published 132 posts with no images in the body, and every verification run passed. The check looked at the social preview image and exempted any post that had one. The fix was a shared gate that counts charts actually embedded in the body, which is where fig-embed and fig-count come from.

2. A post went live, then the job crashed before writing its ledger. The daily job published at 05:01:20 and died at 05:03 with ValueError: I/O operation on closed file. A late import replaced sys.stdout with a new wrapper, the old wrapper was garbage-collected, and it closed the shared buffer. No ledger entry meant the next morning's run would have published the same post again. The fix: use sys.stdout.reconfigure(...) instead, and write the ledger line immediately after each publish rather than at the end of the batch.

3. A --dry run rewrote an input file. A dry run of a social-follow script overwrote its target list with 30 candidates the owner had already rejected. The next scheduled run would have followed them, and dev.to has no unfollow API. The rule: dry means no state changes, not "different output." If a dry path writes even one file, it is not dry.

4. Code pasted through a shell heredoc broke the publisher twice. \n inside an f-string became a real newline, which was a SyntaxError. Worse, \b in a regex became the 0x08 control character, so the image counter always returned 0. That one passed syntax checks and surfaced only as "2 charts inserted, 0 images counted." Now any code containing backslashes goes through the file-edit tool, and a control-character scan runs afterward.

Why gates work where prompts don't

A prompt like "verify your work" asks the model to grade itself. Claude Code is good at writing a checker, but it is not a reliable witness to its own run, because the run's log and the run's result can disagree. Failure 2 is exactly that: the post existed and the record of it didn't.

A gate separates the two. It opens the output (the HTML, the chart files, the ledger) and returns an exit code, and the publisher refuses to continue on a defect. Claude Code then has a concrete, machine-readable reason to fix something. Of the 23 stopped posts, 11 were fixed and re-passed; the other 12 never passed in this window, so they never went out through the publisher with the defect.

Copy this setup

Give every checker three exit codes. 0 is clean, 1 is a defect, 2 means the checker itself is broken (no targets found, file unreadable). Finding zero things to check is exit 2, not a pass.
Append one JSON line per run with timestamp, target, exit code, and defect names. If the line count doesn't grow, the check didn't run.
Make the publish step call the gate and stop on exit 1. Put it inside the publisher, not in a checklist someone has to remember.
Write the ledger the moment the irreversible action happens, not at the end of the batch.
Restrict what a completion report may say. In CLAUDE.md, a report can cite only the checker's name and exit code, what a human actually opened, and what the gate cannot see.
Log every failure as symptom, cause, fix, then turn the fix into a check. My 169 incident entries are where most gate rules came from.

A minimal skeleton with the three exit codes and the ledger line:

import json, sys, time
from pathlib import Path

def check(html_path: Path) -> list[str]:
    html = html_path.read_text(encoding="utf-8")
    defects = []
    if html.count("<img") < 2:
        defects.append("fig-count")
    return defects

def main(paths: list[str]) -> int:
    targets = [Path(p) for p in paths if Path(p).is_file()]
    if not targets:
        return 2  # nothing to check means the checker is broken
    worst = 0
    with open("gate.jsonl", "a", encoding="utf-8") as ledger:
        for t in targets:
            defects = check(t)
            code = 1 if defects else 0
            worst = max(worst, code)
            ledger.write(json.dumps({
                "ts": time.strftime("%Y-%m-%dT%H:%M:%S"),
                "target": str(t), "exit": code, "defects": defects,
            }) + "\n")
    return worst

if __name__ == "__main__":
    sys.exit(main(sys.argv[1:]))

The publish step then runs this and aborts when the exit code is not 0.

Limits worth knowing

A gate with bad measurement lies with confidence. The first live run of a page checker flagged 320 defects across 80 pages. Every one was an analytics beacon failing because the checker opened pages from file://. When every target fails the same way, suspect the gate first.
Gates see surface patterns, not quality. A title-hook detector rated a good title as having zero hooks because its word list was incomplete, and it blocked a publish. Expect false positives and keep an explicit override.
"Success with zero output" is ambiguous. 207 runs reported success and produced nothing. Most were legitimate, such as a comment watcher with no new comments, so you must define per job what empty means.
This is one operator's setup, a single blog platform over a few weeks. It shows the mechanism works here; it is not a benchmark.

You don't need 44 jobs to start. Wrap the one script that publishes, posts, or deletes with a checker that exits 1 on the defect you fear most, and ask Claude Code to append a JSON line per run. For the full ledger tables and the incident details, read the full post on my-blog.org.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.

4,474 of 5,369 Output Tokens Were Thinking: Reading Claude API Errors

Sungwoo Lee — Sun, 25 Oct 2026 05:00:22 +0000

The most confusing Claude API failure is not a 400, a 429, or a 529. It is an HTTP 200 with an empty text block. Nothing was thrown and nothing was logged as an error, yet your JSON parser reports "no JSON found". In our case the cause was thinking tokens eating the whole max_tokens budget: 4,474 of 5,369 output tokens went to thinking, which left 895 for the answer.

This post is the triage order we use now. It separates "retry", "fix the request", and "wait", and it catches the failures that never produce an error at all. The longer write-up, with the full status table, is on the original post.

Errors share one shape, so classify by type

Every API error comes back as the same JSON object: a top-level error with a type and a message, plus a request_id.

{
  "type": "error",
  "error": {
    "type": "rate_limit_error",
    "message": "..."
  },
  "request_id": "req_..."
}

Branch on error.type, never on the message text. The docs say wording can change, and the SDK raises a different exception class per status code, so catch the class. A string comparison on the message will break silently one day.

The first-pass reading:

400 (invalid_request_error): the request is wrong. Retrying the same request gives the same result.
429 (rate_limit_error): a limit of some kind. Which kind matters, see the next section.
529 (overloaded_error): temporary overload across all users. Wait and retry. It is not an account problem.
500 (api_error) and 504 (timeout_error): server-side. Back off, or move long requests to streaming or the batch API.

One more detail: the SDK already retries connection errors, 429s, and 5xx responses twice with exponential backoff, honoring retry-after. If an exception reached your code, two more attempts already happened.

429 is three different problems

A 429 can be a rate limit, a monthly spend cap for your usage tier, or a Claude Code workspace spend limit. Only the first one clears if you wait.

The tell is the retry-after header. A rate limit sends it. A spend cap does not, and it keeps failing until access reopens. If you treat a spend cap as a rate limit and add backoff, you get a loop that receives the same 429 all day.

import anthropic

def classify_429(err: anthropic.RateLimitError) -> str:
    ra = err.response.headers.get("retry-after")
    if ra is None:
        return "cap-type: stop retrying, check spend caps and workspace limits"
    return f"rate-type: retry after {ra}s"

Rarely, a sudden jump in organization usage can trigger a 429 from an acceleration limit. The fix there is to ramp traffic up gradually and keep usage patterns even.

A 400 on a valid-looking request

When the payload looks fine, check whether the model dropped a parameter. These are the messages that mattered to us:

Message fragment	Cause	Fix
"does not support assistant message prefill"	Newer models reject a prefilled last assistant message	Use structured output or the system prompt
`"thinking.type.enabled" is not supported`	Fixed `budget_tokens` thinking was removed on newer models	`thinking: {type: "adaptive"}` plus `effort`
"thinking blocks ... cannot be modified"	You edited or dropped the previous assistant turn's thinking blocks	Send them back unchanged
`tool_choice: type "tool" and "any" are not supported`	Some models reject forced tool calls	`auto` plus strict tool use

One observation that is not in the official error docs: our LLM wrapper has a comment saying not to pass temperature, left behind after an old example that included it returned a 400. Treat that as our environment's experience, not a documented rule.

Empty response, HTTP 200, no error

Thinking tokens count toward max_tokens. If thinking spends the budget first, the response ends with stop_reason: "max_tokens" and the text block is truncated or missing. The status is 200 and no exception is raised.

Our case: a call asking for a content plan as JSON returned an empty string and failed with "JSON not found". We then walked a four-step misdiagnosis:

The log said "JSON parse failed".
We assumed the prompt was steering the model wrong and rewrote it.
The same failure came back. It failed three times in a row.
The real cause was the output budget. The clue was that the raw response was an empty string.

That last point is the discriminator. If the prompt had pushed the model toward prose instead of JSON, the raw response would not be empty. Only an empty raw string supports the "thinking used the budget" diagnosis.

def diagnose_empty(resp) -> str | None:
    text = "".join(b.text for b in resp.content if b.type == "text")
    if text.strip():
        return None
    thinking = getattr(getattr(resp.usage, "output_tokens_details", None),
                       "thinking_tokens", None)
    return (f"empty response: stop_reason={resp.stop_reason}, "
            f"output={resp.usage.output_tokens}, thinking={thinking}")

The field to read is usage.output_tokens_details.thinking_tokens. When streaming, it only appears on the final message_delta event.

There are two official fixes: raise max_tokens so thinking and text both fit, or lower effort so thinking spends less. We added a third. We cut what a single call has to produce: instead of "plan N posts at once", we ask for one outline, then one table of contents per post. The call that had failed three times passed on the first try.

The rule of thumb: if the output must arrive in one piece, use the official fixes. If it can be split, split it.

A six-step check order

Is the status 200? If the result is empty, it is an output budget problem. Read stop_reason and thinking_tokens.
Is it a 400? Find the parameter name in the message (prefill, thinking.type, tool_choice). Do not retry unchanged.
Is it a 429? retry-after present means rate-type; absent means cap-type, so stop the loop.
Is it a 529 or 500? The SDK already retried twice. Wait longer, and record the request_id if it persists. Give that ID to support.
Is it a 504 or a long request? Move anything that may exceed ten minutes to streaming or the batch API. Note that an error can still arrive after a streamed 200.
Is it a Claude Code MCP tool? Check /mcp, and if only the first call fails, raise MCP_TIMEOUT.

When the first MCP call fails

If a Claude Code MCP tool fails only on its first call in a session, suspect a cold start. One of our search-console servers times out on the first call and works once a lightweight tool has woken it.

Control	What it adjusts	Example
`MCP_TIMEOUT` env var	Server startup wait	`MCP_TIMEOUT=10000 claude`
Per-server `timeout` in `.mcp.json`	Tool execution time in ms	`"timeout": 600000`
`MAX_MCP_OUTPUT_TOKENS`	Tool output token cap	Default 25,000

The caution that matters most: do not retry a timed-out write. A timeout means "result unknown", not "failed". Resending a write that already landed applies the change twice, so check whether it took effect first.

Two things this table does not cover. The subscription limit messages in the Claude Code UI, such as "You've hit your session limit", are plan notices, not HTTP errors. And any automation that reports "success" while producing nothing belongs to the same family as the empty response.

For the full status table, the FAQ, and the related posts on this, see the complete guide on my-blog.org.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.

One Unattended Claude Loop Burned 13 Points of Plan Usage

Sungwoo Lee — Mon, 19 Oct 2026 23:35:21 +0000

An LLM loop with no stop condition ran overnight on my Claude subscription and burned 13 percentage points of plan usage. The problem was not the price per token. Nothing in the code could end the loop, and nobody was watching. This post covers how Claude plan limits actually work, how to read your usage, and the three caps I now put in every unattended loop.

The limits are shared with the chat app

Pro and Max subscriptions include Claude Code, and the limits come as two meters: a 5-hour session limit and a 7-day weekly limit. According to Anthropic's help pages, Claude and Claude Code draw on the same pool. Whatever you spend in the chat app shrinks what Claude Code can use, and the reverse is also true.

That sharing is why an "unexpectedly high" bar in the morning is hard to explain from a terminal alone. If part of the usage came from the app, it will not show up in the terminal breakdown.

Two details are easy to get wrong when you hit a limit:

Switching models only helps when the message names a model (for example an Opus-specific limit). For the generic "all models" message, switching does nothing.
Your options are to wait, turn on usage credits, or auto-continue after the reset. Auto-continue is configured with /rate-limit-options on v2.1.234 or newer, and organizations use the autoContinueAtUsageLimit setting.

Usage credits have a side effect: the prompt cache lifetime drops from 1 hour (60 minutes) to 5 minutes, so the same working habits cost more. Also, the monthly API credit included with Max cannot be used to extend Claude Code limits.

Read /usage the right way

Type /usage inside Claude Code. As a subscriber, ignore the Session block and look at the plan usage bars and the breakdown beneath them. The breakdown has three parts:

Attribution: share of usage by skill, subagent, plugin, and MCP server.
Behavior flags: things like long contexts and cache misses.
Loops: runs and tokens per scheduled task (v2.1.242 or newer).

Press d for the last 24 hours and w for the last 7 days. One caveat: these numbers come from local records on the machine you are on. Other devices and claude.ai app usage are missing.

What the overnight incident looked like

On 2026-08-01 an LLM loop ran overnight without anyone approving it, and plan usage went up by 13 percentage points. The 13 is a reading from the meter, a before/after change. I deliberately did not convert it to a token count, because any conversion factor would be an estimate. (The full incident write-up has the details.)

The root cause was that the loop could not stop. If a person had been watching, it would have been killed within minutes. Switching it to a cheaper model would not have fixed anything either, because the missing exit condition would still be there, just burning more slowly.

Put three caps in the loop

Pick at least two of these and enforce them in code: a consecutive-failure cap, a total-call cap, and a wall-clock cap. The values from my own example are 3 consecutive failures, 200 calls, and 3 hours.

import time

MAX_FAILS, MAX_CALLS, MAX_SECONDS = 3, 200, 3 * 3600

def run(task, step):
    start, calls, fails = time.time(), 0, 0
    while not task.done():
        if fails >= MAX_FAILS:
            return "stopped: 3 consecutive failures"
        if calls >= MAX_CALLS:
            return "stopped: 200 calls"
        if time.time() - start >= MAX_SECONDS:
            return "stopped: 3 hours"
        calls += 1
        try:
            step(task)
            fails = 0
        except Exception:
            fails += 1
    return "done"

The check runs before every iteration, and the function returns the reason it stopped so you can log it. Test the guards first: feed step a function that always raises, and confirm you get the failure message after exactly 3 attempts.

One trap: a 429 cooldown is not a cap. It is a resume mechanism, because it revives the loop in every new limit window. It lets the loop run forever, politely.

A checklist before any unattended run

Write down the expected usage before you start.
Have a human approve that estimate.
Set at least two caps and test them.
On exit, log the stop reason and the usage.
Once a month, audit every cron job, scheduler entry, and background runner.

The guard only covers loops you wrote yourself. For Claude Code's own /loop, check the Loops row in /usage and turn it off or lengthen the interval by hand. And because app usage is not in the breakdown, a high morning bar cannot always be attributed from the screen alone.

The full write-up, including the FAQ on limits, credits, and model switching, is in the original post on my-blog.org.

Free tools I keep on my own site: 34 calculators and how-to guides - loans, severance pay, take-home salary, savings vs deposits. New ones go out in one email, no ads.