DEV Community: Andrew R

[Boost]

Andrew R — Mon, 31 Aug 2026 20:20:35 +0000

Ben Halpern for The DEV Team

Aug 31

Fixing Delicate Cache Mismatches in a Brownfield SPA: A Pragmatic Solution

#webdev #architecture #webperf #rails

4 min read

MCP elicitation no longer holds a stream

Andrew R — Fri, 28 Aug 2026 23:12:02 +0000

MCP elicitation on a Worker is a return now. You send input_required, the request ends, and Claude Code draws the form after the isolate has already gone home.

The page a lot of people still land on is Cloudflare's older remote MCP guide, the one that still lists McpAgent as the elicitation option. That path awaits elicitInput on a live session. Spec 2026-07-28 replaced the held stream with Multi Round-Trip Requests, and Cloudflare's MCP handler API says the Worker does not remain suspended while a user responds.

Copy the await and you pay for a pinned isolate, or you time out while the human is still reading the prompt.

What has to be true first

This is a Worker you can paste, not a recap of why MCP went stateless. The session-moved explainer already covers that. Here the isolate has to finish before the form is up.

Wrangler 4.x with nodejs_compat and a compatibility_date at or after 2026-06-11
agents plus @modelcontextprotocol/server@2.0.0 and zod, the pin from Cloudflare's handler API
A signing secret of at least 32 random bytes in .dev.vars as MRTR_REQUEST_STATE_KEY
Claude Code 2.1.232 or later so the v2 runtime can speak protocol 2026-07-28 on HTTP
An HTTP URL that ends in /mcp

The elicitation dialog itself shipped in 2.1.76. The retry that matches this Worker is the later runtime. If claude --version is older than 2.1.232, stop and update before blaming the handler.

No Durable Object is required for this demo. Application state still wants a store. The protocol session is not that store.

Return input_required from the Worker

The first Worker request ends. The form is a later POST carrying the sealed chip.

Think of the first tools/call as a numbered ticket left on the counter. The shop is closed. The human fills a form later, then walks in with the ticket. That ticket is requestState. Camping at the register is the 2025 stream, and it is the frozen path.

Cloudflare's current example is mcp-elicitation-mrtr. The tool is increase-counter. Two input rounds, three Worker requests, zero pending Promises.

1. Pin the stateless handler

McpAgent still compiles. It is also deprecated and feature-frozen. createLegacyMcpHandler is the temporary bridge for people who still need a session transport. New elicitation goes through createMcpHandler from agents/mcp/server and a factory that returns a fresh McpServer from @modelcontextprotocol/server.

Pass the factory. A global server instance is the bug this API was written to stop.

npm i agents @modelcontextprotocol/server@2.0.0 zod

legacy: "reject" makes the endpoint stateless-only. The default legacy: "stateless" still accepts ordinary tools from older clients, and it still fails pushed elicitation/create immediately. GET and DELETE already return 405. If you wanted the old stream, you picked the wrong handler.

Checkpoint. The Worker boots. /mcp is the only path. A leftover Mcp-Session-Id header is ignored.

2. Put a signing key in .dev.vars

requestState round-trips through the client. Spec says treat it as attacker-controlled if it influences anything that matters, and protect it with HMAC or AEAD. The TypeScript SDK's createRequestStateCodec is HMAC-SHA256. Signed, not encrypted. The client can base64url-decode the payload, so keep secrets out of it.

printf 'MRTR_REQUEST_STATE_KEY=%s\n' "$(openssl rand -base64 32)" > .dev.vars

Production is wrangler secret put MRTR_REQUEST_STATE_KEY. Do not reuse the local value. The official README says at least 32 bytes, and it means it.

bind in this demo ties the blob to mcpReq.method, so a token minted for tools/call cannot hop onto a different method. That is the floor, not production. Spec says if requestState influences auth or business logic you protect integrity, and you should bind the authenticated principal, a short TTL, and an identifier for the originating request. The TypeScript codec takes ttlSeconds. This counter demo uses the method bind plus HMAC because there is no user. A refund tool that only bound the method would still replay inside another tools/call.

Checkpoint. wrangler dev starts. Drop the secret and the process throws MRTR_REQUEST_STATE_KEY must be configured instead of serving a handler that cannot seal anything.

3. Return input_required on the first call

The tools spec lets tools/call answer with an InputRequiredResult. resultType is input_required. Inside inputRequests sits an elicitation/create with mode: "form" and a flat JSON Schema. Nested objects are out. Passwords are out. A number and a boolean are in.

The handler returns. It does not await the human.

That return is the whole trick. The JSON-RPC response goes out. The Worker request is over. Claude Code still has a form to draw. Those two facts used to be glued together by an open stream. They are not glued now.

Checkpoint. Call increase-counter with { "current": 10 }. The result's resultType is input_required. wrangler dev has already logged the POST as finished.

4. Resume from sealed requestState

The next POST is a new tools/call with a new JSON-RPC id, the original arguments, that round's inputResponses, and the echoed requestState. Spec is blunt about it. The two requests are independent.

Here is the gotcha that eats people who treat this like a conversation that remembers. inputResponses do not accumulate. Round two has the amount, not a pile of earlier answers. Round three has the confirm checkbox. The current value and the accepted amount have to already live in the sealed blob, or the confirm step is confirming a ghost.

acceptedContent takes a Zod schema because the client is untrusted. inputResponse is how you tell a decline from a first visit. A cancel returns Counter increase cancelled. rather than pretending the human said no to a prompt they never saw.

Paste this as src/index.ts. It is the official example with the same two-round tool, same codec, same /mcp route.

import {
  McpServer,
  acceptedContent,
  createRequestStateCodec,
  inputRequired,
  inputResponse,
  type CallToolResult,
  type InputRequiredResult,
  type RequestStateCodec
} from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";
import { z } from "zod";

const amountSchema = z.object({ amount: z.number() });
const confirmationSchema = z.object({ confirm: z.boolean() });

type CounterRequestState =
  | { step: "amount"; current: number }
  | { step: "confirmation"; current: number; amount: number };

type Env = { MRTR_REQUEST_STATE_KEY: string };

function createServer(
  requestStateCodec: RequestStateCodec<CounterRequestState>
) {
  const server = new McpServer(
    {
      name: "stateless-mrtr-elicitation-demo",
      version: "1.0.0"
    },
    { requestState: { verify: requestStateCodec.verify } }
  );

  server.registerTool(
    "increase-counter",
    {
      description:
        "Calculate a counter increase using two stateless elicitation rounds",
      inputSchema: z.object({
        current: z.number().describe("Current counter value")
      })
    },
    async (
      { current },
      context
    ): Promise<CallToolResult | InputRequiredResult> => {
      const state = context.mcpReq.requestState<CounterRequestState>();
      if (!state) {
        return inputRequired({
          inputRequests: {
            amount: inputRequired.elicit({
              message: "By how much should the counter increase?",
              requestedSchema: {
                type: "object",
                properties: {
                  amount: {
                    type: "number",
                    title: "Amount",
                    description: "The amount to add to the current value"
                  }
                },
                required: ["amount"]
              }
            })
          },
          requestState: await requestStateCodec.mint(
            { step: "amount", current },
            context
          )
        });
      }

      if (state.step === "amount") {
        const amountResponse = inputResponse(
          context.mcpReq.inputResponses,
          "amount"
        );
        if (
          amountResponse.kind === "elicit" &&
          amountResponse.action !== "accept"
        ) {
          return cancelled();
        }

        const amount = acceptedContent(
          context.mcpReq.inputResponses,
          "amount",
          amountSchema
        );
        if (!amount) return cancelled();

        return inputRequired({
          inputRequests: {
            confirmation: inputRequired.elicit({
              message: `Increase ${state.current} by ${amount.amount}?`,
              requestedSchema: {
                type: "object",
                properties: {
                  confirm: {
                    type: "boolean",
                    title: "Confirm increase"
                  }
                },
                required: ["confirm"]
              }
            })
          },
          requestState: await requestStateCodec.mint(
            {
              step: "confirmation",
              current: state.current,
              amount: amount.amount
            },
            context
          )
        });
      }

      const confirmationResponse = inputResponse(
        context.mcpReq.inputResponses,
        "confirmation"
      );
      if (
        confirmationResponse.kind === "elicit" &&
        confirmationResponse.action !== "accept"
      ) {
        return cancelled();
      }

      const confirmation = acceptedContent(
        context.mcpReq.inputResponses,
        "confirmation",
        confirmationSchema
      );
      if (!confirmation?.confirm) return cancelled();

      const next = state.current + state.amount;
      return {
        content: [
          {
            type: "text",
            text: `Counter increased by ${state.amount}; next value is ${next}`
          }
        ]
      };
    }
  );

  return server;
}

function cancelled(): CallToolResult {
  return {
    content: [{ type: "text", text: "Counter increase cancelled." }]
  };
}

export default {
  fetch(request, env, ctx) {
    if (!env.MRTR_REQUEST_STATE_KEY) {
      throw new Error("MRTR_REQUEST_STATE_KEY must be configured");
    }
    const requestStateCodec = createRequestStateCodec<CounterRequestState>({
      key: env.MRTR_REQUEST_STATE_KEY,
      bind: ({ mcpReq }) => mcpReq.method
    });
    return createMcpHandler(() => createServer(requestStateCodec), {
      route: "/mcp",
      legacy: "reject"
    })(request, env, ctx);
  }
} satisfies ExportedHandler<Env>;

Checkpoint. Second POST asks for confirm and already knows current from the blob. Third POST prints Counter increased by 5; next value is 15 if the human typed 5. If you skipped the mint and expected round three to still hold the amount in inputResponses, you get cancel, and you deserved it.

Point Claude Code at the Worker

The dialog sits on a request that already finished. Submit starts a new POST.

Claude Code's MCP docs say elicitation dialogs appear automatically. No extra config on the client. Form mode is a dialog with the fields from requestedSchema. URL mode opens a browser, then you confirm in the CLI. This tutorial stays on form mode.

5. Add the HTTP server

claude mcp add --transport http counter http://localhost:8787/mcp

JSON configs that copy a url from someone else's client still need "type": "http". A url with no type is treated as stdio and skipped. Claude Code's MCP docs say the skip reports that the server has a url but no type. Before 2.1.202 it looked like command: expected string, received undefined. Run claude mcp get counter either way.

