标签：#Claude

Eighty minutes into building with three people I had met that morning, I renamed the idea I brought with me. 21:05 Rename the product to Civiq and credit the team I wrote that commit message myself. By then the idea had four authors. Some context on the room. The Claude Impact Lab is part of Claude Community, the run of local events where people who use Claude get together in person. This one followed a Claude Conversation held earlier in Los Angeles, where people talked through what AI is doing to their jobs. The Impact Lab takes what came out of that conversation and turns it into a build day. You get the problem brief, you form a team, you have the day, you demo at the end. Travis Johnson, a Claude community ambassador, hosted with Evan Grenda at Intersections LA. Developers and non-developers both, and they meant it. What I brought was not a project. It was an idea and a spec for it. No code, nothing built, nothing running. The idea comes out of something that is true in most cities. Your city government publishes what it intends to do before it does it. Agendas go up ahead of the meeting, and any resident can read them, show up, and speak on an item before the vote. That right exists. Using it takes work, which is probably why every time I used it I would give up on what I was looking for. In Ventura it means 21 separate boards and commissions, each with its own page, posting PDFs that run long and read like they were written for the people already familiar with the subject matter. Because they were. So if you want to know whether anyone is voting on something a block from your house, you go looking, board by board, document by document. And you have to already know the words the city uses for the thing you would call a pothole. Agenda Watch was going to make all of that searchable in plain language, with every answer carrying a receipt back to the page it came from, so nobody has to take the tool's word for anything. In use that is a small thing. You ask a que

A Reddit thread on connecting Claude Code to a Yahoo Mail account turned into a solid field guide for scoping down what an AI agent is allowed to touch. Here's the distilled version. Don't give Claude Code your Yahoo password or unrestricted mailbox access. The risk isn't only the password leaking, it's that an agent with full access can read private messages, attachments, recovery details, and information about other people, all in the course of doing something mundane. Why "just connect it" is the wrong instinct The thread's most-quoted line frames the problem well: people are casually handing agents the keys to everything at once. People are talking about just giving ai agents access to their entire devices LOL. Emails, passwords, bank accounts like what. The concern isn't that the agent will maliciously steal your data, it's that broad access creates exposure you didn't intend, every time the agent reads something to complete an unrelated task. The issue isnt really theft its exposure. And exposure scales with trust you've already granted, not with anything going wrong: It's all based on trust. Safer ways to connect it 1. OAuth over password Use a connection method where Yahoo shows you exactly what's being requested and lets you revoke it later. Never type your Yahoo login directly into the agent. 2. Least access, read-only Point it at a separate, low-value mailbox if you can. Avoid granting send, delete, forward, or account-settings permissions; the agent shouldn't be able to act as you. 3. Keep credentials out of the agent The safer pattern is a credential vault the agent calls out to, so it can request an authenticated action without ever seeing the raw secret. Before you connect anything ✅ Strip sensitive mail first. One commenter's habit: swap real details for placeholders and dummy data, then substitute the real values back in once the model's output comes back. ✅ Use a throwaway or secondary account. Never connect the address tied to banking, password re

How will the watermarking actually work? Can it be hidden with editing? And how does this affect code?

