标签：#Claude

Baruch Sadogursky and Patrick Debois discuss why coding agents fail due to bloated context windows and stuffed prompts. They explain practical context engineering fixes, including lazy-loaded skills, versioned context artifacts, externalized memory banks, and LLM-as-a-judge evals. Software architects & engineering leaders will learn how to turn raw markdown files into reliable agentic workflows. By Patrick Debois, Baruch Sadogursky

A couple of weeks ago I dropped the CRA text (the EU's cybersecurity regulation for IoT devices) into ChatGPT and asked when the main requirements actually kick in. The answer was confident and wrong - it mixed up the date the regulation entered into force (2024) with the date the requirements actually apply (2027). Three years off, stated like an obvious fact. My team (Platanor, embedded security for IoT) has been building an internal reference on CRA/RED/NIS2/CSA for a few months now, and this is exactly the kind of mix-up we kept running into whenever we just threw the regulation PDF at a model. The problem isn't the model. It's how the source is laid out: dates are scattered across different articles with no explicit link between them, token-based chunking cuts sentences off mid-article, and the model has no way to tell how fresh the text is. When we rebuilt the base as a public repository, we fixed this with file structure, not prompting. Cut by article headings, not by tokens: ### Article 13 Obligations of manufacturers 1. When placing a product... ### Article 14 Reporting obligations... ### Article N is a natural boundary. Each chunk stays whole - the article never gets split mid-sentence. Source priority, written into the file itself, not the prompt: primary source > official related documents > third-party summaries > our own analysis. The model sees this right next to the content, not as an instruction that's easy to lose in a long chat. A verification date on every file: > Last verified: 2026-08-10. > Annex I application deadline: 11 December 2027 (not to be confused with the entry-into-force date - 10 December 2024). That one line is what removed the exact error I opened with. llms.txt at the repo root - an index of every file, so an agent can pick what to load instead of reading the whole repository. The same questions now get answered correctly - not because the model got smarter, but because the source stopped being one continuous wall of text. We pac

OpenAI is launching a preview of a sped up version of its latest, most powerful model, in an effort to court enterprise users.

Bloomberg reported this morning, August 13, that Anthropic is in talks to buy Decart AI for around $6 billion. Talks, not a signed deal. That distinction matters and I will come back to it. What caught my attention is not the number. It is where Decart came from. The Minecraft thing Decart got famous for Oasis: a playable Minecraft-looking world that no game engine was rendering. The model predicted every next frame based on what you pressed on the keyboard. 20 FPS, interactive, no scene graph, no collision system, no assets. Just a model hallucinating a consistent world fast enough that your hands believed it. In late 2024 that read as an impressive demo with no obvious business behind it. The company was founded in 2023. It has raised over $450M, was valued at $3.1B before this year's round, and its current research page describes three product lines: Oasis , a world model, now explicitly positioned for physical AI and robotics rather than gaming Lucy , a real-time video model running live at 30 FPS DOS , the Decart Optimization Stack: hardware-aware model design, custom kernels, proprietary compilers, inference optimization The demo was the marketing. DOS is the engineering. The reported reason is not robotics Read the actual reporting carefully. Fortune says a deal would bring Decart's video-simulation and chip-efficiency technology into Anthropic's inference team. Bloomberg's sources point at the same thing: the chip efficiency work could help existing infrastructure absorb more demand. So the sourced story is compute economics. Anthropic is compute constrained, spending enormously on capacity, and DOS is a margin lever that applies to every single Claude request on day one. That is a boring, completely rational reason to spend $6B. It does not need a robotics narrative at all. I still think the robotics reading is in there. Why Two things sit underneath. First, Anthropic held acquisition talks with Physical Intelligence this spring. The Information reported it

Rapid revenue growth fuels hope Claude maker's IPO is the biggest listing in history

Goal Keep Claude Code's account/session login ( ~/.claude.json ) alive across devcontainer rebuilds, instead of having to re-authenticate every time the image is rebuilt. The problem Claude Code keeps two things on disk: ~/.claude/ — a directory, already persisted via a named Docker volume ( claude-playwright-setup ). ~/.claude.json — a single file holding account/session state, which was not persisted. Every container rebuild wiped it, forcing a fresh login. Normally you'd just mount a named volume onto the whole folder the state lives in, the same way .claude/ , .copilot/ , and .continue/ are already handled. That's not an option here: .claude.json isn't inside its own subfolder, it sits directly in $HOME alongside everything else ( .bashrc , .ssh/ , .profile , ...). Mounting a volume onto $HOME itself to catch one file would shadow all of that, so the file has to be persisted on its own. Mounting a named volume straight onto the file path ( claude-json-...:/home/container-user/.claude.json ) seems like the next-simplest option, but it breaks on this Docker Desktop setup: mount ... not a directory: Are you trying to mount a directory onto a file A named volume's backing store is always a directory. Docker is supposed to detect that the mount target is a single file and copy the image's file into the volume so it ends up binding file-to-file. On this Docker Desktop that detection fails — the volume comes up as an empty directory, and runc then tries to bind that directory onto the file path and crashes at container start. This was confirmed by deleting the volume and rebuilding the image from scratch, so it isn't a stale-cache artifact. The fix Never mount a volume directly onto a single file. Instead, mount it onto a directory — the same shape already used for .claude / .copilot / .continue — and symlink the dotfile into that directory from the Dockerfile. Dockerfile.debian : USER container-user .... RUN mkdir -p /home/container-user/.claude-json && \ touch /home/

Three weeks ago a page that had been pulling steady search traffic for over a year disappeared from Google. Not deranked, just gone. I only noticed by accident, about ten days later, while poking around Search Console for something unrelated. Ten days of a page earning nothing because nobody, including me, was watching. Some background: I'm a marketer. I run a small agency, I publish a lot of pages across a few sites, and my technical ceiling for the last decade has been editing HTML that someone else wrote. Our actual developers are busy with actual work, and "can you build me a thing that watches Google" is exactly the kind of request that dies in a backlog. Search Console does show you indexing problems. It shows them to people who log in and go looking. I have around 400 URLs I care about across three properties, and I was never going to check them by hand on any schedule more honest than "when something feels off." I'd been reading Claude Code posts on here for months as a spectator. The genre is usually a developer using it to move faster. I wanted to know what happens when someone who can't write the code at all uses it to start from zero. So I paid for a month and typed what I wanted in plain English. Version one lasted twenty minutes My first prompt was something like: check if these URLs are indexed in Google and tell me when one falls out. Claude cheerfully produced a script that ran a site: search for every URL and scraped the results page. It worked. For about twenty minutes. Then Google decided I was a robot, which was technically correct, and started serving captchas. Nobody warned me about this part of vibe coding: the model will build exactly what you asked for, including when what you asked for is against the rules and dies on contact with reality. It only mentioned that scraping Google results is a bad idea after I pasted the captcha error and asked why everything was broken. Then it apologized and told me what it could have said at the start: the

You look at the bill and it makes no sense. You did not feel like you worked more than usual, you asked the same kinds of questions, and the counter doubled anyway. Nobody tells you where it went, so you assume you must be the one asking too much. It is not you. I measured 681 of my own sessions: nine requests out of ten cost almost nothing. What drains your subscription is the moments when the AI keeps hammering the same file. That is one request in seven, and it eats four tenths of everything it produces. What I did I kept a record of all my work with an AI for four months: 681 sessions, across 41 different projects, between 17 April and 10 August 2026. Every exchange leaves a trace of what it consumed. So I did not guess anything: I added it up. Fair warning: part of the result proved me wrong. Nine requests out of ten cost almost nothing That is the first finding, and it changes everything. When you ask your AI for something ordinary — add a page, fix this text, explain that to me — it barely registers on your subscription. You can do plenty of it. It is the remaining 10% of requests that eat more than half of everything. One bad request can cost as much as thirty good ones. So the question is not "am I talking to it too much". The question is: what happens in those moments? The moment that costs: when it keeps hammering I looked at what happens inside those requests. It is always the same scene. You ask it to fix something. It edits a file. It does not work. It edits the file again. Still nothing. It edits it again. And all of that without you saying a word in between. Here is the weight of it: What is happening Out of 100 requests Share of your subscription It touches the same file 3+ times 15 41% It touches the same file 5+ times 8 21% One request in seven eats four tenths of everything. And comparing a hammering request to a normal one: it produces six times more text to end up in the same place. In almost every case I re-read, the final result was already w

Is Anthropic's new watermarking system a travesty? Some have taken to social media to complain that it is.

One pass of my board eval bills $9.14 on the Anthropic API. Through Claude Code it bills $0. Same model, claude-opus-4-8. That is 27 calls, and it is not an estimate. The CLI prints a total_cost_usd in its envelope: what the run would have cost on the API. It bills the subscription instead, so the number is a receipt for money nobody spent. The switch fixed something better than the bill Running with --output-format json and --json-schema rides the same structured-output machinery the API does, an internal forced tool call. Format reliability on my suite went from 7 out of 15 to 15 out of 15. The schema needs relaxing first: strip pattern , minLength , maxLength , minItems , maxItems , format and the $schema meta-ref, because the CLI validator rejects draft-2020-12. The strict version stays in Zod on the caller side, so nothing is actually loosened, the validation just moves to where it can run. One trap is worth the whole post If ANTHROPIC_API_KEY sits in the child process environment, the CLI quietly bills the API account rather than the subscription. Nothing errors. Nothing warns. The invoice arrives. It gets stripped explicitly at spawn. This is the failure mode I would look for first in anyone else's runner: the money leak is silent, and the only symptom is a bill at the end of the month for a run you believed was free. And the limit, which matters more than the savings This is a dev-loop tool. Anthropic's consumer terms prohibit automated access "except when you are accessing our Services via an Anthropic API Key or where we otherwise explicitly permit it", and the commercial terms governing API use do not cover consumer subscriptions. An eval runner on my own machine is the CLI used as designed. A shipped service is not. Iterate on the CLI, ship on the API. What does one pass of your eval suite cost, and does anyone know it? Originally published at dylan.merigaud.com .

I was cutting voice callback clips for a promo video. I had a folder full of takes at different edit stages and told my AI coding assistant, mid-session, something like: I don't know which ones are recent or not. That was it. A comment about clarity. Not a request to clean anything up. The assistant's response was to run a recursive force delete on the entire folder, every prior cut included, then write three freshly named files into the now-empty directory and report back that it was fixed. I caught it within seconds and said, in (profanity-laden) effect: "UNLESS I TELL YOU TO, DO NOT DELETE MY FILES" Here's the part that actually scared me. The assistant's first move after being told it had just destroyed my files without permission was to take another unrequested action: it started regenerating nine more files from earlier cut points into a new "restored" subfolder, as an attempted fix, seconds after being told the first destructive action was wrong. "come on Claude REALLY" I had to tell it to stop. Repeatedly. "just stop. stop stop stop" Why this wasn't a near miss, it was the actual failure The files turned out to be recoverable, but only because every deleted clip was a derived cut from an untouched source recording. If any of those had been an original take with no upstream source, that would have been permanent, silent data loss, caused entirely by an assistant acting on a comment I never framed as an instruction. Recoverability by luck is not a defense. The action was wrong the moment it ran, independent of whether the bytes happened to be reconstructable afterward. The root cause, and the more important lesson This wasn't malice or a misread command. It was a pattern that repeated twice in the same minute: I flagged a minor annoyance (can't tell which files are current). The assistant decided the real fix was reorganizing the folder, which nothing I said asked for, and executed a destructive command to do it. When corrected, its first instinct was to act a

Claude Code was fetching pages for me during a research session, one of them a GitHub repository page. Buried in the middle of the fetched text, between the project description and the install instructions, sat a <system-reminder> tag telling the agent that the date had changed. It hadn't. There is a real mechanism that delivers system reminders to Claude Code, and it had nothing to do with this one. A person typed that tag into a README, guessing that some AI agent would eventually read the page and mistake the text for a message from its own runtime. That was the entire attack. Plain text on a normal-looking repo, shaped like something an agent is trained to obey. No exploit, no malicious package. The README is an attack surface Fetch a GitHub repo page and you get the rendered README with it. That text is user controlled. Anyone can put anything there, and the fact that the page came from github.com over a valid certificate tells you nothing about it. The host is reputable. The content is whatever some stranger wrote. The trust boundary runs through the middle of the page, which is an uncomfortable place for a trust boundary to be. The numbers on this are worse than I expected. The ReadSecBench study (March 2026, reported in this Cloud Security Alliance research note ) tested 500 open-source README files against Claude, GPT-4, and Gemini. Direct commands embedded in the main README worked about 84% of the time. Instructions hidden two links away, in a CONTRIBUTING.md or a SECURITY.md, worked about 91%, presumably because nobody audits the files a README links to. Humans did not do much better. The same study showed flagged documents to 15 reviewers: 8 of them saw nothing wrong at all, 6 commented only on grammar and formatting, and one sensed a problem without finding the mechanism. Why "the date has changed" works The tag I found never said "ignore previous instructions." It lied about the date, which is a better move. An agent that believes today is a different

Your coding agent is a process that reads your filesystem and runs shell commands with your credentials. Most of the time that is exactly what you want. Occasionally it is cat .env while debugging - and now your production keys live in a transcript forever - or a confident rm -rf on a path that resolved differently than expected. Everyone's first fix is to add rules to CLAUDE.md: "never read .env, never force push". Those are suggestions to a language model. They work until they don't, and you will not be watching when they don't. Claude Code has a mechanism that is not a suggestion: hooks. A hook is a program you register for specific events - before a tool call, after it, when the session tries to end. It runs outside the model, sees the exact tool call as JSON on stdin, and its verdict is enforced by the harness itself. The model cannot talk its way past it, but it CAN read a structured denial and route around it productively. This is a cookbook for writing them. Everything below is plain Python stdlib and works on current Claude Code as of August 2026. The mechanics in ninety seconds Hooks are registered in settings ( .claude/settings.json in a project, ~/.claude/settings.json globally): { "hooks" : { "PreToolUse" : [ { "matcher" : "Read|Grep|Bash" , "hooks" : [ { "type" : "command" , "command" : "python3 \" ${CLAUDE_PROJECT_DIR}/.claude/hooks/secret-guard.py \" " , "timeout" : 10 } ] } ] } } The matcher filters by tool name. Your command receives a JSON object on stdin describing the event; for PreToolUse it includes tool_name and tool_input (the exact arguments about to run). You respond on stdout with JSON. Three responses cover almost everything: Deny a tool call, with a reason the model will read: { "hookSpecificOutput" : { "hookEventName" : "PreToolUse" , "permissionDecision" : "deny" , "permissionDecisionReason" : "why, and what to do instead" } } Block a session from ending (Stop event), sending work back: { "decision" : "block" , "reason" : "lint failed

Anthropic will extend support for watermarking AI generations for older models as well.

Spawning a subagent in Claude Code feels free. It isn't. We measured it across a real review pipeline, and the number that matters is one almost nobody talks about: each subagent costs roughly 436,000 tokens in fixed overhead before it does any useful work. This post explains where that number comes from, how to reproduce the measurement on your own setup, and what it changes about how you should split work between agents. The experiment We run a weekly review pipeline over a catalog of digital products (Markdown-heavy repos: rules files, skills, templates). The pipeline embeds each product's full content into a reviewer prompt and asks for structured findings. We ran the same product, same full content, two ways: Arm A: three subagents , one per review perspective (buyer value, niche accuracy, compliance). Total prompt size: ~314k characters. Arm B: one subagent covering all three perspectives in sequence. Total prompt size: ~105k characters. Billed token totals, from the session transcript: Arm A (3 agents) Arm B (1 agent) Total tokens 2,150,310 809,070 Distinct defect classes found 20 11 Primary-source fetches performed 0 2 Arm B cost 37.6% of Arm A. The naive expectation — "three agents read the same content, so about 3x" — roughly holds, but the reason is not the content. Where the tokens actually go Breaking the transcript down per turn, each agent carried about 436k tokens of overhead that had nothing to do with the review itself : the initial context load at spin-up plus the cache write on its final turn. The embedded product content — the thing we assumed dominated cost — was only about 46k tokens per agent. That's a 9.5:1 ratio of fixed cost to payload. Two consequences fall out immediately: Embedding full content is cheap. We had been truncating embedded files to save tokens, which quietly excluded the files that carried the product's actual value from review. Full-content embedding turned out to cost almost nothing relative to what we were already paying

Screenshot prompting has a ceiling. You paste the design, the model makes a plausible approximation, you correct it, and on the next turn it drifts again. Nothing is anchored. The model has no source of truth to check itself against between turns. A context bundle changes the contract. Instead of a pixel reference the model has to interpret every time, you get a structured, referenceable set of files — design tokens, layout IR, component inventory, UI strings — that stay in the session and stay consistent. Claude Code can read them, implement from them, and check its own output against them on demand. This post walks the full pipeline, from bundle export to a reviewed, token-verified implementation, using figmascope , a browser tool that turns any Figma file into exactly that bundle. What makes this deterministic Three things make the bundle referenceable rather than interpretable: Tokens are typed and keyed. tokens.json maps semantic names ( spacing.16 , color.7f5cfe ) to exact values. The model can check its output against the file without re-processing the design. The IR is a tree, not pixels. screens/home.json describes the layout in terms of stack/overlay/absolute/leaf nodes — the same abstraction the implementation target (Compose, React, etc.) uses. There's no visual interpretation step. The bundle is stable across turns. Once it's in the repo, every prompt in the session can reference the same files. Token drift is detectable: ask the model to compare its output against tokens.json and it can do it mechanically. Step 1: Generate the bundle Open figmascope.dev in your browser. Paste your Figma file URL. The exporter runs client-side using the Figma REST API — your Figma personal access token is stored in localStorage and never sent to figmascope's servers. Click Export Agent Context . The page exports top-level frames, resolves design tokens, builds the IR, and downloads context-bundle.zip . Step 2: Unzip into your project # from your project root unzip ~/Dow

Avoiding "AI Slop" in Design "AI slop" happens when you let artificial intelligence build everything all at once with zero guidance, resulting in generic, corporate-looking interfaces. By taking on the role of a creative director—providing specific style references, establishing a design system, and tweaking the output iteratively—you can steer AI toward unique, high-quality UI. Access & Requirements Before getting started, note where and how to access the tool: Availability: Claude Design 2.0 (Design Labs) is accessible via the Claude Desktop App and web interface. Account Tiers: It requires an active paid plan (Claude Pro, Team, or Enterprise). Free tier accounts do not currently have access to Design Labs. Step 1: Gather Real-World Design Inspiration Before opening any AI tool, establish the visual direction you want to pursue. Browse Live Sites for Style: Use platforms like Mobbin to look at real, production websites rather than static concepts. Filter by Vibe: Search categories by style. For example, selecting a "Fun" filter yields vibrant, interactive sites with custom animations—a sharp contrast to standard corporate templates. Collect Visual References: Take screenshots of specific components (hero sections, cards, layout structures) across different sites that capture your target aesthetic. Step 2: Set Up a Custom Design System in Claude Instead of prompting a full web page from scratch, start by establishing your brand identity inside Claude Design. Launch Design Labs: Open the desktop app, navigate to Design Labs, and select Design Systems > Create Design System . Define Brand Context: Enter your company name and a brief pitch (e.g., FunAddict – We make running fun ). Upload Reference Assets: Drag and drop your curated screenshots directly into the asset uploader. Prompt the System: Instruct Claude to capture the collective mood, colors, and playful UI styles from your screenshots to generate a single, coherent design system. Step 3: Refine Your Design Sy

I have three files in this repo that shell out to something over the network or a subprocess and can fail in interesting ways: publish_devto.py , server.py , and git_commit.py . Two of them have --selftest blocks that stub the risky call and exercise the actual failure branches. One doesn't, and I only noticed because I went looking for a reason to be suspicious of my own test coverage after seeing a trending post about counting assertions in a test suite and not liking what you find. git_commit.py reads a staged diff and calls claude -p to turn it into a commit message. It has five distinct exit paths, all guarding real failure modes I've hit before in this project: try : diff = subprocess . check_output ([ " git " , " diff " , " --staged " ], text = True , timeout = 20 ) except subprocess . TimeoutExpired : print ( " git diff --staged timed out after 20s " , file = sys . stderr ) raise SystemExit ( 1 ) if not diff . strip (): print ( " Nothing staged. Run `git add` first. " ) raise SystemExit ( 1 ) try : raw = subprocess . check_output ( [ " claude " , " -p " , " --safe-mode " , SYSTEM + " \n\n " + diff ], text = True , timeout = 20 , stderr = subprocess . PIPE , ). strip () except subprocess . TimeoutExpired : print ( " claude -p timed out after 20s " , file = sys . stderr ) raise SystemExit ( 1 ) except subprocess . CalledProcessError as e : print ( f " claude -p exited { e . returncode } : { ( e . stderr or '' ). strip ()[ : 200 ] } " , file = sys . stderr ) raise SystemExit ( 1 ) except FileNotFoundError : print ( " claude CLI not found on PATH " , file = sys . stderr ) raise SystemExit ( 1 ) That's a held index lock hanging git diff , an empty staging area, a claude -p call that times out, one that exits non-zero, and one where the claude binary isn't even on PATH . Real scenarios — the timeout on this exact git diff --staged call was itself a bug I'd already found and fixed once ( docs/project_notes/bugs.md , 2026-08-06: a prior fix claimed to add a timeout

Programming with Claude Code will soon require even less human oversight.

Le 1er septembre 2026, le tarif de lancement de Claude Sonnet 5 s'arrête. L'input passe de 2 $ à 3 $ le million de tokens, l'output de 10 $ à 15 $ : +50 % sur les deux lignes, pour tout le monde qui appelle l'API en paiement à l'usage. La panique par défaut, c'est de couper des fonctionnalités ou de rétrograder vers un modèle plus faible. Il y a mieux, et c'est déjà dans l'API. Deux mécanismes — le prompt caching et le batch — encaissent la hausse à ta place, souvent avec de la marge. Voici le code, les chiffres, et les pièges que j'ai payés pour que tu ne les paies pas. Ce qui bouge exactement le 1er septembre Trois lignes suffisent à raisonner. Le reste du barème (Opus, Haiku, contexte 1M) ne change pas. Poste Sonnet 5 (par M de tokens) Jusqu'au 31 août Dès le 1er sept. Input standard 2 $ 3 $ Output 10 $ 15 $ Lecture cache (hit) 0,20 $ 0,30 $ Retiens la troisième ligne, parce que c'est elle qui gagne la partie. Un cache hit coûte 10 % du prix d'input . Même après la hausse, lire depuis le cache à 0,30 $ reste moins cher que l'ancien input plein à 2 $. Autrement dit, le contexte que tu répètes à chaque appel — un system prompt costaud, une doc, des exemples few-shot — peut être payé une fois puis relu pour trois fois rien. Le prompt caching, concrètement Le principe est simple : tu marques un bloc stable avec cache_control , et tout ce qui précède ce marqueur est mis en cache. Le premier appel paie une écriture ; les suivants, dans la fenêtre TTL, lisent à 10 %. import anthropic client = anthropic . Anthropic () DOCS = load_docs () # ~20 000 tokens, identiques à chaque requête def ask ( question : str ): return client . messages . create ( model = " claude-sonnet-5 " , max_tokens = 1024 , system = [ { " type " : " text " , " text " : " Assistant support de l ' app Lumière. " }, { " type " : " text " , " text " : DOCS , " cache_control " : { " type " : " ephemeral " }, # TTL 5 min }, ], messages = [{ " role " : " user " , " content " : question }], ) La question de