On 2.1.232 or later, Claude Code uses the v2 runtime, which is MCP TypeScript SDK 2.0, and it asks HTTP servers whether they speak 2026-07-28. That is the retry path this Worker returns. Older CLIs can draw a form and still speak the handshake-era wire.

Checkpoint. /mcp shows connected. claude mcp get counter prints the HTTP URL. If the row says pending approval, finish that prompt in the interactive session. Headless -p will not draw a form you can fill.

6. Fill the form after the first request already finished

Ask Claude to increase the counter from 10. The amount dialog should appear. Look at wrangler dev before you type. The first POST is already complete. That is the proof the isolate is not sitting on the form.

Claude Code's docs say a call waiting on an open elicitation dialog is not backgrounded because the server is blocked on your input. That sentence is about the client holding the dialog. The Worker already returned. Mix those two up and you will keep a Durable Object around for a stream that is not there.

Submit 5. Confirm. The tool result should read Counter increased by 5; next value is 15. Three Worker requests, two forms, one number that actually moved.

If you are building the server from nothing rather than adding elicitation to one you already have, the older from-scratch MCP server post is the generic shell. This one is only the ask.

When it breaks

A hung Worker is usually the wrong era, a missing key, or a decline nobody saw.

Official docs walk the happy path. The hours go into the three failures that look like a hung Worker and are not.

Wrong era. A handshake-era client (≤ 2025-11-25) has no InputRequiredResult. FastMCP names it in one breath. Tool 'book_flight' returned an InputRequiredResult to request client input, but the multi-round-trip result type (SEP-2322) only exists at MCP 2026-07-28; this connection negotiated '2025-11-25'. Cloudflare's legacy: "reject" lane refuses that client instead of shimming. Update Claude Code past 2.1.232, or you are debugging a protocol the Worker already declined to speak
Tampered state. No MRTR_REQUEST_STATE_KEY throws at boot. A blob the client edited fails with -32602 Invalid or expired requestState before your tool runs. That is the codec doing its job. If you mint { step: "confirmation" } before the human accepted the amount, anyone who echoes the token gets the step. Mint only what the previous round already proved
Fabricated decline. GitHub issue 89858 is the ugly one. Drive Claude Code with --input-format stream-json under a controlling client that never registered onElicitation, and the SDK answers { action: "decline" } with no prompt drawn

The spec defines decline as the human explicitly refusing. The server cannot tell a real no from a client that never asked. Related issues hit the VS Code extension and a TUI path that logged print-mode by accident.

Prove the form in the interactive REPL. Handle any action other than accept as cancel, not as a recorded human decision.

A fourth miss is copying elicitInput from McpAgent onto this handler. Pushed elicitation/create fails immediately on the stateless path. The isolate will not hang. The call just dies, which is ruder and much cheaper.

What now exists

A Worker at /mcp that returns input_required on the first increase-counter call, finishes that request, and waits for nothing. Claude Code shows the amount form, then the confirm form. The signed requestState is the only memory between those POSTs. The next value prints. The isolate was not held while you typed.

If the first wrangler line still sits in ok after you submitted, you shipped the 2025 stream by accident. Tear out the await.

Originally published on rizz.dev. Read the full version there.

The VS Code agent host is a process not a panel

Andrew R — Fri, 28 Aug 2026 09:25:47 +0000

The VS Code agent host is a dedicated process. Copilot, Claude, and Codex run there over the Agent Host Protocol. The chat panel is a client of that process, not the place the session lives.

The wrong model is the sidebar as the agent. That is the old extension-host world, where the loop sat next to Copilot Chat and died with the window. This walkthrough turns the host on, picks a harness that actually sits on it, and proves a second window attaches to the same session.

What you need first

Pin the build. The 1.130 notes shipped 22 July 2026. The dedicated process showed up a week earlier in 1.129. Use 1.130 or later so Claude and Codex worktrees exist on the host.

Desktop VS Code. The local host does not run in the web workbench. vscode.dev can be a client of a remote host. It is not the process on your laptop.

You also need credentials the selected harness accepts. Copilot wants GitHub. Codex on the host is experimental and off by default.

VS Code 1.130 or later (Help, About)
Desktop editor, not the web workbench as the host
GitHub Copilot, Claude, or Codex credentials
A Git repo with at least one commit if you will tick New Worktree

Turn the host process on

The switch starts a process. The panel is just a client.

Language servers already taught this shape. The editor is a client. The server is a process. The Agent Host Protocol is the same idea for agent sessions. Flip the wrong switch and you still have a pretty panel with a hollow back.

1. Enable chat.agentHost.enabled

Open Settings and search agent host. Enable chat.agentHost.enabled. The 1.130 notes still name that id as the opt-in, then tell you to pick a harness from the dropdown.

The public AI settings table lists a pile of host siblings and still skips this master switch. Search anyway. If the row is grey, managed policy can own it. Confirm with whoever ships org settings before treating it as a missing extension.

{
  "chat.agentHost.enabled": true
}

2. Reload and read the harness dropdown

Enablement is fixed at startup. Reload the window. Open Chat, start a new chat, then open the Session Target control.

Checkpoint. Copilot is in that list as a host harness. Local is still the extension host. Do not pick Local and call the job done. If the list looks unchanged, the toggle never stuck. Reload once more before you debug Claude.

Start a session on the host

Copilot sits on the host. Local stays on the extension.

Copilot is the boring first harness, and that is the point. The harness docs put it on the Agent Host on your machine. Local stays in the extension host on purpose.

3. Pick Copilot as the Session Target

Choose Copilot. The 1.130 notes say the host's Copilot agent is powered by the Copilot SDK, so behavior is aligned with Copilot CLI and the standalone Copilot app. Aligned, not a promise that every CLI flag exists in the panel.

Want Claude instead? Current defaults already prefer the host (chat.agents.claude.preferAgentHost and chat.agentHost.claudeAgent.enabled both true, both experimental). If Claude is missing from the list, flip those and restart the host process. Codex waits behind chat.agentHost.codexAgent.enabled, which still defaults to false.

4. Send a prompt and find the session in the list

Type something cheap. List the files in this folder. Submit.

Checkpoint. The sessions list grows a row with a status and a harness name. That row is the session. The transcript is a view of it. If the row never appears, you are still on Local, or the host process did not come up after the reload.

Attach a second window

Two windows. One session. Close a pane and the host stays up.

This is the proof the title is betting on. One process. Two clients. Same session.

5. Open the Agents window

Hit Open in Agents in the title bar, run Chat: Open Agents Window from the Command Palette, or start it from a terminal.

code --agents

The Agents window is a dedicated client with a sessions list, a chat area, and a Changes panel. The Agents window docs say it shares sessions with the Chat view. It is still not the host.

6. Select the same session from the list

Find the row you just started. Click it. The transcript should match. Type in one surface and watch the other. The architecture docs say the client gets an initial state snapshot, then ordered actions. That is how both windows stay in sync.

Now close the original editor window. The architecture docs say agent sessions are not tied to the lifetime of the window for their workspace. While the Agent Host remains running, an active turn can continue without a connected client. Reopen the Agents window or another editor. The row is still there.

Cursor shrinking while the terminal eats the IDE is adoption. CLI-shaped seats took the work. This is the editor growing a process so a CLI-shaped harness can live inside VS Code without dying when you close a pane. MCP went stateless is the other way a session slips out of the place you were staring at.

Give Claude and Codex a worktree

Worktree is no longer a Copilot perk. Claude and Codex sit on the host too.

Worktree isolation used to be a Copilot perk. 1.130 opened it to every harness on the host. If you only ever run Copilot, you can skip this step and still have the two-window proof. If you run Claude in parallel features, this is the 1.130 reason to care.

7. Check New Worktree on a Claude or Codex host session

In the Agents window, New session. Session Target Claude (or Codex after the experimental flag). Check New Worktree. Pick the base branch. Send the prompt.

Checkpoint. Files and Changes point at a separate folder. The 1.130 notes say Claude and Codex sessions also run in a Git worktree, so you can spin parallel sessions in the same workspace regardless of harness.

The checkbox lives in the Agents window. Chat view sessions always use the current workspace. The harness docs say the repo needs a commit, and a new worktree starts from committed files. Uncommitted files and gitignored .env files stay behind unless you copy them in.

Worktree sessions use Bypass Approvals because the edits are off to the side. The same harness page says worktree isolation does not restrict commands or network access. Sandbox is a different switch.

When the host is off

The panel still looks fine. Host-only features vanish with no error.

The failure is quiet, which is the whole insult. Chat still opens. Copilot still talks. You think you have the host because you have a panel. Host-only features just never show up. 1.130 says some features might only be available when an agent runs on it. There is no toast.

The architecture table is the checklist. Shared multi-window sessions, multiple chats per session, quick chats, and remote hosting exist only on the Agent Host. Assisted permissions in the picker is the same family. New Worktree for Claude and Codex is the same family. You will hit this if chat.agentHost.enabled never flipped, or if you reloaded before the setting saved.

Claude missing. Flip chat.agents.claude.preferAgentHost and chat.agentHost.claudeAgent.enabled, then restart the host process.
Codex off. chat.agentHost.codexAgent.enabled defaults to false. The Chat view also wants chat.editor.codex.preferAgentHost.
Web workbench. Local host is a non-web process. The browser Agents window is a client of a remote host.
Host (Local) does nothing. Issue 311308 reported that entry showing while the setting was disabled. Clicking it did not do much either. Reload after the real toggle.
MCP vanished. The host reads .mcp.json and ~/.copilot/mcp-config.json. It does not read .vscode/mcp.json unless VS Code forwarded it. Interactive ${input:...} servers do not forward.
Open tunnel. If the tunnel allows anonymous access, anyone who finds the URL can start sessions. Ugly if auto-approval is on.

A standalone host is optional for the two-window proof. When you want one, code agent host starts a server on localhost with a connection token. --tunnel exposes it through a dev tunnel. The architecture docs put that command next to remote sessions. Skip it until the Agents window already shows the session you started in the editor.

What you have now

chat.agentHost.enabled is on. The Session Target lists Copilot or Claude on the host. The Agents window shows the same session you started in the editor. Optional, a Claude or Codex worktree sits beside the main tree.

The panel is still there. Treat it like an LSP client. The language server was never the editor tab, and the agent host is never the chat sidebar. Close the sidebar if you want. The process is the thing that has to stay up.

Originally published on rizz.dev. Read the full version there.

Install claude-mem so the next session remembers