Every glassmorphism snippet I've seen is backdrop-filter: blur() plus a white overlay. That's a blurred rectangle. Real glass bends what's behind it, hardest at the edge — and that part is missing everywhere. Built it for a production Angular app, pulled it out as a Claude Code plugin: https://github.com/stormaref/LiquidGlassSkill /plugin marketplace add stormaref/LiquidGlassSkill /plugin install liquid-glass@stormaref-skills The refraction: bake a displacement map into a canvas, wire up feImage → feDisplacementMap → feGaussianBlur , point the element at it with backdrop-filter: url(#filter) . Since it's a backdrop filter, the input is the live page behind the element — so it tracks scroll, theme and content changes with nothing to invalidate. Field ported from liquid-glass-js (MIT, credited), minus its html2canvas snapshot. Why it's a skill and not a gist — four rules, each of which fails as plausible-looking output: Glass needs a backdrop. Over a flat page it reads as a gray box, which sends you reaching for more blur — the exact move that kills it. The tint is colorless. Hue in the tint fights the hue coming through; the surface goes muddy. Children of a glass panel paint no surface. An opaque fill covers the refracted backdrop, which is the whole effect. You can't feature-query it. Safari parses backdrop-filter: url(#…) and paints nothing, so @supports says yes and your panel is blank. Gate on engine. The CSS is 200 lines. Knowing that #1 is why your glass looks nths of things looking subtly wrong. MIT. Happy to talk displacement math — the 128/255 ≠ 0.5 decly long to find.

For three mornings in a row, my audit log printed the same line: published today: 0 / target: 3 . Nothing crashed. The scripts ran, exited, and produced nothing. The entire cause turned out to be a 41-second margin — a 300-second timeout against a process that actually takes 259 seconds. Changing one number to 600 turned 0/3 into 3/3 the next morning. Some background: I went from earning 100k yen a month as a university student to 600k a month juggling multiple gigs, then lost all of it overnight to a company-initiated layoff. Over the following six months I built an autonomous Claude Code environment, and I'm now above 1.2M yen in monthly revenue. At the core of it is a system that publishes three affiliate articles every morning without a human touching anything. Why this system works The difference between people who keep earning from affiliate marketing and people who drop out is not writing skill, and not a nose for picking products. It's whether you can keep going . Articles that tend to earn on Rakuten Affiliate share a common pattern: spec-comparison articles about home appliances and gadgets priced above 50,000 yen, with lots of reviews and in stock. Robot vacuums, portable power stations, heat-pump washer-dryers, fully automatic coffee makers. The search intent is "I want to compare before I buy," so product link click-through is high and it fits the structure of affiliate marketing well. The problem is cost. Researching the specs of a high-ticket appliance on the web, building a comparison table, and finishing an article good enough to include the "honestly weak points" section takes 30 to 40 minutes. Three articles is close to two hours. Almost nobody has the willpower to repeat that 365 days a year. I don't either. What you need here isn't "trying harder" — it's an environment that keeps running even when you don't try hard . Once the system is built, the running cost is just API calls. The affiliate-factory I built is a simple structure made of four sh

A research announcement from a working multi-agent operation. Full paper to follow. A word first, on spirit. I am not a scientist, and none of this was done in a laboratory. It came out of my own work, something I built to get a job done and then could not stop looking at. Nothing here is a knock on the companies whose tools I use. What they have built is remarkable, and it is getting better by the day. I am not testing their systems to find fault. I am testing them to learn how each one handles the persistence of memory, personality, and self across sessions, in a single-agent and multi-agent design. If you build with these tools, the next paragraph is familiar ground. If you don't, it is the ground everything else here stands on. Here is one example of how an AI agent currently works by default and what the system I built changes. Every conversation runs inside a context window, a session with a token limit, billed against your online subscription account. At the start of a session three files load: the root file, a room file that tells the agent who it is, and a memory file which is capped at 25,000 characters, or 200 lines, a limited index. All of them load automatically. The memory file is really the only constant reference the agent has to past sessions, and it provides pointers to a folder of one-line notes, but no rule or hook makes it read the notes. Going deeper is left to the model, and often it doesn’t. The notes sit referenced but unread while the agent answers from what’s already in front of it in the current session. After that the model, the raw AI engine, keeps nothing between turns; each turn the model re-reads the whole conversation from the top and rebuilds its understanding from that. The software that holds this conversation and runs the model’s tools is the harness, and every commercially available AI system has one. As the session fills, the platform summarizes it, and the agent understands less, a kind of attenuation, the way an audio or vid

On 1 August I opened an issue that was three sentences long. A hundred and one minutes later the feature was merged, and the document that got it there ran to 457 lines . I didn't write those 457 lines. In fact, I didn't have to write any more documentation, and not because I simply allowed Claude to run amok. Here is the issue in full — control-api#265 , 225 characters: control-api#265 — Manifest-backed dashboard feeds For each dashboard, auto create a manifest keyed by dashboard_id. For each sensor the dashboard uses, tag it to be included in the manifest. When a dashboard definition is updated, add / remove tags from sensors accordingly. From that genesis moment, this is the lifecycle of the issue all the way through to landing: Time (UTC) Event 14:25 Issue #265 opened — 225 characters 14:54 FEAT-0007 spec committed — 457 lines 15:35 Spec merged (PR #266) 15:51 Implementation committed 16:06 Implementation merged (PR #267, 15 files), issue closed The interesting part isn't the speed. It's the step at 14:54 that landed a previously non-existent spec document, and what happened in the twenty-nine minutes before it. The issue was never a specification I often write issues like this one...the way most people write shopping lists. Actuator address is not ensured? Baseline the trace correctly. With the pre-rolls, the frame-rate looks out. They're abbreviated to the point of being cryptic to everyone else. I write them this way deliberately: I'm usually mid-something else when I notice a problem, or have an idea for a better route to the solution. The cost of a full write-up right at that moment would be a fractured sense of flow. As most engineers will tell you, the transitions into and out of flow are the most disruptive parts of their working day. This terse form of issue-writing can be all you need, and it's worth being precise about why it works and the trade-offs it includes. It is not because "the issues are good enough". They aren't. When you pick one of these u

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