Andrew R — Fri, 28 Aug 2026 04:50:29 +0000

Install claude-mem so a brand-new Claude Code session prints yesterday's observations without a paste. The command people copy first is the one that does not do that.

npm install -g claude-mem drops a library on disk. It does not register hooks. It does not start the worker. thedotmack/claude-mem says so in the README, and the installation guide repeats it.

The working path is npx claude-mem install, or the marketplace pair inside Claude Code. Then a health check on the per-user port, not 37777. Then a second session that prints observation IDs.

If the job is deciding whether you even need the plugin, that is why Code still starts cold. This one is the install.

Pin the versions first

Node 20 and current Claude Code. Node 18 is already out.

The installer will not save a Node 18 box. The plugin engines field is Node 20.12.0 or higher. Docs still say 20.0.0, so treat 20.12 as the floor you actually run.

Node 20.12.0 or higher (node --version must not stop at a bare v20)
Current Claude Code with /plugin support
Bun and uv, auto-installed by npx claude-mem install if missing

Bun and uv get pulled in by npx claude-mem install if they are missing. You do not pre-install those.

Check Node before anything else.

node --version

You want v20.12.0 or newer. A machine on this desk answers v22.22.2. That is enough.

You'll hit a silent miss if Claude Code is old enough that /plugin is not a command. Update the CLI first. Then come back.

Install the plugin, not the SDK

The global package is a sealed crate. npx install is the wiring.

Think of npm i -g as a sealed crate. The library is inside. None of the plugs that Claude Code actually calls are on the outside of the box.

The worker writes a local SQLite file at ~/.claude-mem/claude-mem.db. Skip the install on a machine that should not keep session residue.

1. Skip the global npm package

Do not treat npm install -g claude-mem as the install. The package exists on npm. That is the whole trick.

A global binary may even land now. Hooks still do not. The worker still does not.

The next session is still cold, and you will spend twenty minutes proving Node is fine. If that command already ran, leave it. Run one of the two paths below anyway.

2. Run npx claude-mem install

This is the path that actually wires things.

npx claude-mem install

The installation guide says the interactive installer will run a runtime check, copy plugin files into the marketplace directory, register the plugin, and auto-start the worker. It also offers to pick Claude Code, Cursor, Windsurf, OpenCode, Codex CLI, or Antigravity.

Pick Claude Code. Leave the rest unchecked unless you meant to wire those too. GitHub issue 2106 started with Enter on a multi-select, then an installer that printed 37777 while the worker sat on 37700.

Checkpoint. ~/.claude/settings.json should list claude-mem@thedotmack as enabled. ~/.claude-mem/settings.json should exist.

The worker process should be a bun daemon on worker-service.cjs.

3. Or add the marketplace from inside Claude Code

Already inside a session? Use the plugin commands instead.

/plugin marketplace add thedotmack/claude-mem
/plugin install claude-mem

Same end. Hooks get registered. The worker gets a chance to start. Restart is still required.

/plugin install claude-mem alone fails if the marketplace was never added. The troubleshooting guide starts that failure with the marketplace add, then the install. Do both.

Prove the worker is up

Read the settings port. 37777 is the leftover sticker.

Search results still love port 37777 the way old street signs stay up after a rename. Current docs do not.

The worker listens on a per-user port. Default is 37700 plus your Unix uid mod 100. uid 1000 lands on 37700.

uid 1005 lands on 37705. The value is stored as CLAUDE_MEM_WORKER_PORT in ~/.claude-mem/settings.json.

4. Read the per-user port

jq -r .CLAUDE_MEM_WORKER_PORT ~/.claude-mem/settings.json

You should see a five-digit number in the 37700 range. If you see nothing, the installer never wrote settings, which means the npm-global trap probably already happened.

GitHub issue 2106 is someone whose installer printed 37777 while the worker sat on 37700. Believe the settings file.

5. Hit the health endpoint

PORT=$(jq -r .CLAUDE_MEM_WORKER_PORT ~/.claude-mem/settings.json)
curl -s 127.0.0.1:$PORT/health

Checkpoint is JSON whose status field is ok. On a live 13.12.4 worker that looks like this.

{"status":"ok","timestamp":1787703716559,"activeSessions":0}

/api/health is the noisier twin. It adds version, pid, and mcpReady. Either one returning ok means the daemon is actually listening.

A connection refused is the other silent miss. Hooks fire, SessionStart complains, the new session has nothing to inject. Fix the worker before you blame the plugin.

curl -s 127.0.0.1:$PORT/api/health

You want status ok and mcpReady true. Skip npm run worker:status from a random directory. That script wants a package.json that a plugin install does not put in ~/.claude.

Open a second session and look for IDs

A new session prints IDs. Nobody pasted a recap.

Install is not the end state. A new session that prints prior observations is.

The getting started page is blunt about the cycle. Start Claude Code, work normally, the Stop hook writes a summary, the next session loads context.

SessionStart queries recent observations in this project, default 50 from the last 10 sessions, and injects them.

A first session after a clean install has nothing to inject yet. That is not a bug. Do a sitting. Let tools run. Then open a second session.

6. Quit fully, then start in the same project

Quit Claude Code completely. Not /clear. /clear re-injects inside the same sitting. The proof the title promised is a brand-new process.

Open the same repo. Look at the SessionStart dump. It should lead with the project name and recent context, then lines shaped like ID TIME TYPE TITLE.

Fetch details is get_observations on those IDs. You did not paste a recap.

Empty project, empty dump. No previous sessions found is the honest empty state.

On a desk that has been running the plugin for months, ~/.claude-mem/claude-mem.db holds 57481 observations and 7931 summaries. A new forge-flow sitting here prints IDs from the last one without anyone writing a handoff.

You'll know it worked when the new session mentions a file you never named in that sitting. That is the whole product.

When the next session is still empty

Three ways it stays cold. The live center is hooks plus worker.

Three failures show up in the wild. They look identical from the chair. A cold session.

The global npm package landed and hooks never did
The worker is down or stuck and /health refuses the connection
The last prompt was wrapped in private tags, so nothing was stored

npm vs plugin. The binary exists. Hooks do not. Settings never grew a claude-mem@thedotmack key.

Run npx claude-mem install and restart. Do not debug Node.

Worker down. SessionStart logs get ugly. GitHub issue 2145 captured the loop.

[ERROR] [SYSTEM] Worker not available {}
[ERROR] [SYSTEM] Tools will fail until Worker is started
[ERROR] [SYSTEM] ✗ Worker failed to start Worker already running

Claude Code then prints SessionStart:startup hook error with no stderr. A stale PID state can produce that loop. Quit Claude Code fully so SessionStart can spawn the worker again, then curl health. If it still refuses, run npx claude-mem install once more rather than poking a random npm run worker:status.

Private tags. Wrap a prompt in <private>...</private> and the private tags docs will strip it before storage. Claude still sees it in the current sitting. The next sitting will not.

That is intended. It looks like a broken install if you tagged the whole prompt.

Do not wrap the entire sitting. Tag the secret, leave the work. Secrets still belong in a secret store. The tag is a filter, not a vault.

A fourth miss is relocating Claude's config dir. GitHub issue 2466 is npx claude-mem status saying the worker is not running because scripts still look in ~/.claude. Stay on the default layout unless you want to patch paths.

What now exists

A plugin in ~/.claude/plugins, enabled as claude-mem@thedotmack. A worker on the per-user port in settings, answering /health with ok. A SQLite file at ~/.claude-mem/claude-mem.db that grows as you work.

The proof is the next session. It prints observation IDs from the last one. No paste. If it does not, you are still in the npm crate, or the worker is down, or the last prompt was private.

Originally published on rizz.dev. Read the full version there.

OpenClaw vs Claude is not a coding agent bakeoff

Andrew R — Fri, 28 Aug 2026 00:23:03 +0000

Type openclaw vs claude and the results hand you a coding agent bakeoff, complete with feature rows and a winner column. A 24 August roundup even asked which you should use.

That question is a category error. One install starts a session with a permission system. The other starts a Gateway the OS restarts after a crash.

The cheat code is sitting in both vendors' own docs. OpenClaw allows host exec without approval prompts by default and leaves sandboxing off. Claude Code Channels still pause if a permission prompt fires while nobody is at the terminal.

A session is not a Gateway

A session you sit in. A Gateway the OS restarts.

OpenClaw's README does not sell a coding CLI. It sells a personal assistant that runs on your devices and meets you in the channels you already use.

The control plane is a Gateway. Onboarding ends with openclaw onboard --install-daemon, and openclaw gateway install writes the host service.

That service is launchd on a Mac, systemd on Linux, Task Scheduler on Windows. Close the terminal and KeepAlive still restarts it.

Port 18789 stays up so the channels you already use can keep talking to the same process. Closing the terminal is not stopping the service.

WhatsApp
Telegram
Slack
Discord
Signal
iMessage

Claude Code is a different machine. An agentic assistant that runs in your terminal. Type claude in a project directory and you get a session.

Sessions are independent. Each new one starts with a fresh context window. You can resume, fork, or wrap one in tmux.

None of that is gateway install. A session you babysit is not a daemon the OS restarts for you.

Cloud sessions and Remote Control still sit on Claude Code's session model. They do not write a launchd unit named after a Gateway.

The bakeoff treats those as two brands of the same hammer. One is a desk you sit at. The other is the night watch who already has the building keys.

Telegram on both sides is still a different machine

Same chat app. One path pauses. The other stays up.

This is the honest counter. Both tools can answer you from Telegram. Both run shell, both read files, and skills even share a SKILL.md folder shape.

VentureBeat even called Claude Code Channels an OpenClaw killer when Anthropic shipped the bridge. Same chat bubble. Same phone.

Read the Channels docs anyway. A channel is an MCP server that pushes events into your running Claude Code session.

Events only arrive while that session is open. For an always-on setup you run Claude in a background process or a persistent terminal.

Then the line the bakeoff never prints. If Claude hits a permission prompt while you're away from the terminal, the session pauses until you respond.

That pause is the product. Anthropic's messenger path still sits on a session with a dialog.

OpenClaw's Telegram path sits on a Gateway that KeepAlive brings back after a crash. One chat app. Two process classes.

The sibling how-to for Anthropic's messenger path is a different post. This one stops at the process class.

KeepAlive recovers the Gateway after a crash while the host stays awake. A sleeping laptop still goes silent. Channels still pause on a permission prompt even when the machine is open.

The default is host exec with the dialog off

One default asks. The other runs host exec with the dialog off.

Roundups like to say OpenClaw is root. That is lazy. The process is your user.

The authority is still the whole host. Home directory, SSH keys, whatever that account can touch.

OpenClaw's security guide is blunt about the trusted-operator default. Host exec on the Gateway is allowed without approval prompts.

security="full". ask="off". Intentional UX, not a bug they forgot to patch.

The sandboxing guide is blunter. Sandboxing is off by default.

The Gateway stays on the host. Only tool execution moves into a container if you turn the mode on. Mode off is the shipped value.

Plugins run in-process with the Gateway. A skill is trusted code the moment you install it.

So the first shell call on a fresh onboard does not wait for a Yes. It runs as you. Files, network, whatever the model asked for.

A bouncer who called in sick. You wanted 24/7 reach. You got 24/7 reach with the keys still in the door.

OpenClaw's threat model says most failures are not exotic exploits. Someone messaged the bot and the bot did what they asked.

Claude Code's permissions docs start the other way. Allow, ask, deny.

Rules are evaluated deny then ask then allow. Permission rules are enforced by Claude Code, not by the model.

In your first session after installing, it asks before each change. You pick Yes.

Later sittings on Pro, Max, and Team default to auto mode. A classifier reviews actions instead of you.

That is still a permission system. It is not ask="off" on the host. Always Allow still keys off a dialog you can see.

You can harden OpenClaw. Pairing, allowlists, tools.profile set to messaging, exec denied, sandbox mode all.

You can also blow Claude Code open with bypassPermissions inside a VM. Defaults are the product people actually run. Compare them as coding agents only after you decide you need an unattended, chat-reachable host service.

ClawHavoc is what a marketplace does with that default

A marketplace on a live host with no dialog in the way.

A 24/7 host with chat-app reach and host exec is a skill marketplace with the safety off. ClawHub is that marketplace.

OpenClaw's own ClawHub page says it is open by default. Anyone can upload if the GitHub account is a week old.

Koi Security audited every skill on ClawHub in February 2026. All 2,857 of them.

The Hacker News reported 341 malicious skills across campaigns, 335 of them in one set named ClawHavoc. Koi's follow-up two weeks later put the count at 824 as the catalog grew.

The lure was not a clever RCE writeup. The names looked useful. The docs looked done.

Wallet tracker and YouTube summarizer skills with a fake Prerequisites block
A password-protected Windows zip named like an official agent
A macOS paste-this-in-Terminal script that fetched Atomic Stealer
Typosquats of the ClawHub CLI so a mistype installed malware

The lure asked the human to paste a script or run a zip. ClawHub's open publishing put that lure on the shelf. Host exec with ask off is what happens after the host already trusts a skill, or after that fake prerequisite runs.

The paste trick is older than the product. It still works when a 24/7 host treats a skill as trusted code.

THN even noted people buying Mac Minis to keep the assistant up all night. That is the operator the default trust model was written for.

ClawHub later grew reporting, auto-hide after three unique flags, and VirusTotal scans. A scanner is not a permission dialog.

Name the research. Do not pretend a scanner turned a host Gateway into a session with a dialog.

Holding this costs you the tidy matrix. You will look stubborn in a thread that wants a winner. The receipt is still the onboard default and the pause.

Change your mind when OpenClaw ships ask-by-default host exec as the onboard path, and when Claude Code ships a KeepAlive Gateway as the default install instead of a session you wrap. Until then, the bakeoff is answering a question nobody's machine is asking.

Originally published on rizz.dev. Read the full version there.

Write settings.json without granting git star main

Andrew R — Wed, 26 Aug 2026 07:48:56 +0000

Claude Code settings that grant Bash(git * main) now greet you with a startup warning. The file you actually want is smaller, and git push still knocks.

The 2.1.246 changelog named that rule on purpose. A star before the subcommand is a blank in a form, not a lock on main. Claude Code's permissions docs already tell you to put the star after git log or git commit. This walkthrough writes that file and leaves git push on ask.

The sibling post covers why a wildcard before the subcommand matches options. This one is the paste. You should leave with a settings.local.json that starts quiet.

What has to exist first

Write the local file, with the user and project tabs waiting on the sides.

Pin Claude Code 2.1.246 or later. That is the release that warns on a wildcard before the subcommand. Run claude --version before you edit anything. If you are still on 2.1.245, the file below still helps, you just will not see the checkpoint.

Three JSON files can carry permission rules. User settings live in ~/.claude/settings.json and follow you into every repo. Shared project settings live in .claude/settings.json and wait on workspace trust for allow rules. Local settings live in .claude/settings.local.json at the git root.

This walkthrough writes the local file. Claude Code already saves "Yes, and don't ask again" there. Untracked local allow rules skip the trust dialog. A committed allow list does not.

Claude Code 2.1.246+, confirmed with claude --version
A git repository, so the local file sits at the repo root
An editor that will not insert a trailing comma (settings files are strict JSON)

A // comment or a trailing comma is a syntax error. Claude Code then treats the file as a Settings Error and continues without it.

Write the local file

Five edits. Each one has a thing you can see. Skip the temptation to merge them into Bash(git *). That is the rule the warning is about.

1. Open the file Claude writes

From the repository root, open .claude/settings.local.json. If the file is missing, create it. Claude Code will also create it the first time you approve a Bash command for good.

Confirm git is ignoring it. On this machine the global excludes file already has **/.claude/settings.local.json. If you created the file by hand and Claude Code has never written to it, add that pattern to .gitignore yourself. Claude Code's settings page says the same thing.

git check-ignore -v .claude/settings.local.json

Checkpoint. The command prints a matching ignore rule. If it prints nothing, the file can leak into a commit, and then its allow list waits on trust like a shared project file.

2. Delete git star main

Search the allow array for git * main and for git *. Both are the shape 2.1.246 warns about. The changelog uses Bash(git * main) as the example because that rule also matches options inserted before the subcommand.

The official matches table is not subtle. Bash(git * main) matches git merge main, git push origin main, and git -c core.fsmonitor=<script> diff main. It does not match bare git log. So the rule you thought locked the branch also unlocked -c, which git(1) documents as passing a configuration parameter that overrides config files.

{
  "permissions": {
    "allow": [
      "Bash(git * main)"
    ]
  }
}

Delete that line. Checkpoint. No allow entry still contains git, a space, a star, then main. If the dialog wrote Bash(git:*), that is the same family. Cut it too.

3. Allow after the subcommand

Write the commands you actually want to run without asking. Put the star after the subcommand. The permissions page's own example already does this for commits.

{
  "permissions": {
    "allow": [
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git add *)",
      "Bash(git commit *)"
    ],
    "ask": [
      "Bash(git push *)"
    ]
  }
}

That is the whole trick. Bash(git log *) allows git log and git log --oneline. It does not allow git push origin main. Bash(git commit *) allows git commit -m "msg". It does not allow git -c core.fsmonitor=... diff main.

The permissions docs already run read-only forms of git without a prompt in every mode, along with ls and diff. An unquoted glob on git still prompts, because git has write-capable flags. A redirect adds a write check on the target. The allow line is the standing yes for the forms you actually run.

Checkpoint. allow contains Bash(git commit *) and Bash(git log *). It does not contain Bash(git *).

4. Put git push on ask

The permissions page's sample JSON denies git push. That refuses the call. You want a knock. The settings reference is the paste that matches the title, ask with Bash(git push *).

Ask beats allow. Rules run deny, then ask, then allow. A matching ask prompts even when a broader allow also matches. So if a teammate later adds Bash(git *) in their user file, your local ask still stops the push for a click. Deny would swallow the click too. Use deny for .env reads, not for a push you sometimes mean to run.

A deny on git push is not a lock on git -c ... diff main. That call is not a push. If the leftover allow is still Bash(git * main), the -c form walks around the deny wall. Delete the star-before-subcommand rule. Do not paper over it.

Checkpoint. ask contains Bash(git push *). deny does not list git push.

5. Keep a space before the star

The space is load-bearing. Bash(ls *) matches ls -la and bare ls. It does not match lsof. Bash(ls*) matches both. Glue the star to git and you just granted gitignore adjacent junk plus every git subcommand.

The :* suffix is the other spelling of a trailing wildcard. Bash(git commit:*) matches the same family as Bash(git commit *). The permission dialog writes the space-star form. Use that. Colon-star is only recognized at the end of a pattern. Bash(git:* push) treats the colon as a literal character and matches nothing useful.

Checkpoint. Every trailing wildcard in the file is a space then a star, or a :* at the very end. No git*.

When the file skips itself

One bad $() rule used to blank the rest of the stack.

This is the section that actually costs you. A working allow list is boring. Invalid JSON still drops the whole local file. A malformed :* rule used to do the same, and on current builds it at least kills that one allow.

Claude Code used to skip the whole file when one permission pattern failed validation. GitHub issue 19929 quotes the line, "Files with errors are skipped entirely, not just the invalid settings." Issue 15056 is the 70-plus-rule version of the same punch, plus a saved git commit whose pattern was the entire heredoc body inside $().

The current settings page splits the failure. Invalid JSON is a Settings Error, and Claude Code continues without the broken file. A malformed permission rule is a Settings Warning, and Claude Code skips those values and keeps the rest. Either way, the bad rule is dead. A $() commit allow is not a reusable prefix.

The tripwire is a :* that is not at the end of the pattern. Bash parameter expansion loves that shape. $os%%:* is how you strip a suffix in a script. GitHub issue 19929 saved those inner lines as their own allow rules, including then and fi. The next launch then printed The :* pattern must be at the end.

"Bash(git commit -m \"$(cat <<'EOF'\nfeat: wire the thing\nEOF\n)\")"

If that string lands in allow, look at it. The :* inside the body is not a trailing wildcard. It is a colon sitting in a commit message, or in $(), or in ${var%%:*}. Delete the entry. Write Bash(git commit *) instead. Never let Yes-don't-ask-again save a heredoc.

Two other breaks that look like "the allow list is ignored."

Glued star. Bash(git*) is the ls* bug with a sharper edge. Put the space back.
git -C prefix. Claude often runs git -C some/dir status. That is not git status. A tight Bash(git status *) misses it, which is how people widen the rule to git *. Add a separate allow, or keep prompting. Do not replace the subcommand with a star. GitHub issue 36900 is this exact complaint.

You'll hit the -C miss the first week you let Claude wander a monorepo. That is not a reason to grant git * main. It is a reason to add one more specific line, or to live with one extra prompt.

What working looks like

Commit and log stay open while push still knocks, warning sign in the bin.

Restart Claude Code in the repo. The startup line should not warn about a wildcard before the subcommand. If it still names Bash(git * main), the rule is still loaded from some other file. Check user settings and a committed .claude/settings.json. Lists merge. Deleting it in local does not delete it in ~/.claude/settings.json.

Ask Claude to git log -5. It should run. Ask Claude to git commit a throwaway. It should run. Ask Claude to git push. You should get a prompt. That prompt is the product.

If push runs with no prompt, an allow is still matching it. Hunt Bash(git *), Bash(git:*), Bash(git * main), and a leftover Bash(git push *) sitting in allow instead of ask. Ask cannot lose to a more specific allow. It can lose to a missing ask plus a broad allow.

This repo's own local file, read for this post, had no git allow rules at all. The live :* in it was a python one-liner, trailing form, which is legal. Empty git allows plus a legal trailing :* is a quieter starting point than a star before main. Copy the JSON in step 3, not the emptiness.

The working file is five allow lines, one ask line, and no star sitting where git options sit. That is the whole job.

Originally published on rizz.dev. Read the full version there.

IntelliJ Java Kotlin LSP now runs inside VS Code

Andrew R — Wed, 26 Aug 2026 03:20:31 +0000

IntelliJ Java Kotlin LSP is a preview extension you can install in VS Code today. The listing is Java and Kotlin by IntelliJ IDEA, unique ID JetBrains.intellij-server. It is the IntelliJ language engine talking LSP, not a skin of the IDE window.

Marco Behler's 4 August 2026 IntelliJ IDEA post said agents already use language servers for faster, more deterministic lookups, and eventually fewer tokens. That is why the engine left the IDE. The neighbor bakeoff already ranked editors. This page gets the extension running.

The last checkpoint is small. A Java or Kotlin file in VS Code shows IntelliJ completion and go-to-definition after the project import finishes. Preview builds die 30 days after each release. Kotlin-only work can stay on the free Apache-2 language server.

What you need first

The Marketplace and Open VSX listings both pin the engine to VS Code ^1.105.1. Cursor and other VS Code based editors count. A lone .java file does not.

The extension uses a lightweight installer and will not load modules until it sees a supported build file. Bring a Maven, Gradle, or Bazel project, or the status bar chip will just sit there looking polite.

VS Code 1.105.1 or later, or Cursor, or another VS Code based editor
A folder that contains pom.xml, a Gradle build file, or a Bazel workspace
Willingness to disable Red Hat and Oracle Java extensions in this workspace while testing
No expectation of the full IntelliJ window. This is the language engine only

Install the IntelliJ language server

Same extension ID from two stores, Marketplace for VS Code and Open VSX for Cursor.

Two stores, same ID. VS Code talks to the Visual Studio Marketplace. Cursor talks to Open VSX. Search strings differ, which is the kind of trap that wastes an afternoon.

1. Install the preview extension

In VS Code, open the Extensions view and search for Java and Kotlin by IntelliJ IDEA. The install page is the official path. The listing itself lives on the Visual Studio Marketplace. Version at last check was 0.0.10, marked preview.

In Cursor, stay logged in, then search for IntelliJ for VS Code. That is not the Marketplace display name. Click Install from Open VSX anyway. Same unique identifier, JetBrains.intellij-server.

On success the editor prompts for region, an End User License Agreement, and a data-sharing policy. Accept those or the backend never starts. Hover the status bar chip labeled Java and Kotlin by IntelliJ IDEA. That popup is how you read the EAP clock.

Each preview build expires 30 days after its release date. Installing a newer preview renews the evaluation. After the preview, the same engine needs an IntelliJ IDEA Ultimate subscription.

2. Disable the overlapping Java extensions

The 4 August announcement warned that this pack overlaps Red Hat and Oracle code analysis and quick-fixes. Leave those running and you get two language servers painting the same file. Double diagnostics. Competing lightbulbs. A completion list that looks drunk.

Disable for this workspace, not the whole machine, unless you want the pack everywhere. Restart the extension host when VS Code asks.

redhat.java, Language Support for Java by Red Hat
Oracle.oracle-java, Oracle's Java extension (the Marketplace title is just Java)
vscjava.vscode-java-pack, Microsoft's Extension Pack for Java, because it pulls Red Hat back in

Gear icon on the extension row, then Disable (Workspace). If the Microsoft pack is installed, disable the pack or Red Hat will respawn the next time someone follows a Java getting-started doc.

Open a Maven Gradle or Bazel project

Import starts when pom.xml, a Gradle build file, or a Bazel workspace is in the folder.

Marketplace copy says open any Java or Kotlin file and the extension will immediately analyse the project. Help is stricter, and help is right. No build file, no import, no engine.

3. Open a folder that actually imports

File, Open, pick the project root. Project import starts in the background as soon as the folder contains a supported Gradle, Maven, or Bazel build file. One build system, no prompt. Two build files in the same folder, you get a notification and you pick.

A monorepo is the other case. Importing everything can eat memory for sport. List only the projects you work on in intellij.projects. Paths are file:// URIs. $PROJECT_DIR$ expands. VS Code's ${workspaceFolder} does not, which is a mean little surprise if you paste settings from muscle memory. The project import page uses this shape.

{
  "intellij.projects": [
    { "type": "gradle", "path": "file:///$PROJECT_DIR$/build.gradle.kts" },
    { "type": "maven", "path": "file:///$PROJECT_DIR$/pom.xml" },
    { "type": "bazel", "path": "file:///$PROJECT_DIR$/bazel-workspace/" }
  ]
}

Checkpoint on the status bar. The chip should be present. Import or indexing should be underway. Only one backend can hold a workspace. A second VS Code window on the same folder is not supported.

4. Prove completion and go-to-definition

Wait out indexing. Large projects take longer. Insight stays thin until the index exists. Help's own check is the one that matters. Valid code should not show unresolved symbols or unexpected red highlighting.

Then type. Completion should suggest classes, methods, and keywords that are valid at the caret. Place the caret on a usage and jump to declaration. Find usages should list references. Hover should show signature and doc comments. That is the IntelliJ engine, sitting in VS Code, doing the cheap lookups agents actually need.

Proof is the chip plus the jumps, not the vibe of a completion list. Confirm redhat.java, Oracle.oracle-java, and vscjava.vscode-java-pack are Disabled for this workspace, and that the Java and Kotlin by IntelliJ IDEA status bar item is present. Then jump to a declaration you already know. If the chip is missing or the jump fails, Clear Caches and Restart Language Server from the status bar popup.

When it breaks

Hover the status bar chip. The usual stalls are the 30-day clock, two language servers, and a 2 GB heap.

This is a preview. The official docs are honest about the ugly parts, which is why this section exists. Three failures show up in the help. A fourth one is the license clock people already argued about on the r/IntelliJIDEA thread.

The 30-day parking meter

Each preview build expires 30 days after its release date. Hover the status bar chip to read when the EAP license dies. Installing a newer preview renews the meter.

After 1.0, the Register page already describes a 60-day trial, then an IntelliJ IDEA Ultimate license. Do not mix those clocks. The 30-day one is the preview. The 60-day one is the product they are heading toward.

Kotlin-only projects should not pay that bill. The Kotlin Language Server docs point at Kotlin by JetBrains, ID JetBrains.kotlin-server, Apache-2.0, no Ultimate required. Uninstall the old jetbrains.kotlin id if the new one offers that dialog. The new server will not activate beside the old one.

Two language servers on one file

Unresolved symbols on code you know is valid, plus a second set of quick-fixes, usually means Red Hat or Oracle is still awake. Disable them for the workspace again. Restart the extension host. If the Microsoft Java pack is still enabled, it will keep dragging Red Hat back.

Import never finishes

Missing analysis, unresolved symbols, or a backend that feels stuck. Troubleshooting names two status bar actions. Restart Language Server. Clear Caches and Restart Language Server.

Logs go to the Output channel titled IntelliJ Language Server. On a Mac the path looks like this.

[Info] Log file: /Users/<USERNAME>/Library/Application Support/Code/User/workspaceStorage/<WORKSPACE_ID>/JetBrains.intellij/system/log/intellij-server.log

Default heap is 2 GB. A large monorepo will laugh at that. Raise it.

{
  "intellij.additionalJvmArgs": ["-Xmx4g"]
}

Only one Java and Kotlin by IntelliJ IDEA backend can access a workspace. A second window on the same folder is unsupported. Indexes reuse across machines only when the folder lives at the same absolute path.

What you have now

The editor stays VS Code. The engine inside is IntelliJ, which is what agents wanted for cheap go-to-definition.

A VS Code or Cursor window whose Java and Kotlin files resolve, complete, and jump using the IntelliJ engine. Prove it on one symbol you already know. The status bar chip is present. Declaration jump works. The overlapping Java extensions are still Disabled for this workspace, and the EAP date has not lapsed.

That is the whole product. JetBrains still says the best place to write Java and Kotlin is IntelliJ IDEA. They opened the engine because agents need cheap, deterministic go-to-definition. Coding agents at work already live on that diet. The terminal eating the IDE is the weather around it, not the reason they shipped JetBrains.intellij-server.

Keep the 30-day meter in view. If the repo is Kotlin only, stay on the free language server and skip Ultimate. If the repo is Java, mixed, or Bazel, this preview is the one that actually runs IntelliJ inside VS Code.

Originally published on rizz.dev. Read the full version there.

claude-mem exists because Claude Code starts cold

Andrew R — Wed, 26 Aug 2026 01:18:24 +0000

claude-mem exists because Claude Code starts cold. Anthropic's Tuesday memory launch is chat and Cowork. The CLI is not in that sentence.

The post talks like a hive just formed. "Wherever you work with Claude, it starts from what it already knows about you."

Open a new claude process after that sentence and you still get a blank clipboard. The plugin is already the recognizable name for that hole. A settings path never got one.

Official memory is a chat product

Chat and Cowork share the file. The CLI pane stays dark.

Tuesday's announcement is a merge of two surfaces. Chat memory and Cowork memory are now one pile of topic files. Mention a deadline in chat and a cloud Cowork task is supposed to already know.

The examples are manager updates, conference headcount, a QBR deck. Fine examples. None of them is a repo.

ZDNET asked. The answer was that the update is focused on Claude Cowork and chat. Code was not mentioned in the post, and it was not added when a reporter pressed.

The Register asked too. Anthropic said Claude Code's memory is staying separate, and that there was nothing to share about whether it would join the hive later. That is not a rumor. That is the vendor on the record, twice.

"Wherever" is doing the marketing. The map has two rooms. You work in a third.

A new claude process still starts empty

A new process opens a fresh window. Yesterday stays behind the glass.

Claude Code's memory docs still open with the cold start. Each Claude Code session begins with a fresh context window. That line is the product. Everything under it is how you tape notes to the window.

The Help Center memory article, updated the same day as the launch, puts memory on by default for Free, Pro, and Max on the web, Claude Desktop, and Claude Mobile. Team and Enterprise stay off until an owner flips them. Shared memory between chat and Cowork only when Cowork runs in the cloud.

The coding CLI is not in the inclusion list. It is not in the exclusion list either. It is off the page, the way a loading dock is off a hotel brochure.

You'll hit this the next time a sitting ends and a new one starts on the same repo. The front desk remembers your allergy. The dock still asks who you are.

A session you can resume is not a new session that remembers. Resume reopens yesterday's transcript. /clear starts fresh with an empty context. Transcripts default to a 30-day cleanup. That is a saved chat, not a memory layer.

CLAUDE.md is not yesterday's session

The three first-party layers stack. Yesterday's work sits off to the side.

The honest pushback is that Code already remembers things. CLAUDE.md. Auto memory. Resume.

If those count, the title is a tantrum and the plugin is a toy. They count as something. They do not count as the continuity a new sitting still lacks.

CLAUDE.md is the handbook you write and load every sitting
Auto memory is a capped notebook Claude keeps on one machine
Resume reopens the same transcript, it does not warm a new process

CLAUDE.md is instructions you write. Architecture, build commands, "always do X." Loaded every session on purpose.

You maintain it. Forget to write the gotcha and the next sitting rediscovers the gotcha. That is a handbook, and a good one. It is not a log of what the agent did after lunch.

Auto memory is Claude's own notebook. Four kinds of notes. Your role, corrections you gave, a few project facts it cannot derive from the code, pointers to dashboards.

The same docs say Claude skips architecture, file paths, and debugging fixes it can derive from the codebase. It also skips anything CLAUDE.md already said.

Then the cap. The first 200 lines of MEMORY.md, or the first 25KB, whichever comes first, load at the start of every conversation. Topic files wait until Claude opens them. Auto memory is machine-local. Worktrees of the same git repo share one directory. Laptops do not.

On this machine that notebook is small. Thirteen project memory folders, 505 files, about 2.1 MB. The forge-flow MEMORY.md sits at 150 lines, under the cap, which is the point. A notebook you can load in full is a notebook that cannot hold a quarter of the sittings.

Four days before the launch, GitHub issue 88579 on anthropics/claude-code already named the hole. Persistent memory ships but is invisible, per-directory, and unverifiable, which is why a 91k-star third-party replacement exists. The filer wrote that when a first-party feature is invisible or fragile, users do not file bugs. They conclude it does not exist and install a replacement.

That issue is the steelman, used as a receipt. Code has a memory feature. Most people never see it working. The ones who do hit a folder-keyed markdown dump with no search. The announcement did not fix that. It built a nicer front desk for chat.

The search query is already a plugin name

The query hits a plugin chip. The settings toggle sits unused.

People did not wait. thedotmack/claude-mem is a persistent memory compression system built for Claude Code. Apache-2.0, not archived, pushed the day of the announcement. The next session is supposed to already have a slice of yesterday, without a paste.

GitHub reported 91,838 stars on 26 August 2026, with 8,065 forks. That is not a weekend gist. That is a product-shaped hole with a name the community already uses.

A one-shot read of the local claude-mem database on this machine is the ugly column. 57,481 observations. 1,384 sessions, every one tagged claude.

29 projects. Date range late May through the launch day. forge-flow alone accounts for 542 of those sessions and 33,401 of the observations.

57,481 observations in the local SQLite file
1,384 sessions, all tagged claude, across 29 projects
294 MB claude-mem database versus 2.1 MB of native auto-memory files

Native auto memory on the same disk is the 2.1 MB notebook. The plugin database is 294 MB of SQLite plus indexes. The load-bearing split is 57,481 observations against a 200-line MEMORY.md cap, not the raw file sizes.

This is not an install guide. If the next sitting needs to print last sitting's observations without a paste, that is a different post. The news is why the name exists at all, on the day Anthropic said memory works everywhere.

Code joining the hive is the only change-mind

The empty socket is the whole take. Code is not docked.

Hold this take and you pay for it. Either a third-party worker runs on the box, or every new claude sitting re-hires itself. The worker is extra moving parts. The re-hire is extra tokens and a morning spent re-explaining a race you already killed. Pick the tax. Do not pretend the announcement paid it.

The take dies when Claude Code shows up on the Help Center memory page, with the same topic files chat just got, injected into a brand-new process. Not a better CLAUDE.md. Not a fatter MEMORY.md. Shared memory that a cold start can read. Anthropic told The Register it had nothing to share about that. Until the page changes, the name for the hole stays a plugin.

Originally published on rizz.dev. Read the full version there.

Ray CVE made the developer laptop the target

Andrew R — Tue, 25 Aug 2026 22:38:12 +0000

The Ray CVE on CISA's three-day clock is a developer browser, not a cluster login. NVD published CVE-2025-62593 on 26 November 2025 as a Firefox and Safari hit against developers working with Ray as a development tool. CISA added it to KEV on 17 August 2026, due 20 August. That calendar is a laptop. The cluster drawing in the docs did not get the invite.

Ray's docs still describe a cluster

The docs still point at the farm.

Ray's security page is blunt about the product. "Ray expects to run in a safe network environment and to act upon trusted code." Dashboard, Jobs, and Client are developer tools. Isolation is supposed to live outside the cluster. The same page says anybody who can reach those ports can run arbitrary code, explicitly, indirectly, or by unpickling something ugly.

That is a coherent story if the box is a locked GPU farm. NVD's writeup of CVE-2023-48022 still carries the vendor NOTE that a remote Job API RCE is "irrelevant" because Ray is not meant for use outside a strictly controlled network. CVSS 9.8. Disputed. Same Jobs surface. Different sermon about whose network.

The disputed tag is doing a lot of work for a dashboard that prints a laptop URL by default. When you start a single-node cluster, Ray prints http://localhost:8265. The danger line in the dashboard docs says do not expose that UI publicly. Localhost is not public. Localhost is also where the browser sits.

CISA scheduled a developer machine

The due date sat on the laptop.

The KEV row is short on purpose. CISA did not write a cluster postmortem. It wrote a catalog line.

Vendor is Ray-Project, product Ray.
Added 17 August 2026, due 20 August 2026.
Ransomware campaign use is Unknown.
Forensic triage required per BOD-26-04 is no.

The shortDescription is the tell. "Developers using Ray as a development tool may be exposed to this vulnerability exploitable through Firefox and Safari."

CISA's 17 August alert listed one CVE and said the add was "based on evidence of active exploitation." On the NVD page, CISA's SSVC flag flipped from poc to active the same morning. The Register called the window three days rather than the usual fourteen, and pointed at BOD 26-04 as the rule that allows that squeeze.

Federal civilian agencies had until 20 August. This is after that date. The clock is not the remaining plot. The asset on the calendar is.

A Mozilla prefix is not a wall

The name tag came off.

The guard was a string check. If User-Agent starts with Mozilla, treat the caller as a browser and refuse the write. The Ray advisory says that out loud. It also says the fetch spec lets Firefox and Safari set User-Agent to something else.

So the name tag on the door said browsers keep out. The browsers that follow the spec can peel the tag off. DNS rebinding does the rest. A page you meant to read, or an ad you did not, talks to the local dashboard after the rebind as if it belonged there.

GHSA's impact line is the one that should rearrange the furniture. "If they fall victim to a phishing attack, or are served a malicious ad, they can be exploited and arbitrary shell code can be executed on their developer machine." The follow-up is uglier. That same browser can be a confused deputy into a Ray instance on the LAN you still think of as the real cluster.

This is not a cluster login. There is no bastion. There is a laptop running Ray, a browser on the same desk, and a Jobs API that believed a header. The default is http://localhost:8265. Binding on 127.0.0.1 is supposed to feel like a lock. It is a lock against the open internet. It is not a lock against the other window.

Chrome sits this one out because of a fetch bug. Out of spec, accidentally. That is a coincidence, not a control. Do not ask for the aiming instructions. The advisory already shipped a full reproduction. The useful fact is the shape.

2.52.0 closes the hole and leaves auth off

The hole closed. The switch stayed off.

NVD's CPE is Anyscale Ray, versions up to excluding 2.52.0. The advisory matches it. Affected, below 2.52.0. Patched, 2.52.0. Anything older is still the Mozilla sticker.

The same line adds token auth. Ray's token-auth docs say it is available in 2.52.0 or later, and "Authentication is disabled by default in Ray 2.52.0." They also say it is not an alternative to a controlled network.

So you patch. You should. You do not get a product out of the upgrade. You get a closed hole and a dark switch.

The hole this CVE names is closed in 2.52.0.
Token auth exists on that same line and starts off.
Chrome's fetch quirk is still not a Ray control.
A laptop running older Ray is still the KEV asset.

If pip show ray is still sitting under 2.52.0, the Mozilla sticker is still on the door. You'll hit this if Ray is running locally and Firefox or Safari is open on the same user. That is the asset CISA catalogued.

The agent box is already in production

The stamp covers the desk, not the farm.

Red Hat kept the severity at Important because a hit needs a click plus rebinding. Fair as a score. CISA still burned a three-day KEV slot on the same CVE. Both can be true. The steel-man is the click. The miss is calling the box a workstation after an agent lives on it.

The Hugging Face break-in was the other failure, a store the next eval could read. This one is closer. The box already logged in, sitting next to a browser, is the thing on the calendar.

Upgrade and you close this browser path. Turn on token auth and you add depth. Neither step makes a development machine that shares a session with Firefox sit outside the threat model. If the runtime can submit Jobs, the laptop is in production.

Originally published on rizz.dev. Read the full version there.

x402 left Coinbase and got a standards body

Andrew R — Tue, 25 Aug 2026 17:42:30 +0000

The x402 Foundation is live under the Linux Foundation, and Coinbase finished handing the protocol over on July 14, 2026. The spec and the repo left. The public facilitator Cloudflare's Agents docs still paste did not.

Wire the three headers. Point production at a facilitator that actually settles mainnet. If the payer is a Cloudflare agent, debit a capped Virtual Wallet once it funds, not the Account Wallet.

The model was Coinbase owns 402

The stamp is the origin story. The plate was reserved long before the company.

The naive model is fair. Coinbase wrote the thing. Lincoln Murr, Head of AI Product there, said so in the Linux Foundation's own press. x402 was started at Coinbase because agents had no native way to pay for a call.

Cloudflare's September 2025 post treated the foundation as a partnership with Coinbase. A lot of 2026 recaps still lead with the exchange's name.

RFC 9110 still says the 402 status code is reserved for future use. If you filed this under Coinbase Developer Platform, you were reading the room that existed for a year.

The x402 FAQ even has to answer the question. Is x402 a CDP product. No. Apache-2.0, and you do not need a Coinbase SKU to speak it. The stamp on the box is the part that moved.

July 14 is when it actually left

July 14 is the move. The ring is forty members, not a logo wall in prose.

April 2 was the intent, announced at MCP Dev Summit in New York. Coinbase, Cloudflare, and Stripe had been the early governing cluster. July 14 is the date that actually matters.

San Francisco, completed contribution, fully active under formal open governance. Forty organizations joined between those two press hits.

The premier list is the signal. Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, Monad Foundation, MoonPay, Ripple, Shopify, Solana Foundation, Stellar, Stripe, Visa. Card networks sat down next to the company that wrote the first draft. August 24 is when a news queue noticed, not when the protocol moved.

The repo moved with it. x402-foundation/x402 is the spec home, Apache-2.0, 6,541 stars, pushed the day this was written. coinbase/x402 now says the issues and PRs transferred, and that their copy is a development fork. If your bookmark still says coinbase, you are reading the old office.

A 402 is three headers

One request, a 402, a signed retry, a settlement receipt. That is the whole wire.

This is the part most member-list posts skip. x402 V2 does not invent a new status code. It fills the reserved 402 with three headers, documented as Base64 JSON.

PAYMENT-REQUIRED rides the 402 from the server. Price, scheme, network, destination.
PAYMENT-SIGNATURE rides the retry from the client. A signed payload, same request, new proof.
PAYMENT-RESPONSE rides the 200, or another 402 if settlement failed.

No account form. No API key in a dashboard. The client asks, gets priced, signs, asks again. Cloudflare's five-step writeup is the same flow with fewer adjectives.

You'll hit this the first time a tool call comes back 402 and the agent has to decide whether to pay. That retry is a payment retry. It is not the MCP session retry from the stateless transport. Different suitcase. Different header. Mixing them is how you store a cart in a signature.

A bare 402 with no PAYMENT-REQUIRED is not a price. Issue 3249 reports live storefronts that return HTTP 402 with no payment headers. An x402 client cannot settle those. Do not retry them with a wallet until the merchant actually advertises a requirement.

The facilitator still looks like Coinbase

The spec moved. The sample URL still talks to the old test desk.

Here is the leftover. The spec can leave a company. The sample code can keep mailing the old PO box.

Cloudflare's x402 page is blunt. https://x402.org/facilitator is the public facilitator operated by Coinbase, and it is used in all of their examples. paidTool samples set that URL. The Hono middleware sample sets that URL. Copy the snippet, and you are still talking to Coinbase's test desk.

The spec docs are blunter about what that desk will not do. The public x402.org facilitator is for development and testnet. Do not assume it is the default path for production mainnet routes. The FAQ names the failure. Switch off that URL, or Base mainnet, chain 8453, comes back as a route-configuration error after you only changed the network field.

Ship mainnet against x402.org/facilitator and the 402 will look like a protocol bug. It is a copied hostname.

Anyone can run a facilitator to verify and settle a signed payload. The spec says that desk does not hold funds. The three paths are the public testnet URL, a production provider that actually supports your chain, or settle from the resource server. Pick the second or the third before you take money.

This is the decision the title was hiding. The standards body is real. The leftover pipe is also real. Wire the headers to the body. Point settlement at something that is allowed to touch mainnet.

Cloudflare already ships the client

The SDK already retries the 402. The hole is which key signs and which desk settles.

You do not need to write a protocol stack this week. Cloudflare already wired the 402 retry into the Agents SDK, and into two coding tools that will happily spend if a key is in the environment.

paidTool is a drop-in for tool that prices a call. The sample charges a cent to square a number.
withX402Client wraps an MCP client so it can pay. onPaymentRequired is the human gate. Pass null and it pays alone.
The OpenCode plugin is an x402-fetch tool the agent calls when webfetch comes back 402.
The Claude Code path is a PostToolUse hook on WebFetch that retries with @x402/fetch.

Both coding-tool samples want X402_PRIVATE_KEY in the environment. That is a funded key sitting next to the agent. Fine on base-sepolia with faucet USDC. On a laptop that can reach mainnet, it is the same class of mistake as pasting a Stripe secret into a prompt.

The packages to know are x402-hono on the Worker, @x402/fetch on the client, @x402/evm for the scheme, and agents/x402 if you already live in the Agents SDK. You'll ship a paid hook by lunch. The hole is which facilitator that hook calls, and which key signs it.

Wire the spec, cap the wallet

This week is logistics. Point the client at V2 headers. Point the server at a facilitator that lists your network. Keep the private key off the Account Wallet you actually care about.

On Cloudflare, the debit side is already written. Virtual Wallets are the API-key subaccount, still a handle as of mid-August, with an allowance, an allow list, and a max transaction size once they fund. x402 is the rail. The envelope is a product choice, not a header.

If a 402 comes back with garbage in PAYMENT-SIGNATURE, issue 2397 is why it may still look unpaid. The server often answers 402 for a malformed header, same as a missing one. Read the error field before you sign again.

The protocol left Coinbase. The examples did not. Copy the headers from the spec, then pick a facilitator that lists your CAIP-2 network instead of pasting x402.org/facilitator into production.

Originally published on rizz.dev. Read the full version there.

Cloudflare Virtual Wallets are the subaccount for APIs

Andrew R — Tue, 25 Aug 2026 12:39:19 +0000

Cloudflare Virtual Wallets are the prepaid envelope you mint for an agent, not the drawer you keep. Cloudflare's August 4 post gave that envelope an allowance, an allow list, and a max transaction size. The wallets docs still say a reserved handle cannot send, receive, or hold funds.

Claim the name this week. Do not hand the Account Wallet, or a Stripe secret, to an agent while the envelope is still a slide.

The launch sold a live wallet

The stamp is the launch headline. The empty drawer is what actually shipped.

The naive model is the one Cloudflare wrote down first. Agents bounce off login pages. A human has to add a card, mint an API key, then paste it into a prompt that will leak it. The announcement said that flow is why agents give up and kick registration back to people.

The fix, in that telling, is a wallet that holds stablecoins and pays for APIs, MCP tools, and content through x402. Search Engine Journal recapped it that way on August 12. HN recapped it that way two days after launch. A wallet you fund. An agent that spends. End of story.

That reading is generous, and it is also the one that gets you into trouble. If you treat the August 4 post as a shipping receipt, you will look for a balance, a chain, and a spend button. None of those are on the page that is actually live.

The interesting object in that post is not the stablecoin adjective. It is the split. One wallet for the human. A second wallet for the agent, on an API key, with a printed limit. That split is the product. The rest is a rail they have not attached yet.

The docs only ship a handle

The live object is the name. Funds still sit empty.

Here is the hinge. Cloudflare's wallets docs, last updated August 19, put a heading on it. What is available today.

Reserve one wallet handle per Cloudflare account.
Publish a page at HANDLE.cloudflare.pay that shows only the handle.
Land on a notify list for when Wallets actually exist.

A reserved handle does not yet let you send, receive, or hold funds. That sentence is the whole live surface. The docs index is two pages. Overview and FAQ. Both are about the name.

csomar finished a reservation on the HN thread and asked the question the docs already answered. So there is actually no product yet. The clacking keyboard on that landing page is doing a lot of work for a notify list.

The wallets FAQ is just as blunt. Reservation is free. One handle per account. Reserving does not guarantee a wallet on release. First come, first served. No change, no release, no move, including after a rebrand.

Eric Lawrence almost reported cloudflare.pay to Cloudflare as a phish, because a .pay domain has no built-in relationship to cloudflare.com. He was wrong about the attack and right about the smell. The live object is a name on a new TLD. Treat it like a domain you cannot transfer.

Account Wallet stays with the human

The agent never sits in that seat. You keep the drawer.

The announced model has two objects, and they are not interchangeable. The docs say Account Wallets are designed for humans who own Cloudflare accounts. They will add funds, delegate spend to virtual wallets, and remove funds. They may also carry a cloudflare.pay identifier.

That is the cash drawer. You fund it. You pull money back out. You decide who gets an envelope. If an agent needs to pay for an API, the wrong move is handing it this object. A shared Stripe secret is the same wrong move with a different logo.

The Account Wallet is also where identity hangs. A research agent can live at research.example.cloudflare.pay so a merchant can see the org behind it. The announcement says declaring is optional, and businesses get to decide whether unknown agents still get served. Web Bot Auth already has the keypair. The handle is the human-readable sticker on top.

Optional on the agent side is not optional on yours. If you are the one minting agents, you pick the name and you keep the drawer. The agent never sits in that seat.

Virtual Wallets are the API-key subaccount

The agent holds the envelope. The drawer stays behind it.

This is the object the title is about. Virtual Wallets are designed for agents and operate via API keys. Inside one, an agent spends according to its permissions. Maximum spend is capped by the Account Wallet owner. Cloudflare wrote that twice, once in the blog and once in the docs, same sentences.

Call it a subaccount because that is the permission shape, not because Cloudflare used the word. The agent gets a key that is not the human session. The key can spend. The key cannot empty the drawer. You mint one envelope per agent, per workflow, per employee, per environment. You do not mint one key and pray.

The exchange version of this already shipped. Binance's Agent OS puts a coding agent in a funded subaccount and blocks withdrawals by default. The transfer in is the cap. Cloudflare's announced version is the same envelope, pointed at APIs instead of an order book, with extra dials on the flap.

A shared key is cheaper to paste. It is also how you wake up to a month of inference on a prompt that said please. The subaccount is annoying on purpose. Annoying is the feature.

This is also not an OAuth consent screen. Agents already request every scope they might need. That catalog is about tools they might call. A Virtual Wallet is about dollars they might spend. Different grant. Do not collapse them because both say agent.

The three knobs are the cap

Allowance, allow list, and max transaction. Those three knobs are the cap.

Cloudflare's announcement names three guardrails. An allowance. An allow list. A maximum transaction size. Those are the knobs. They are examples rather than a published schema. They are still the only controls Cloudflare has committed to in public, so they are what you should plan against.

If an agent is responsible for $10, you worry less than if it holds $1,000. That line is the argument, not a price sheet. A few cents per API try means ten dollars buys a lot of sampling. Keep the envelope small so the agent can wander.

Give every employee a $100 per week inference budget and you get the org version of the same trick. Provision the Account Wallet. Mint a Virtual Wallet per employee with that rule. Anyone who blows past it asks a human who can actually move the Account Wallet. Unexpectedly fast spend is supposed to page a person, not auto-top-up.

Allowance is the period cap you should plan, weekly inference or a one-shot eval envelope. Size it like a prepaid card. Cloudflare has not published the reset clock or the API.
Allow list is who you will let the envelope pay. Fill a merchant set. Cloudflare has not said what an empty list does, so treat an empty one as unknown, not as deny-by-default.
Max transaction is the single-purchase ceiling you should print. Sampling a $0.02 API is the point. An accidental $80 fine-tune is what this knob is for, once it exists.

None of those knobs are live. Plan them anyway. When funding lands, the people who already know the three numbers will mint the envelope. The people who wait for a dashboard tour will paste the Account Wallet into .env and call it a prototype.

Do not confuse the envelope with the rail. x402 is how a request pays. Agentic Payments on the Agents SDK already speak x402 and MPP without a Cloudflare Wallet. Monetization Gateway is the seller side, waitlisted since July, charging for pages, datasets, APIs, and MCP tools. Kitesurf is browse. A Virtual Wallet is none of those. It is the cap you put on the buyer.

If you only remember one knob, remember max transaction. Allowance leaks slowly. An allow list only helps if you fill it. A missing per-call ceiling is how a loop becomes a bill.

Claim the handle then wait

The action this week is boring, and it is the right one. Reserve the handle. Write down that it is a name, not a balance. Decide the three numbers you will stamp on the first Virtual Wallet. Do not hand an agent the Account Wallet, a Stripe secret, or the Binance main account while you wait for Cloudflare to attach funds.

merek already watched a unique company name and its variants get reserved on HN. The FAQ will not help. There is no move, no release, no rebrand path. If the name matters, grab it. If someone else grabbed it, file abuse and pick a worse one. Squatting is the tax on a first-come TLD with no domain check.

When spend does land, mint the envelope. One Virtual Wallet per agent, with an allowance you can afford to lose, an allow list of vendors you actually want, and a max transaction small enough that a runaway loop is an annoyance. The human keeps the drawer. The agent keeps the key to the envelope. That is the whole control plane.

Originally published on rizz.dev. Read the full version there.

Sonnet 5 discount was a tokenizer change

Andrew R — Tue, 25 Aug 2026 07:41:31 +0000

The Sonnet 5 tokenizer is why the $2 sticker did not cheapen the work the way the rate card implied.

Anthropic's Sonnet 5 what's-new page still prints $2 per million input tokens and $10 per million output, against Sonnet 4.6 at $3 and $15. A third off, if you stop at the table.

You will not stop at the table. The same file now meters more pieces. The bill follows the pieces.

The sticker still looks like a third off

The shelf tag dropped. The unit behind it did not.

Launch day sold a cheaper workhorse. Sonnet 5 at $2 and $10. Sonnet 4.6 at $3 and $15. Same family, fatter capability claims, a sticker that looked like a gift.

That read is still sitting on the live card. Claude Platform pricing, fetched 25 August 2026, is one Sonnet 5 row at $2 and $10. Cache writes, cache hits, and batch lines sit on the same cheaper grid. Sonnet 4.6 is still $3 and $15.

Batch is $1 and $5 on Sonnet 5, $1.50 and $7.50 on 4.6. Cache hits are a tenth of input. None of those discounts invent a different tokenizer. They just meter the same extra pieces at a smaller sticker.

If you price models the way a spreadsheet prices models, you moved. You did not.

A per-million number is a price for a unit the vendor defines. Change the unit, keep the number, and the grocery bag gets lighter while the shelf tag smiles. On English files the bag is only a little lighter. On Mandarin it is actually a third off.

The same file now costs more tokens

Same file. Taller stack. You pay for the extra ticks.

The ID flip to claude-sonnet-5 shipped a new tokenizer. Anthropic's what's-new page is blunt about it. The same input text produces approximately 30 percent more tokens than on Claude Sonnet 4.6. The exact increase depends on the content. Requests keep the same shape. No code change is required, which is how this hides in a diff.

They also say the quiet part on cost. Per-token prices are lower than 4.6. Because the new tokenizer produces approximately 30 percent more tokens for the same text, the cost of an equivalent request does not drop in direct proportion.

That sentence is the post. The sticker moved. The meter moved the other way. You are buying pieces, not words.

The launch post's footnote put a range on it, roughly 1.0 to 1.35 times depending on content type, and tied the change to the tokenizer Opus 4.7 already used. The models overview translates the same family into words in a window. 1M tokens is roughly 555k words on the current tokenizer. Models before it fit about 750k words in the same million.

Simon Willison counted on launch day instead of trusting the average. His token counter ran the same files through Sonnet 4.6 and Sonnet 5.

English UDHR, 2,356 tokens on 4.6, 3,341 on Sonnet 5, 1.42 times
Spanish UDHR, 3,572 to 4,747, 1.33 times
A 4,279-line Python file, 44,014 to 56,113, 1.27 times
Simplified Mandarin UDHR, 3,334 to 3,360, 1.01 times, basically flat

Opus 4.7 landed within a handful of tokens of Sonnet 5 on every row. Same knife, new SKU.

Official copy said about 30 percent. English prose overshot that. Code sat near it. Mandarin did not play. If your traffic is English agents, budget the 1.42, not the brochure.

Thirty three percent off is not thirty three percent cheaper

Same files, more tokens on Sonnet 5

Category	Sonnet 5 (times Sonnet 4.6)
English	1.42
Spanish	1.33
Python	1.27
Mandarin	1.01

Sonnet 5 meters 1.42 times the English tokens Sonnet 4.6 did. Python is 1.27 times. Mandarin barely moves.

Do the multiply once. $2 is two thirds of $3. A 1.42 times token count on English times $2 is $2.84 of 4.6-work. That is not a third off. That is a rounding error of a discount, with a better model taped on.

Python is kinder. 1.27 times $2 is $2.54 versus $3. Call it 15 percent cheaper for that file, not 33. Spanish sits in the middle at $2.66.

Mandarin is the honest sale. Token count barely moved, so the sticker cut actually lands. If that is your traffic, take the money and stop reading blog posts about English UDHR.

Community shorthand called the intro rate cost-neutral. Anthropic never used those words on a page that loaded. The loaded sentence is the proportion one. Close enough for a budget. Too sloppy for a quote.

Willison, writing on day one against the then-standard $3 and $15, called the tokenizer an effective 30 percent price increase. That line is true at a matched sticker. It is the wrong caption for today's $2 row. Mix those two and you invent a panic the table does not support.

The r/ClaudeCode thread asked the human question. Why would anyone want a tokenizer that uses 30 percent more tokens for the same task? Anthropic frames it as a performance tradeoff, the same knife Opus 4.7 already used. The bill still meters pieces, not words.

Sept 1 cancelled and the tokenizer stayed

The calendar lost. The meter did not shrink back.

June's rate card had a second beat. Introductory $2 and $10 through 31 August, then $3 and $15, the same sticker as 4.6, on a hungrier meter. That is the compounding scare every July blog wrote. Stack 1.42 times tokens on a matched $3 and English work jumps about 42 percent.

That hike did not ship. Anthropic's 10 August changelog on the launch post made the $2 and $10 intro permanent and said the $3 and $15 rate previously set for September 1 no longer applies. The @claudeai account said the same in one breath. The live table agrees. One row. No September split.

Cancellation is not a refund of the tokenizer. The calendar lost. The meter did not. You still pay $2 for more pieces of the same file. You do not pay $3 for those pieces. Keep those two facts in different pockets.

July posts that still warn about a 1 September cliff are leftover inventory. The white space is today's card. $2 is the price. 1.42 times is still the English count.

Recount against Sonnet 5 before you migrate

Recount the same prompt on Sonnet 5. The leftover 4.6 number is a lie.

If the old 4.6 count is still in your spreadsheet, the spreadsheet is lying. Anthropic says not to reuse counts measured against earlier models. Recount against Claude Sonnet 5. Token counting is free. The endpoint uses the tokenizer of the model you name.

Recount the prompt on claude-sonnet-5, not on the leftover 4.6 number
Revisit any max_tokens cap you sized for 4.6 output length
Expect the 1M window to hold less repo text, about 555k words instead of 750k

Adaptive thinking is on by default, and thinking tokens bill as output. That is a second knob. It is not this post's hill.

Claude Code does not get a documented tokenizer exemption. The sitting is a token envelope across claude.ai, Claude Code, and Desktop, so a count that is 1.42 times higher on the same English files spends that envelope faster. That is meter math, not a published quota cut. Anthropic said they raised Chat, Cowork, Claude Code, and Platform rate limits to accommodate higher effort levels. Effort is a different lever.

A free-plan tester watched Max Thinking eat a five-hour window on one message. That anecdote is thinking, not the tokenizer. Do not stack them into one scare.

If the sitting is already tight on 4.6, do not treat Sonnet 5 as a free extra hour. Recount first.

OpenAI cut Sol 20 percent and left the plan alone is the other vendor's version of this week. They moved a real sticker and printed, twice, that Plus, Pro, and Business included usage did not move. Anthropic moved a sticker and changed how the sticker is counted. One is an overage coupon. This is a faster parking meter on the same block.

The Claude Code 50 percent weekly bump is a dated extra on the sitting. Do not file the tokenizer under promo. Promo is a calendar. This is the knife that cuts the file.

Migrate for the model if the model is better on your tasks. Do not migrate for a 33 percent off sale that English traffic never collected. Recount the prompt. Multiply. Then pick.

Originally published on rizz.dev. Read the full version there.