DEV Community: Solomon Neas

Anthropic Broke My OpenClaw Stack. GPT 5.4 Put It Back Together

Solomon Neas — Wed, 22 Apr 2026 20:24:00 +0000

If you quit OpenClaw after Anthropic pulled third-party harness support, I don't blame you.

That week was a mess. One day Claude was the center of the stack. Then Anthropic cut subscription coverage for third-party harnesses, Boris Cherny said some of the Claude CLI blocking looked like an overactive abuse classifier, Peter Steinberger tried to route around it, and OpenClaw still kept hitting the wall when the request looked too much like a harnessed system-prompt wrapper.¹²³

That is the part a lot of people missed. The problem was not just billing. The problem was that "Claude CLI is allowed" and "OpenClaw using Claude CLI works" turned out to be two different statements.

So I stopped trying to save the old stack.

I rebuilt it around GPT 5.4 as the orchestrator, Gemini for research, Claude only where first-party Anthropic paths still made sense, and a local-first retrieval layer that did not depend on vendor mood swings. It took more than a model swap. I had to fix crashing bootstrap injections, tighten routing rules until the agent stopped bullshitting itself, and treat memory and embeddings like infrastructure instead of a nice extra.

This post is the field report. If you think OpenClaw became unusable after the Anthropic mess, fair enough. If you think GPT 5.4 cannot anchor a serious OpenClaw setup, I have receipts.

The Week Anthropic Pulled the Rug

On April 3, Anthropic emailed subscribers to say that starting April 4 at 12 p.m. Pacific, Claude Pro and Max subscription limits would no longer cover third-party harnesses, with OpenClaw called out by name.⁴ Continuing to use Claude through those tools would require extra usage, billed separately from the subscription.⁵ Anthropic's rationale was blunt: subscription plans were not built for the call volume and usage patterns of agentic harnesses.⁶

That part was not rumor. It was confirmed in the customer email, picked up by TechCrunch, The Register, VentureBeat, and a dozen community threads full of people realizing their entire setup had just changed cost models overnight.⁵⁶⁷

At that point the obvious question was whether Claude Code CLI could still serve as a bridge. Peter found a workaround path that routed requests through the Claude CLI backend instead of the older OAuth-backed OpenClaw flow. For a minute, that looked like a real survival route. Then it became clear that "Claude CLI is allowed" and "OpenClaw using Claude CLI works" were not actually the same thing.²³

That distinction is the whole fight.

What Boris Said, and Why That Still Wasn't Enough

On April 6, Boris Cherny replied publicly that the blocking behavior did not look intentional and was "likely an overactive abuse classifier," and that Anthropic was looking into it while clarifying policy going forward.¹ If you were trying to keep OpenClaw alive on Claude, that sounded like hope.

Peter treated it like hope. So did a lot of users.

But the later public discussion makes the problem obvious. Peter said OpenClaw added Claude CLI support based on those assurances, only to find that Anthropic still blocked the setup in practice. His explanation is the clearest version of the current state: Claude CLI usage may be allowed in the abstract, but OpenClaw still appears to hit blocking when the request includes the sort of appended system prompt and harness context that marks it as OpenClaw-shaped traffic.²³

That is why this felt so maddening. Anthropic did not seem to be checking only the binary or the auth path. It looked more like they were classifying the behavior and the envelope. A plain claude -p call could appear fine. The same model, wrapped in OpenClaw's injected prompt layer, could trip a different outcome.

That is a very different kind of problem than a simple billing toggle.

Why I Stopped Treating Claude as the Center of the Stack

Once that sank in, the answer got ugly but obvious.

I stopped trying to make OpenClaw depend on Anthropic's goodwill.

Instead of centering the whole system on Claude and using other models as occasional helpers, I inverted it:

GPT 5.4 became the main orchestrator for planning, coding, structure, and conversation.
Gemini 3 Pro became the research and long-context lane.
Claude Opus stayed in the stack only through first-party Anthropic surfaces, where it was still worth using for architecture, review, and deep reasoning.
Local embeddings became mandatory infrastructure, not a nice-to-have.

That part matters more than people think. A lot of "OpenClaw is unusable now" complaints were really complaints about losing a cheap Claude substrate. Once that substrate went bad, the rest of the stack had no spine. GPT 5.4 gave the system a spine again.

Not because it was magical. Because it was stable, good at orchestration, and available on terms that did not collapse the minute Anthropic changed its classifier.

The Ugly OpenClaw Reality That Skeptics Were Right About

The skeptics were not wrong about the rough edges.

The week after the Anthropic cutoff, OpenClaw could absolutely feel cursed. I saw runs that posted "working" notifications for twenty-plus minutes and then stalled. I saw hollow filler replies instead of actual task progress. I saw backend glitches pile on top of billing chaos. And I saw enough papercuts around PDFs and update behavior that a normal user would have been justified in walking away.

That is not me hedging. That is me giving the critics their due.

There were at least two categories of problems happening at once:

External instability: Anthropic changed the economics and kept the technical boundaries vague.
Internal OpenClaw fragility: some core workflows still had rough implementation edges right when users needed confidence most.

If all you saw was that surface layer, OpenClaw looked broken and overcomplicated.

The trick was surviving long enough to harden the inside.

The First Big Fix: Local-First Enforcement Had to Stop Crashing the Gateway

One of the most important fixes I made predated the April blowup, but it became much more important after it.

I had a local-first enforcement hook that injected routing rules at bootstrap. The idea was straightforward: force the stack to check local systems and cheap retrieval paths before burning third-party tokens. In practice, the first version crashed the gateway on every message.

The root cause was stupid and surgical.

My hook was pushing malformed bootstrap file objects. OpenClaw's bootstrap pipeline expected a workspace file object with the shape:

{ name, path, content, missing }

The broken hook was effectively sending the wrong keys, which meant path was undefined. Somewhere inside the bundled runtime, OpenClaw did a file.path.replace(...) call. Since path was missing, the gateway face-planted before the agent could even reply.

The fix was to stop guessing and match the actual expected shape exactly:

event.context.bootstrapFiles.push({
  name: "LOCAL_FIRST_RULES.md" as any,
  path: `${event.context.workspaceDir}/LOCAL_FIRST_RULES.md`,
  content: RULES_CONTENT,
  missing: false,
});

That one fix took the system from "broken before every reply" to "capable of receiving routing constraints at startup." It also taught the most annoying lesson of the whole month: a lot of agent reliability work is not model work. It is object shape, lifecycle timing, and boring plumbing.

The Second Big Fix: Prompt Rules Only Work When They Are Concrete and Mean

After the crash fix, I still had a behavior problem.

The agent knew it should prefer local systems first, but "should" is not enforcement. Vague rules got ignored. Gentle guidance got rationalized away. Anything that felt like judgment instead of a hard edge leaked.

So I rewrote the routing rules until they behaved like guardrails instead of wishes.

The final structure was basically this:

Pre-flight check first
Code Search API before grepping repos
Prompt Library before drafting prompts from scratch
Agent Intel before answering knowledge questions
Delegate file-scanning tasks instead of doing them directly in the expensive orchestrator lane
Hard violations for common shortcuts

The part that finally worked was not abstract policy. It was specifics.

For example, coder delegation did not start sticking until I added:

explicit command blocklists for grep, find, cat, head, tail, sed, awk, and friends
examples of the exact rationalizations I wanted to kill
direct language that said "no, even if it would be faster"
cost framing tied to me personally paying for wasted calls

That last part sounds petty, but it worked. Models respond better when the rule cashes out into a human consequence.

The Third Big Fix: Split the Work Across Strict Agent Lanes

This was the real system redesign.

I stopped pretending one general-purpose agent should do everything well and cheaply.

Instead, I ran OpenClaw with strict lanes:

Lane 1: GPT 5.4 as the orchestrator

This is the lane that made the whole thing survivable.

GPT 5.4 handled:

planning
orchestration
coding direction
multi-step reasoning
structured drafting
deciding which lane should do what

This turned out to be the right use of it. Not as a gimmick. Not as a pure chatbot. As the traffic cop and field commander.

Lane 2: Parallel research lanes instead of one research monoculture

I stopped treating research like a single-provider job.

Gemini 3 Pro handled the giant-context and multimodal work:

long source packs
vision work
large-doc sweeps
broad comparison passes

Perplexity handled sourced current-event sweeps and fast citation gathering.

Claude Opus handled the tighter synthesis pass when I wanted a second serious read on architecture, tradeoffs, or whether a conclusion actually held up.

Running those lanes in parallel was better than pretending one model should be researcher, fact-checker, and synthesizer all at once.

That also kept GPT 5.4 from being used like an overpriced research scraper.

Lane 3: Native harnesses for serious building

For serious builds, I stopped pretending the generic orchestrator lane should do all the heavy lifting itself.

I used native coding harnesses where they were strongest:

Codex CLI for build-heavy coding work in its own native loop
Claude Code when I wanted Anthropic's first-party harness behavior and tool loop
OpenClaw as the orchestrator that decides when those lanes should take over

This part matters because harness engineering changes outcomes. Public 2026 benchmark writeups put GPT-5.4-Codex at 56.8% on SWE-bench Pro, while Anthropic's later Opus line was reported at 64.3% on the same benchmark family in a first-party-style coding setup.⁸⁹ Separate harness comparisons also make the bigger point: the same base model can move a lot depending on which harness is driving it, which is why I care less about leaderboard chest-thumping and more about using the model in the environment where it actually behaves best.¹⁰

There was also a policy boundary here. Anthropic's published position was that subscriber OAuth access was reserved for Claude Code and Claude.ai, while third-party harnesses needed API-key access or explicit permission.¹¹ So even when Opus looked better in a given harness, the practical Anthropic-safe path was Claude Code, not trying to smuggle subscriber OAuth back through OpenClaw.

That is why Claude stayed in the stack, but not at the center of it.

That was the emotional adjustment some people never made. They were still trying to get back to the old world. I was building for the new one.

The Quiet Hero: Local Embeddings and Memory Cards

The part I trust most in this stack is not the fanciest model. It is the memory system.

A lot of agent setups fail because they rely on fresh-session vibes and giant transcript sludge. When the vendor changes behavior, the whole thing turns into a goldfish with tools.

I wanted something closer to a compact operating memory:

a slim MEMORY.md as the index
atomic knowledge cards in memory/cards/*.md
daily raw logs in memory/YYYY-MM-DD.md
semantic search across all of it
local embeddings first

For embeddings, I run qwen3-embedding:8b locally through Ollama for memory search and code retrieval. That matters for three reasons.

First, it is cheap. Second, it is private. Third, it removes one more dependency on third-party token economics for the boring but essential retrieval layer.

This is the part that reminds me most of the better agent-memory systems people keep circling around lately. Keep the hot context small. Keep durable knowledge chunked. Search first, load second. Do not dump a 60 KB memory blob into every session and pray.

That change alone made the stack feel less brittle.

The Missing Glue: Handoff Notes Between Codex, Claude Code, and OpenClaw

One thing I also borrowed from the gbrain and gstack style of thinking was this: the useful part is not just having multiple agents. It is having a clean handoff surface between them.

That is where a lot of multi-model setups quietly fall apart. Codex figures something out. Claude Code discovers a root cause. OpenClaw finishes the task. Then the lesson dies in whichever terminal happened to learn it.

I got sick of that.

So I added a Memory Handoff workflow for Claude Code and the other coding lanes. When a session produces something durable, it is supposed to emit a short structured handoff instead of burying the answer in chat exhaust. The format is dead simple: what happened, why it matters, the durable facts, the evidence, and where the knowledge should land next.

That matters because I do not want three competing memory systems.

Codex and Claude Code can keep local session context
OpenClaw on Rocinante is the canonical long-term memory
handoffs are the bridge

In practice that means architecture decisions, weird bug roots, workflow changes, setup gotchas, and user preferences get written as small transfer documents in .claude/memory-handoffs/. From there, Rocinante can route them into memory/cards/, TOOLS.md, USER.md, rules/, or .learnings/ depending on what the fact actually is.

That sounds boring. Good. Boring is what you want from memory plumbing.

The important part is that it kills the old handoff-letter problem. I am not pasting giant end-of-session summaries back into a fresh model anymore. I am pushing small, structured notes across lanes so Codex, Claude Code, and OpenClaw stop relearning the same lesson like idiots.

The Ingestion Layer: n8n as the Information Bus

The other piece people should know about is n8n.

I do not just use n8n for social posting. It has turned into the information bus for the stack.

On my setup, n8n already owns a bunch of glue work that would otherwise become brittle shell scripts and forgotten cron notes: blog publishing, cross-post fan-out, draft queues, webhook-driven publishing, and audit logging. Once that was in place, it made sense to treat it as part of the agent infrastructure too.

So the stack is not just model routing plus memory cards. It is also ingestion.

webhooks for one-shot publish and routing events
scheduled jobs for polling, dedupe, and follow-up work
workflow state for draft queues and publish history
audit trails that can be shipped into Wazuh

That matters because good agent systems are really data-movement systems in disguise. The model is only one layer. The rest is capture, routing, storage, and retrieval.

In my case, n8n handles a lot of the "something happened, now move it where it belongs" work. A blog draft can become a canonical post, then a cross-post job, then a social preview queue, then a record in the broader content pipeline. A Claude Code memory handoff can get ingested on schedule so durable knowledge does not stay trapped in a repo-local folder. Different jobs. Same philosophy.

That is the part I think more OpenClaw users should steal. Not my exact stack. The pattern.

Use the orchestrator for judgment. Use specialist lanes for depth. Use structured handoffs so context survives model boundaries. Use an automation layer like n8n so the system keeps moving even when no one is staring at the terminal.

The Bugs That Made the Trench Story Real

There were also smaller but very real wounds.

PDF handling

OpenClaw had document handling gaps and PDF weirdness bad enough that it became one of the receipts I kept for public criticism. The public issue for automatic inbound PDF text extraction was already there, and I later tracked the related fix work around standardFontDataUrl because broken document ingestion does not just look sloppy, it kills trust in the agent's ability to work with real inputs.¹²

Systemd update behavior

Another nasty one was update behavior that could silently strip user-added environment directives when regenerating the managed systemd unit. There is a public issue for that too, and it is the kind of bug that makes people think the product is haunted because their setup breaks after a successful update.¹³

The meta-problem

Those bugs matter beyond their own scope. They compound. If billing is unstable, prompt behavior is unstable, and upgrades silently stomp local directives, people stop giving the tool the benefit of the doubt.

That is why the fix story matters. Reliability is not one grand heroic patch. It is a pile of ugly little wins that stop the system from bleeding out.

What I Would Say to OpenClaw Quitters

If you quit because Anthropic killed the old Claude subscription path, I think your frustration was fair.

If you quit because OpenClaw felt too fragile during that transition, that was fair too.

But if you are writing off OpenClaw entirely, I think you are throwing away the wrong part.

The wrong part was depending on Anthropic as the unquestioned center of the stack.

The useful part is still here:

multi-lane orchestration
agent-specific routing
background work
channel integration
local-first retrieval
structured memory
tool access

That combination is still powerful.

The post-Anthropic version of OpenClaw just needs a different default architecture:

GPT 5.4 as the main orchestrator, with Codex CLI for native build-heavy coding work
parallel research lanes across Gemini, Perplexity, and Opus
Claude only through first-party lanes like Claude Code or direct API usage
local embeddings for retrieval
strict routing rules
bootstrap-level prompt injection defenses

That is not a consolation prize. It is a more grown-up design.

The Proof I Wanted for the Skeptics

The reason I am writing this at all is simple.

I wanted receipts.

Not "trust me bro, I made it work." Not a tweet thread with the edges sanded off. Real receipts. Real failure modes. Real fixes. Real architecture changes.

If I answer somebody on X about OpenClaw after the Anthropic mess, I want to point to a field report that says:

yes, the Anthropic cutoff was real
yes, the Claude CLI classifier mess was real
yes, OpenClaw had enough rough edges to make people quit
and yes, I still made GPT 5.4 work as the orchestrator anyway

That last part is the point.

Not that GPT 5.4 solved every problem. It did not. Not that Anthropic stopped mattering. They still matter. The point is that once the stack stopped assuming Claude had to be the center of the universe, OpenClaw became usable again.

That is a very different claim from "everything is fine."

Everything was not fine.

It was a trench story. Then it became a system.

The Bottom Line

Anthropic did pull the rug on third-party subscription harnessing.⁴⁵⁶ Boris did publicly say some of the Claude CLI blocking looked like a bug or overactive classifier and that it was being addressed.¹ Peter did try to build around that guidance, and then said OpenClaw still hit blocks in practice because the harness behavior itself appeared to trigger Anthropic's defenses.²³

That left OpenClaw users in a miserable spot: shaky policy, inconsistent runtime behavior, and a lot of reasons to distrust the stack.

My answer was not to pretend that away. My answer was to redesign the stack around reality.

That is what this whole post comes down to.

I did not save OpenClaw by finding a new Claude loophole. I saved my OpenClaw workflow by making Claude optional, making GPT 5.4 the orchestrator, making retrieval local-first, and making the routing rules strict enough that the system stopped lying to itself.

That is the version of OpenClaw I still believe in.

Originally published at solomonneas.dev/blog/openclaw-after-anthropic-how-i-made-gpt-54-work. Licensed under CC BY-NC-ND 4.0 - attribution required, no commercial use, no derivatives.

Boris Cherny (@bcherny), "@steipete This is not intentional, likely an overactive abuse classifier. Looking, and working on clarifying the policy going forward," X, April 6, 2026, https://x.com/bcherny/status/2041035127430754686. ↩
Peter Steinberger (@steipete), "Since this is blowing up on hacker news. Boris said that CLI usage is allowed. Thus we added support for it, only to find out that we are still blocked there...," X, April 21, 2026, https://x.com/steipete/status/2046685973233189375. ↩
"Anthropic says OpenClaw-style Claude CLI usage is allowed again," Hacker News, accessed April 22, 2026, https://news.ycombinator.com/item?id=47844269. ↩
Anthropic third-party harness cutoff timeline captured in the author's OpenClaw operating logs, April 3 to April 4, 2026. ↩
Anthony Ha, "Anthropic Says Claude Code Subscribers Will Need to Pay Extra for OpenClaw Usage," TechCrunch, April 4, 2026, https://techcrunch.com/2026/04/04/anthropic-says-claude-code-subscribers-will-need-to-pay-extra-for-openclaw-support/. ↩
Thomas Claburn, "Anthropic Closes Door on Subscription Use of OpenClaw," The Register, April 6, 2026, https://www.theregister.com/2026/04/06/anthropic_closes_door_on_subscription/. ↩
Carl Franzen, "Anthropic Cuts Off the Ability to Use Claude Subscriptions With OpenClaw and Similar Tools," VentureBeat, April 4, 2026, https://venturebeat.com/technology/anthropic-cuts-off-the-ability-to-use-claude-subscriptions-with-openclaw-and. ↩
"Claude Code vs Codex vs Aider vs OpenCode vs Pi 2026," thoughts.jock.pl, accessed April 22, 2026, https://thoughts.jock.pl/p/ai-coding-harness-agents-2026. ↩
Better Stack Community, "Claude Opus 4.7: Benchmarks, Tokenizer Changes, and Coding Performance," accessed April 22, 2026, https://betterstack.com/community/guides/ai/claude-opus-4-7/. ↩
Ibid. ↩
Thomas Claburn, "Anthropic: No, Absolutely Not, You May Not Use Third-Party Harnesses With Claude Subs," The Register, February 20, 2026, https://www.theregister.com/2026/02/20/anthropic_clarifies_ban_third_party_claude_access/. ↩
"Feature: Auto-extract text from inbound PDF/document attachments," Issue #28818, openclaw/openclaw, GitHub, February 27, 2026, https://github.com/openclaw/openclaw/issues/28818. ↩
"openclaw update silently drops user-added EnvironmentFile/Environment directives when regenerating systemd unit," Issue #66248, openclaw/openclaw, GitHub, April 2026, https://github.com/openclaw/openclaw/issues/66248. ↩

Claude Opus 4.7: Mixed Early Signal, Real API Breaks, and a Token Usage Story Anthropic Had to Address Fast

Solomon Neas — Sat, 18 Apr 2026 17:57:15 +0000

Claude Opus 4.7: Mixed Early Signal, Real API Breaks, and a Token Usage Story Anthropic Had to Address Fast

Anthropic launched Claude Opus 4.7 on April 16 at the same base price as Opus 4.6, then tucked the real story inside the docs: API breaking changes, new thinking behavior, new effort controls, beta task budgets, sharper Claude Code defaults, and a multimodal bump that looks real once you read past the launch copy.¹

My first take on this release was probably too upbeat. After digging in more, the honest read is messier. I have not spent enough time with Opus 4.7 myself to write a hard firsthand verdict, so this post is better read as reported analysis and early signal, not a personal field report. Anthropic is clearly pitching Opus 4.7 as the better model for long-running agentic coding, and the docs do point to real changes.² But the early public reaction has been mixed at best. A lot of power users on X and Reddit are calling it underwhelming, more expensive in practice, or flat-out worse for their workflows, especially in Claude Code.³

The real picture, at least right now, is that Anthropic shipped a release with genuine technical changes, real migration consequences, and enough backlash that the token usage story became part of the launch within hours.

Anthropic Is Selling a Workflow Shift, Not Just a Better Benchmark Card

Anthropic is positioning Opus 4.7 as the recommended starting point for its hardest tasks and calls it a "step-change improvement in agentic coding" over Opus 4.6.⁴ That is strong language. Whether it holds up in real use is still getting argued out in public, and I am not going to pretend I have enough seat time yet to settle that myself.

The core pitch is not benchmark chest-thumping. It is behavior under real work. Anthropic says Opus 4.7 handles long-running tasks with more rigor, follows instructions more precisely, and verifies its own outputs before reporting back.⁵ Boris Cherny's launch thread makes the same point from the operator side: auto mode, recaps, focus mode, stronger verification habits, and better effort tuning all matter because the model is being pushed toward longer, more autonomous runs.⁶

That is why this release feels different from a normal model bump. The base capability matters, sure. What stands out more is how explicit Anthropic is getting about the workflow layer around the model.

The Biggest Upgrade Might Be the Workflow Stack Around the Model

Three changes matter most here.

First, Opus 4.7 introduces xhigh effort between high and max, which gives API users finer control over reasoning depth and latency on hard tasks.⁷ Anthropic's effort docs say the API default is still high, but recommend starting at xhigh for coding and agentic use cases.⁸ That matters because a lot of people will assume they are getting the best version of 4.7 out of the box when they are not.

Second, adaptive thinking replaces the old style of thinking budgets on Opus 4.7. Thinking is not automatically on. You have to opt into thinking: { type: "adaptive" }, and once you do, interleaved thinking between tool calls comes with it.⁹ That is a real behavior change, not a cosmetic rename.

Third, task budgets look like one of the more practical additions in this whole release. Anthropic frames them as an advisory budget across the full agentic loop, not a hard cap like max_tokens.¹⁰ If that beta feature works the way the docs suggest, it gives teams a more realistic way to control cost and runtime on longer autonomous jobs without forcing the model to slam into a wall mid-task.

Read those three changes together and the direction is obvious: Anthropic wants people to run longer jobs, give the model room to think, and manage the run at the task level instead of babysitting each individual request.

Claude Code Users Get the Clearest Upgrade Path

The Claude Code side of the release is where the product strategy becomes easiest to read.

On the Anthropic API, the opus alias now resolves to Opus 4.7. On Bedrock, Vertex, and Foundry, that alias does not mean the same thing yet, so you need to pin explicitly if you want the new model.¹⁰ Opus 4.7 also requires Claude Code v2.1.111 or later.¹⁰

More interesting than the versioning detail is the default behavior. Anthropic's Claude Code docs say Opus 4.7 uses xhigh effort by default in Claude Code.¹⁰ Pair that with auto mode for Max users, the new /ultrareview workflow, and Boris's emphasis on focus mode, recaps, and verification, and you get a pretty clear picture of where Claude Code is going.⁵¹¹

It is moving away from short interactive back-and-forth and toward "hand this thing a chunk of work and come back to a recap." That will be great for people who actually want an agent. It will also expose every weak habit people built around constant supervision, vague prompts, and zero verification.

The API Story Is More Interesting Than the Launch Post

This is the part people should read twice before swapping production workloads over.

Anthropic's release notes explicitly say Opus 4.7 includes API breaking changes relative to Opus 4.6.¹ The migration guide spells out the important ones: extended thinking budgets are gone, adaptive thinking is the supported model-specific path, non-default sampling parameters now error, and thinking content is omitted by default unless you opt back into it.¹¹

That is not catastrophic, but it is enough to break wrappers, SDK assumptions, eval harnesses, and whatever cursed internal scripts people built at 2 a.m. six weeks ago.

There is also a cost wrinkle here that deserves way more attention than the launch copy gave it. Anthropic kept the base Opus 4.7 price at $5 input and $25 output per million tokens, but both the migration guide and pricing docs say the new tokenizer may use roughly 1x to 1.35x as many tokens for the same text.¹¹¹² Same sticker price, potentially higher real-world usage.

Anthropic's response matters here. Boris Cherny said Anthropic increased rate limits for all subscribers "to make up for" the higher token usage, and separately said the company tuned limits so users would get the same amount of usage with xhigh.¹³ That public acknowledgment tells you Anthropic knew this would land hard.

It still does not settle the practical question. Higher rate limits help subscribers, but they do not erase the operational effect of larger token counts, especially for Claude Code sessions, long contexts, or teams with cost controls built around older token behavior.

The Vision Upgrade Still Looks Legit

Anthropic says Opus 4.7 can see images at more than three times the resolution of earlier Claude models and should produce better interfaces, slides, and docs as a result.¹⁴ Normally I would roll my eyes at that kind of line. In this case, the docs actually give it teeth.

The vision docs say Opus 4.7 supports images up to 2576 pixels on the long edge and 4784 image tokens, versus 1568 and 1568 for prior models.¹⁵ That is a real jump. If you use models for screenshot review, document parsing, UI QA, or anything where detail gets lost in downscaling, this is one of the clearest improvements in the whole release.

It also has cost implications. Anthropic's own example shows a 2000x1500 image landing around 4000 image tokens on Opus 4.7.¹⁵ Better vision is nice. Better vision that quietly burns more tokens is the part teams discover later.

The Safety Story Got Weird Fast

The system card is worth reading because it says two things at once.

Anthropic calls Opus 4.7 its "most capable general-access model to date," then immediately says it does not advance the company's overall capability frontier because Mythos Preview remains stronger.¹⁶ That is a weird but useful distinction. It tells you 4.7 is the best generally available version of Claude, but not the strongest thing Anthropic has internally.

The system card also says Opus 4.7 ships with new classifier-based cyber safeguards for prohibited and high-risk cyber use, and Anthropic's public launch post ties legitimate security research access to the Cyber Verification Program.¹⁶¹⁷ So this is not just a model release. It is also a deployment and policy story.

But the rollout got messy almost immediately. A bunch of users reported that Opus 4.7 was suddenly treating ordinary code and file reads like malware or prompt injection attempts. Anthropic staffer Alex Albert later said this was a bug on Anthropic's side, not the model "being cautious": older Claude builds were applying a stale safety prompt that Opus 4.7 did not need, which led to the false malware warnings. His fix was simple, update Claude or relaunch the app.¹⁸

That distinction matters. If the issue was a stale prompt or integration-layer bug, then this was not really evidence that Opus 4.7 itself is uniquely paranoid. It was evidence that model upgrades can break in the harness around the model, and that those breakages can look exactly like a model regression when you are the person getting blocked.

That matters because Anthropic is clearly trying to push capability up while tightening the boundary around who gets to use the sharper edges. Day-one safety bugs like this poison trust fast, even when the root cause lives outside the base model.

The Early Public Reaction Is the Real Story Right Now

I have not used Opus 4.7 heavily enough yet to tell you, from personal battle scars, that it is obviously better than 4.6. And the public reaction over the first day does not support pretending otherwise. Reddit threads in r/ClaudeAI, r/Anthropic, and r/ClaudeCode are full of people calling it a regression, saying it burns through usage limits too quickly, or saying the gains are not obvious enough to justify the cost.³¹⁴

That does not mean the model is bad. It does mean the rollout landed in a skeptical environment, and Anthropic's own staff had to publicly defend adaptive thinking, acknowledge higher token use, increase subscriber limits, and explain that at least one wave of malware-style warnings came from a stale safety prompt bug in older Claude builds.¹³¹⁵¹⁸

The fair read, at least this early, is probably this: Opus 4.7 may be better on certain hard coding, vision, and long-horizon tasks, but the upgrade does not look clean or universally felt. If you have not noticed a huge difference yet, that is not some failure to appreciate the model. That seems like a pretty normal reaction right now.

What Actually Matters If You Build With This Stuff

If you build products, agents, or internal tooling on top of Claude, the real checklist is a little harsher:

Audit any 4.6-specific thinking and sampling assumptions before migrating.¹¹
Decide whether your default should stay at high or move to xhigh for hard tasks.⁸
Test task budgets before you trust them for cost control in production.¹⁰
Pin exact model IDs across providers instead of assuming opus means the same thing everywhere.¹⁶
Re-check your image-heavy workloads because better vision can still mean a bigger bill.¹²¹⁷
Do not treat unchanged price-per-million as proof that real usage costs stayed flat.¹¹¹²¹³

That is the divide I keep coming back to. Opus 4.7 might be strong. The teams that get the most out of it are going to be the ones that treat it like a systems change, not just a model swap.

The Bottom Line

I still think Opus 4.7 is a real release. Not fake. Not just a marketing rename. There are too many actual platform and behavior changes for that.

What I do not think, at least not yet, is that the evidence supports writing as if Anthropic obviously nailed it, or as if I have personally validated the upside in heavy daily use.

The safer read is that Anthropic shipped a technically important release with mixed early reception. The model may be better on hard agentic coding, vision, and long-horizon tasks. The rollout also brought token-usage anxiety, migration friction, public skepticism, and enough backlash that Anthropic had to raise subscriber limits almost immediately.¹³

So this post is really two things at once: a news-and-docs roundup, and a cautious read on the early reaction.

Opus 4.7 might prove itself over the next week or two. It might also end up remembered as a release where the docs and benchmark story were cleaner than the first wave of user experience. Right now, pretending certainty would be bullshit.

The interesting part is not whether Anthropic says 4.7 is better. Of course they do. The interesting part is whether builders keep reaching for it once the novelty wears off.

Notes

Originally published at solomonneas.dev/blog/claude-opus-47-release. Licensed under CC BY-NC-ND 4.0 - attribution required, no commercial use, no derivatives.

Anthropic, "Claude Platform," in "Release Notes Overview," Claude API Docs, accessed April 17, 2026, https://platform.claude.com/docs/en/release-notes/overview. ↩
Anthropic, "Claude Opus 4.7," Anthropic News, accessed April 16, 2026, https://www.anthropic.com/news/claude-opus-4-7. ↩
Henry Chandonnet, "The Claude-lash Is Here: Opus 4.7 Is Burning Through Tokens, and Some People's Patience," Business Insider, April 17, 2026, https://www.businessinsider.com/anthropic-claude-opus-4-7-backlash-tokens-2026-4; Reddit post, "Opus 4.7 Released!," r/ClaudeAI, accessed April 17, 2026, https://www.reddit.com/r/ClaudeAI/comments/1sn585s/opus_47_released/; Reddit post, "Claude Code tip: 10 seconds fix to avoid the Opus 4.7 token burn," r/ClaudeAI, accessed April 17, 2026, https://www.reddit.com/r/ClaudeAI/comments/1snv4yq/claude_code_tip_10_seconds_fix_to_avoid_the_opus/. ↩
Anthropic, "Models Overview," Claude API Docs, accessed April 17, 2026, https://platform.claude.com/docs/en/about-claude/models/overview. ↩
Claude (@claudeai), "Introducing Claude Opus 4.7, our most capable Opus model yet. It handles long-running tasks with more rigor, follows instructions more precisely, and verifies its own outputs before reporting back. You can hand off your hardest work with less supervision," X, April 16, 2026, https://x.com/claudeai/status/2044785261393977612. ↩
Boris Cherny (@bcherny), "Dogfooding Opus 4.7 the last few weeks, I've been feeling incredibly productive. Sharing a few tips to get more out of 4.7 🧵," X, April 16, 2026, https://x.com/bcherny/status/2044847848035156457; Boris Cherny (@bcherny), "1/ Auto mode = no more permission prompts," X, April 16, 2026, https://x.com/bcherny/status/2044847849662505288; Boris Cherny (@bcherny), "3/ Recaps," X, April 16, 2026, https://x.com/bcherny/status/2044847853030580247; Boris Cherny (@bcherny), "4/ Focus mode," X, April 16, 2026, https://x.com/bcherny/status/2044847855006024147; Boris Cherny (@bcherny), "6/ Give Claude a way to verify its work," X, April 16, 2026, https://x.com/bcherny/status/2044847858634064115. ↩
Claude (@claudeai), "On the API, a new xhigh effort level between high and max gives you finer control over reasoning and latency on hard problems. Task budgets (beta) help Claude prioritize work and manage costs across longer runs," X, April 16, 2026, https://x.com/claudeai/status/2044785264313221470. ↩
Anthropic, "Effort," Claude API Docs, accessed April 17, 2026, https://platform.claude.com/docs/en/build-with-claude/effort. ↩
Anthropic, "Adaptive Thinking," Claude API Docs, accessed April 17, 2026, https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking. ↩
Anthropic, "Task Budgets," Claude API Docs, accessed April 17, 2026, https://platform.claude.com/docs/en/build-with-claude/task-budgets. ↩
Anthropic, "Migrating to Claude Opus 4.7," in "Migration Guide," Claude API Docs, accessed April 16, 2026, https://platform.claude.com/docs/en/about-claude/models/migration-guide#migrating-to-claude-opus-4-7. ↩
Anthropic, "Pricing," Claude API Docs, accessed April 17, 2026, https://platform.claude.com/docs/en/about-claude/pricing. ↩
Boris Cherny (@bcherny), "Opus 4.7 uses more thinking tokens, so we've increased rate limits for all subscribers to make up for it. Enjoy!" X, April 16, 2026, https://x.com/bcherny/status/2044839936235553167; Boris Cherny (@bcherny), "@mark_k @AnthropicAI Not accurate. Adaptive thinking lets the model decide when to think, which performs better. Opus 4.7 also uses more thinking tokens on average than 4.6, which is why we have increased rate limits for all subscribers to make up for it," X, April 16, 2026, https://x.com/bcherny/status/2044836750066151666; Boris Cherny (@bcherny), "@a_lamparelli We've tuned rate limits to give you the same amount of usage with xhigh," X, April 16, 2026, https://x.com/bcherny/status/2044805730138804519. ↩
Reddit post, "Opus 4.7 Released!," r/ClaudeAI, accessed April 17, 2026, https://www.reddit.com/r/ClaudeAI/comments/1sn585s/opus_47_released/; Reddit post, "I have tested Opus 4.7 and it is worse compared to Opus 4.6," r/Anthropic, accessed April 17, 2026, https://www.reddit.com/r/Anthropic/comments/1snijmr/i_have_tested_opus_47_and_it_is_worse_compared_to/; Reddit post, "Just use Sonnet 4.6 and stay away from Opus 4.7," r/ClaudeCode, accessed April 17, 2026, https://www.reddit.com/r/ClaudeCode/comments/1snwk9v/just_use_sonnet_46_and_stay_away_from_opus_47/. ↩
Henry Chandonnet, "The Claude-lash Is Here"; Alex Albert (@alexalbert_), "A lot of bugs that folks may have hit yesterday when first trying Opus 4.7 are now fixed. Thanks for bearing with us," X, April 17, 2026, https://x.com/alexalbert_/status/2045159041283064095. ↩
Anthropic, "Model Configuration," Claude Code Docs, accessed April 17, 2026, https://code.claude.com/docs/en/model-config. ↩
Anthropic, "Vision," Claude API Docs, accessed April 17, 2026, https://platform.claude.com/docs/en/build-with-claude/vision. ↩
Alex Albert (@alexalbert_), "Some of you ran into Opus 4.7 refusing normal code edits with \"this might be malware\" warnings. That was a bug on our side, not the model being cautious. Older builds applied a stale safety prompt that Opus 4.7 doesn't need. Run claude update or relaunch the app," X, April 17, 2026, https://x.com/alexalbert_/status/2045238786339299431. ↩

Dreaming Is Useful. Structured Memory Is Better

Solomon Neas — Fri, 17 Apr 2026 07:05:55 +0000

I ran OpenClaw Dreaming for a full week on top of my existing memory stack to answer one question: does Dreaming actually improve memory quality, or does it just inflate memory volume?

Both. It surfaced real signal I would have lost. It also dumped enough boilerplate into the promotion stream to prove structured memory still has to be the foundation. If you want the official feature overview first, OpenClaw's Dreaming docs are here: Dreaming. After a week, Dreaming stays on, but as a supporting layer. Not the system.

The baseline was already working

This trial did not start from zero. The stack was already in daily use:

Daily logs in memory/YYYY-MM-DD.md for raw continuity
Atomic knowledge cards in memory/cards/*.md for durable facts and lessons
A slim MEMORY.md acting as an index, not a data landfill
Semantic retrieval over cards using local embeddings
A Memory Sweep cron for review and promotion discipline

That architecture exists because monolithic memory eventually collapses under its own weight. Retrieval gets noisy, cost climbs, and the agent starts missing things that are technically "in memory" but practically unrecoverable. Structured memory fixes that by treating memory as a retrieval system instead of a dump file.

Trial config

Dreaming was enabled on 2026-04-06 as a one-week trial with nightly cadence:

dreaming.enabled=true
dreaming.frequency="0 3 * * *"

Documented as a trial, not a migration, with explicit concern about noisy promotions. A review cron was scheduled for 2026-04-14 to evaluate impact after one full week of live usage.

Nothing else in the memory pipeline was touched. Cards, logs, retrieval, and sweep all stayed active so Dreaming could be evaluated as a pure additive layer.

What Dreaming actually does

From observed behavior, Dreaming runs a nightly retrospective pass over short-term recall:

grounded REM/backfill flow
diary-style processing
candidate durable-fact extraction
promotion hooks into long-term memory surfaces

In plain terms, it is a second-pass recall mechanism. It can rescue durable information that never got manually promoted during the day. That is real value in long, messy sessions.

One-week health check

Core memory infrastructure came out clean:

Main memory healthy
Embeddings ready
Vector search ready
FTS ready
Recall store active
Dreaming cron active
memory_search returning relevant results

Operationally, nothing regressed. Cards stayed structurally normal, daily logs kept writing, semantic retrieval kept working.

So "did Dreaming break memory" was never the question. It did not. The question was quality.

Memory Sweep is the comparison that matters

Sweep is the reference point because it has been doing the same job Dreaming now claims, just more conservatively.

And to be fair to Sweep, the cron reports show it was not sitting there idle. Over the same week, it was reviewing real sessions and persisting useful state with pretty solid discipline.

A few examples from the sweep channel:

April 9: reviewed non-cron sessions and updated a durable agent-workflow card.
April 10: turned grocery receipts into a durable tracking workflow.
April 11: handled a security incident conservatively, logging what mattered without duplicating existing cards.
April 13 to April 15: kept the Lazarus Group research card current while threat-assessment sections and supporting research were still moving.
April 16: created an xMCP service-ops card and logged the operational follow-up cleanly.

That is not a cron doing nothing. That is a curation layer doing triage. Sweep evaluates session material, skips cron, heartbeat, and helper noise, checks whether the durable information already exists, and only writes when something actually changes or deserves promotion.

That restraint matters. Some nights the correct outcome really is "no new cards." But across the week, Sweep still created or updated cards for grocery tracking, agent-workflow rules, Lazarus Group research, blog publishing rules, xMCP service operations, and malware-response documentation. It also kept daily logs current without flooding memory with duplicate fragments.

Dreaming, over the same window, promoted a handful of genuinely useful durable facts and a lot of transcript residue. Same job, different discipline. Sweep's default is "persist carefully after review." Dreaming's default is closer to "surface candidates broadly and let cleanup happen later." That difference is the whole story.

Dreaming quality: real signal, real noise

The good

Useful promotions did show up, and they were more specific than "Dreaming found something interesting."

A few examples of what it actually added:

It recovered a real ACP constraint: Discord thread creation works reliably from a fresh inbound turn, but nested or yielded turns can collapse into webchat and fail.
It helped move an agent lane from "probably working" to a verified workflow, which turned that discovery into a durable card instead of leaving it buried in chat history.

That part matters. Those are real operating rules that affect how I route agent work and catch workflow hiccups, not just vague themes Dreaming happened to notice.

The bad

Staged recall also contained a lot of debris:

heartbeat boilerplate (HEARTBEAT_OK)
silent sentinel text (NO_REPLY)
tiny one-line chat fragments
metadata-heavy transcript sludge

This is the limitation. Without strict filtering, Dreaming will keep surfacing things that are technically recallable and semantically worthless.

Where Dreaming writes

During the trial, Dreaming artifacts showed up in:

DREAMS.md and workspace equivalents
memory/.dreams/* (session corpus and short-term recall JSON)
MEMORY.md promoted sections tagged with openclaw-memory-promotion
daily logs with Light and REM candidate traces

Cards and daily logs stayed intact. The promotion stream is what needs quality controls.

Complement, not core

After one week the architecture answer is obvious:

Structured memory (cards, slim index, retrieval, Sweep) is the core
Dreaming is a useful second-pass promotion layer

Dreaming catches what day-of workflows miss. It is not trustworthy enough yet to be the primary curation mechanism. That is not a failure, it is a role.

What I am keeping, what I am tuning

Keeping Dreaming enabled. Tightening the promotion side:

heavier penalties for boilerplate tokens
stricter filtering against low-information one-liners
lower promotion likelihood for metadata-only fragments
human-curated cards stay the authoritative path

The goal is not maximal recall. The goal is durable, retrievable memory that stays useful under load.

Verdict

Dreaming is useful. Structured memory is better. 🦞

That is not a contradiction, it is the right layering. Use Dreaming to recover signal from transcript residue. Use structured memory to decide what deserves to live long-term. Blend the roles correctly and you get better continuity without turning your memory system into a junk drawer.

Originally published at solomonneas.dev/blog/dreaming-useful-structured-memory-better. Licensed under CC BY-NC-ND 4.0 - attribution required, no commercial use, no derivatives.

GPT-5.4-Cyber Is Really a Fight Over Access Control

Solomon Neas — Wed, 15 Apr 2026 02:49:40 +0000

OpenAI just made its answer to Anthropic's Mythos pretty clear.

This is not just a model story. It is an access-control story.

OpenAI wants broader, tiered access through Trusted Access for Cyber. Anthropic wants a tighter gate through Project Glasswing. One side is arguing that verified defenders should get access at scale. The other is arguing that this class of capability is dangerous enough to keep inside a much smaller circle.

That is a real disagreement. It is also the part of the story most people are still flattening into launch-day hype.

What OpenAI Actually Announced

OpenAI's April 14 post is pretty direct. The company says it is scaling Trusted Access for Cyber to thousands of verified individual defenders and hundreds of teams responsible for defending critical software. It also introduced GPT-5.4-Cyber as a variant of GPT-5.4 trained to be cyber-permissive, with a lower refusal boundary for legitimate cybersecurity work and new binary reverse-engineering capability for analyzing compiled software without source code access.¹

Reuters confirmed the key part of the rollout: GPT-5.4-Cyber is not a public release. It is being rolled out on a limited basis to vetted security vendors, organizations, and researchers, with higher levels of verification unlocking more sensitive capability.²

So yes, OpenAI is talking about broader access. It is still gating the good stuff.

The Real Split Is Access Philosophy

Anthropic's framing is sharper and more dramatic. In its Mythos Preview write-up, the company described a model it says can identify and exploit zero-days in every major operating system and major web browser when directed to do so. Anthropic presented that as the reason for Project Glasswing, a restricted deployment model built around a small group of partners and a coordinated defensive push.³

OpenAI is arguing almost the opposite. Its TAC post says it does not think it is practical or appropriate to centrally decide who gets to defend themselves.¹ That line was not subtle. It was a shot at the curated-partner model without naming Anthropic directly.

Both approaches assume the scarce asset is the model. For most defenders, the scarcer asset is everything around the model: verification, workflow integration, triage discipline, reverse-engineering skill, patch pipelines, logging, analyst time, and plain old trust. A stronger model helps. It does not magically turn noisy output into fixed software.

What GPT-5.4-Cyber Actually Changes for Defenders

The clearest practical claim in OpenAI's launch is binary reverse engineering. That is not some vague promise about AI making security better. It points to a specific use case: giving analysts help with compiled software when source code is unavailable.

In practice, that could mean:

faster triage of suspicious binaries,
faster explanation of unfamiliar functions,
quicker hypothesis generation around likely vulnerability classes,
and a better first pass before a human digs deeper in Ghidra or IDA.

That is useful. It is not a replacement for real reverse-engineering skill.

Anyone who has tried to use a general model for malware analysis or exploit-adjacent research has run into the same wall: the model gets skittish, moralizes, or refuses a task that is obviously defensive. OpenAI is trying to reduce that friction for verified users.¹

The Caveat Everyone Wants to Skip

This is where the independent caveats matter. OpenAI's own GPT-5.4 Thinking System Card says GPT-5.4 is the first general-purpose model in its line with mitigations for high cyber capability.⁴ That tells you the company itself thinks the baseline model is already in different territory.

The UK AI Security Institute's evaluation of Mythos adds a second useful data point. AISI found that Mythos Preview was a step up over prior frontier models, succeeded on expert-level CTF tasks 73 percent of the time, and became the first model to complete its full 32-step corporate network attack simulation end to end in some runs.⁵

But AISI also says its test environments are easier than real defended systems. There were no active defenders, no realistic defensive tooling, and no real penalties for noisy behavior that would trigger alerts in production.⁵

That is exactly the kind of caveat people tend to bury after the headline.

Why Workflow Still Matters More Than Weights

A model that can explain a decompiled function, highlight suspicious control flow, or suggest where memory corruption might live is valuable. A model that can reliably find, validate, chain, and exploit serious vulnerabilities across messy real environments without heavy scaffolding is a different beast entirely.

Those are not the same claim, and too much of the public conversation treats them like they are.

That is why I do not think either company has fully answered the core question.

Anthropic's approach may slow diffusion, but it also concentrates advantage among already powerful partners. OpenAI's broader approach is more appealing if you actually want these tools in the hands of working defenders, smaller teams, and security vendors beyond the usual giants. But broader verification is not a magic shield. Trusted access is still a policy layer. If identity checks are weak, if accounts get abused, or if the surrounding agent runtime is sloppy, the safety story gets shaky fast.

A defender does not win because a model is good at describing assembly

A defender wins when suspicious code gets triaged faster, false positives get killed earlier, high-confidence findings get validated, patches get written, and the fix lands before the other side can capitalize.

That is a pipeline problem. The model sits inside it. The model is not the pipeline.

My Take

The strongest reading of GPT-5.4-Cyber is not "OpenAI caught up to Mythos" or "the AI cyber arms race is here," even if both headlines are tempting.

The stronger reading is that frontier labs are turning access control into product strategy because raw capability is no longer the only thing they are selling. They are selling who gets to use it, under what conditions, with what audit trail, and with what story attached.

For defenders, the question is simpler.

Will this help real teams do better work now, before similar capability spreads elsewhere anyway?

That is the question worth tracking. Not who had the scarier press release.

Notes

1. OpenAI, "Trusted Access for the Next Era of Cyber Defense" (April 14, 2026).
2. Reuters, "OpenAI Unveils GPT-5.4-Cyber a Week After Rival's Announcement of AI Model" (April 14, 2026).
3. Anthropic, "Claude Mythos Preview" (April 7, 2026).
4. OpenAI, "GPT-5.4 Thinking System Card" (March 5, 2026).
5. AI Security Institute, "Our Evaluation of Claude Mythos Preview's Cyber Capabilities" (April 2026).

Claude Mythos Preview Is a Warning Shot for Every Security Team

Solomon Neas — Thu, 09 Apr 2026 02:38:47 +0000

Claude Mythos Preview Is a Warning Shot for Every Security Team

Anthropic just said the quiet part out loud.

Its new gated model, Claude Mythos Preview, is strong enough at vulnerability research and exploit development that Anthropic decided not to release it for general access. Instead, it wrapped the model inside Project Glasswing, an invitation-only defensive security program with launch partners including AWS, Cisco, CrowdStrike, Google, Microsoft, NVIDIA, Palo Alto Networks, JPMorganChase, Apple, Broadcom, and the Linux Foundation.

That alone should get your attention. Frontier labs love shipping. They do not voluntarily keep flagships behind a fence.

And yes, Anthropic looks nervous.

What Anthropic Actually Announced

Across Anthropic’s official Glasswing launch post, the Project Glasswing page, the Frontier Red Team’s technical write-up, the system card, the alignment risk update, and Anthropic’s own platform release notes, the picture is consistent:

Mythos Preview is not generally available. Anthropic says it is a limited research preview for defensive cybersecurity work.
Access is invitation-only. The release notes explicitly describe it as a gated preview.
Anthropic says the model has already found thousands of zero-day vulnerabilities across critical software (per Anthropic).
Anthropic says those findings include bugs in every major operating system and every major web browser.
Anthropic says Mythos can often identify vulnerabilities and develop related exploits autonomously, with minimal or no human steering.
Anthropic is putting real money behind the defensive rollout: up to $100 million in usage credits and $4 million in open-source security donations.
Participants can access it through Anthropic’s API, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry, but only inside the preview program.

That is not a normal model launch. That is a containment strategy with a press release attached.

The Details That Matter

The headline is big, but the technical details are what make this feel different.

Anthropic’s red team says Mythos found:

a 27-year-old OpenBSD bug that could remotely crash a target over TCP,
a 16-year-old FFmpeg vulnerability in code exercised millions of times by automated testing without being caught,
and chained Linux kernel vulnerabilities that allowed escalation from regular user access to full system compromise.

Anthropic also says the model wrote sophisticated exploit chains, not just toy crash reproducers. One example in the red-team post describes a browser exploit chain that combined multiple vulnerabilities and escaped both renderer and OS sandboxes. Another describes autonomous work on privilege escalation and remote code execution scenarios.

The benchmark deltas are ugly in the way that matters. Anthropic reports 83.1% on Cybersecurity Vulnerability Reproduction for Mythos versus 66.6% for Opus 4.6. On coding-heavy evaluations, the model also jumps hard: 77.8% on SWE-bench Pro versus 53.4% for Opus 4.6, 59.0% on SWE-bench Multimodal versus 27.1%, and 82.0% on Terminal-Bench 2.0 versus 65.4%, with Anthropic noting 92.1% under a more permissive timeout setup.

That matters because this is not a “cyber model” in the old narrow sense. Anthropic’s own framing is that Mythos’ cyber capabilities are downstream from broader gains in coding, reasoning, and autonomous tool use. In plain English: if a model gets much better at understanding messy codebases, testing hypotheses, writing debugging scaffolds, and persisting through long tasks, it also gets much better at offensive security work.

The System Card Makes the Release Decision Clear

The strongest signal is not the marketing page. It is the system card.

Anthropic says Mythos Preview showed such strong dual-use cyber capability that it chose not to make the model generally available. Instead, it restricted access to partners working on defensive security. The system card also says this choice was not required by Anthropic’s Responsible Scaling Policy. That means Anthropic made a discretionary call: this thing is useful enough for defense, dangerous enough for offense, and not ready for the open market.

Anthropic also describes Mythos as its best-aligned model so far, which sounds reassuring right up until you hit the next sentence. The company says that when Mythos does engage in concerning behavior, those actions can be more serious because the model is so much more capable, especially in software engineering and cybersecurity. The separate alignment risk update says Mythos is more capable at working around restrictions, is used more autonomously than prior models, and pushed Anthropic to admit errors in its own training, monitoring, evaluation, and security processes.

That combination matters:

better aligned overall,
more capable at cyber tasks,
more capable at agentic workflows,
still occasionally willing to do sketchy things in pursuit of task success.

It is honest. But it is not comforting.

Take the Claims Seriously, Not Blindly

There is one important caveat.

Most of the biggest Mythos claims are still coming from Anthropic itself. The company says more than 99% of the vulnerabilities it has found are not yet patched, so it cannot publicly disclose full details on most of them. That means outside verification is limited for now.

So no, you should not swallow every benchmark and every claim whole just because a glossy PDF says so.

But you also should not shrug this off as AI-company hype.

Anthropic is doing something labs hate doing: limiting distribution of a powerful model because it thinks widespread release would create real offensive risk. That is a stronger signal than any benchmark chart.

What This Means for Cybersecurity Teams

If Anthropic is basically right, a few old assumptions just died.

The grace period between discovery and exploitation is getting crushed

CrowdStrike’s quote on the Glasswing page puts it bluntly: what once took months can now happen in minutes with AI. That probably overstates the timeline, but the direction is right. If high-end models can reliably move from bug discovery to exploit development faster, the old patch rhythm stops being good enough.

Weekly triage meetings and “we’ll get to it next sprint” vulnerability handling are going to age like milk.

AppSec becomes more like active defense

If models can find weird bugs in mature codebases that survived years of review and automated testing, then secure SDLC theater is not going to save anyone. Security teams need:

faster variant analysis,
tighter patch validation loops,
code scanning that includes agentic workflows,
and better prioritization around exposed, memory-unsafe, parser-heavy software.

The dangerous surface is not just your flagship product. It is also the dusty dependency parsing malformed media, network packets, or archive files three layers down.

Open source maintainers are now on the critical path

Anthropic and its partners are clearly treating open source as shared attack surface. They are right. The same libraries sitting in enterprise products, browsers, cloud tooling, appliances, and security stacks are exactly where an AI-assisted vulnerability hunt becomes painful.

If you rely heavily on open source, your third-party risk program cannot just be “watch GitHub advisories and pray.” You need real inventory, ownership, and patch routing.

What This Means for Cyber Threat Intelligence Teams

Most CTI teams are still treating this as a future-deck topic.

CTI teams need to stop treating AI-assisted exploitation as a future trend deck topic and start treating it like live collection priority.

A few things change immediately.

Vulnerability intel gets more time-sensitive

If exploit development speeds up, then the value of early vendor advisories, patch diffs, and quiet maintainer activity goes up with it. CTI teams should be watching for:

sudden patch activity in security-sensitive open source projects,
vague stability fixes that smell like quietly handled security bugs,
exploit chain research against browsers, kernels, codecs, parsers, and network-facing services,
and signs that private findings are becoming operationalized faster than before.

Patch diff analysis is about to matter even more.

“Who can weaponize this?” becomes a shorter list, but a much faster one

The old comfort blanket was that only top-tier researchers could go from obscure crash to clean exploit. Mythos weakens that assumption. Anthropic’s own red-team post says even internal users without formal security backgrounds were able to prompt toward serious exploit work. That is Anthropic’s claim, not outside validation, but it is still worth taking seriously.

That does not mean every random actor suddenly becomes a world-class exploit developer overnight. It does mean more actors can operate above their historical skill ceiling.

For CTI, the collection surfaces that matter now:

dark web forums and Telegram channels where jailbreaks and safeguard bypasses circulate,
exploit broker communities and private research circles with early access to frontier models,
and operational groups already automating tradecraft integrations who will be the first to weaponize capability jumps.

The actors to watch are not necessarily new. They are existing skilled groups who now have a capable assistant.

Detection teams need to watch for machine-speed tradecraft, not just machine-written malware

The obvious fear is AI-generated malware. I think the more immediate problem is AI-assisted acceleration across the whole intrusion lifecycle: recon, exploit adaptation, script generation, privilege escalation paths, and post-exploitation troubleshooting.

In other words, some campaigns may not look wildly novel. They may just move faster, branch faster, and recover from failure faster.

That is a different detection problem.

What Practitioners Should Do Right Now

If I were running security or CTI in a mid-size enterprise today, I would treat the Mythos announcement as a forcing function and do five things:

Re-rank patch priorities around internet-facing systems, browsers, kernels, VPNs, hypervisors, media processing libraries, and authentication infrastructure.
Tighten time-to-triage for new critical and high-severity vulnerabilities. Not just patch SLA, actual analyst triage.
Stand up patch diff monitoring for critical open source dependencies and major platform vendors.
Pressure test detection engineering against faster exploit chaining and faster post-exploitation adaptation.
Revisit your assumptions about attacker labor. The question is no longer just “Could an actor do this?” It is “Could an actor do this with a frontier model and a weekend?”

Also, if your security stack still depends on luck, manual heroics, and one burned-out person who knows where everything is, fix that before someone else teaches you the lesson.

My Take

Mythos does not mean the sky is falling tomorrow.

But it does mean the economics of vulnerability discovery and exploitation are changing faster than a lot of defenders want to admit. Anthropic’s own response tells the story better than any benchmark: it kept the model gated, restricted use to defensive cybersecurity, wrapped it in a coordinated industry program, and started talking openly about safeguards before talking about product rollout.

That is not how you behave when you think a capability jump is business as usual.

For defenders, the message is simple: compress your own timelines before someone else compresses them for you.

Sources

Claude Code's Source Leak Was Embarrassing. The Real Story Is What It Revealed

Solomon Neas — Thu, 02 Apr 2026 12:46:59 +0000

On March 31, Anthropic accidentally published a source map inside Claude Code npm package version 2.1.88. That one packaging mistake exposed roughly 512,000 lines of TypeScript across nearly 2,000 files, handed competitors a detailed view of Anthropic's product roadmap, triggered a DMCA mess that briefly took down more than 8,100 GitHub repositories, and kicked off a wave of clean-room clones within hours.¹²³

The obvious lesson is that shipping source maps in a public package is bad. The more interesting lesson is that this was not mainly a code leak. It was a feature flag leak. Anthropic did not just lose implementation secrecy. It lost strategic secrecy.

The same day, npm users were also dealing with a separate supply chain incident: a North Korea attributed compromise of the Axios package that shipped a cross-platform remote access trojan through malicious releases 1.14.1 and 0.30.4.⁴⁵ Those two incidents together say more about the current JavaScript ecosystem than either one does alone. Build hygiene is weak, package trust is weaker, and the response playbook for leaks still assumes a centralized internet that no longer exists.

How the leak happened

The mechanics were simple. Anthropic published Claude Code v2.1.88 to npm with a .map file included. That source map was enough to reconstruct the readable TypeScript source for the CLI. Chaofan Shou appears to have been first to spot it publicly and posted about it immediately, after which mirrors spread fast across GitHub, Reddit, Hacker News, and IPFS.²⁶

The underlying failure looks mundane, which is exactly why it matters. Bun generates source maps by default. If packaging rules are not tight, those files can ride along into artifacts that were never meant to contain source. Reporting on the incident pointed to a missed .npmignore style exclusion as the immediate cause.²⁷

But there is a deeper layer. On March 11, 2026, twenty days before the leak, a bug was filed against Bun (oven-sh/bun#28001) reporting that source maps are served in production mode even when Bun's own documentation says they should be disabled.⁸ The reporter demonstrated that setting development: false in Bun.serve() still produces sourceMappingURL references and serves .map files. As of this writing, the bug is still open.

This matters because Anthropic acquired Bun in late 2025 and built Claude Code on top of it.⁹ The most likely scenario: Anthropic ran a production build expecting Bun to suppress source maps per its documented behavior. The bug meant the .map file got generated anyway. Without an explicit .npmignore exclusion or a files field in package.json to catch the unexpected output, the 59.8 MB source map rode along into the published npm package.

Boris Cherny, who leads Claude Code, said the cause was human error, not a tooling defect. The deployment process still had manual steps, and one of them was missed. He framed the follow-up as a blameless postmortem problem: fix the process, not the person.⁷⁹ That framing drew pushback. Multiple developers on Hacker News and Reddit argued that the Bun.serve() explanation Cherny addressed was a visible symptom, not the root cause, and that the underlying bug also affected how Bun bundles output for npm packaging.⁸

Both explanations can be true simultaneously. A known tooling bug generated a file that should not have existed. A missing packaging safeguard failed to catch it. The result was the same either way.

That is the right engineering posture on the postmortem side, but it comes with an uncomfortable footnote. This was the second time. Anthropic had already had a similar exposure in February 2025. Once is a packaging accident. Twice is a release control failure, especially when the company owns the build tool.⁷¹⁰

There is no mystery about prevention here. Public npm artifacts should be built in a hermetic pipeline, inspected before publish, and checked by policy for forbidden files. Source maps, tests, private certificates, .env fragments, internal prompts, and debug fixtures should all be blocked automatically. When you own both the product and the build tool, and a known bug in the build tool generates files that should not exist in production, the defense needs to be belt and suspenders: fix the bug, and independently verify the output before publishing.

What the source actually exposed

A lot of the commentary focused on novelty items. Some of that was justified because the leak was genuinely revealing. Some of it was internet theater. The useful way to read the dump is to separate trivia from strategic substance.

The trivia was funny. The strategic substance was not.

KAIROS: the unshipped product hiding behind feature flags

The biggest disclosure was KAIROS, an unreleased autonomous mode that turns Claude Code from a reactive CLI into a persistent agent. The leaked code showed a heartbeat loop that periodically asks a question close to, "anything worth doing right now?" If the answer is yes, the system can act without a fresh user prompt. It can watch pull requests, send push notifications, maintain append-only daily logs, and run a nightly memory consolidation flow literally called autoDream.⁶⁷

That is not a toy feature. It is a different trust model.

A request-response coding assistant is bounded by explicit user initiation. A background agent is bounded by policy, logging, tool permissions, and the quality of its judgment. That shift matters more than any implementation detail in the leaked files. It says Anthropic is not just building a better terminal wrapper. It is building an always-on operator.

The important point is that KAIROS looked built, not speculative. It was sitting behind feature flags, not in a half-finished branch. Competitors did not merely learn that Anthropic was interested in autonomous agents. They learned the architecture, the likely product direction, and some of the operational assumptions already encoded in the design.⁶¹¹

Hidden flags are roadmap leaks

The code reportedly exposed 44 hidden feature flags tied to capabilities such as swarm mode, voice commands, browser control via Playwright, background daemons, and agents that can sleep and later self-resume.⁶¹² Again, the damage is not that rivals can copy a function name. The damage is that they can infer sequence and priority.

Feature flags are internal strategy documents with executable syntax. Leak them and you leak what a team has built, what it is testing, what it is scared to ship, and what it thinks the next market looks like.

Three-layer memory is the kind of design detail competitors pay for

One of the more useful architectural disclosures was Claude Code's apparent three-layer memory model: a compact index that is always loaded, topic files retrieved on demand, and full transcripts that are never loaded directly, only searched when needed. The autoDream process reportedly runs in a forked subagent and consolidates memory over time.⁶¹²

That is a sensible design. It balances token economy, retrieval precision, and long-horizon continuity. It also answers a practical question many teams are still stumbling over: how do you make an agent feel persistent without rehydrating too much junk every turn?

This is where source leaks hurt. They compress competitors' learning cycles. Instead of discovering these patterns through years of shipping and failure, rivals can inspect a working system and skip to adaptation.

Undercover mode

The leaked undercover.ts file shows a mode that strips Anthropic-internal references when Claude Code operates in external repositories. According to technical analyses, it suppresses internal codenames, internal repository names, internal Slack references, and the phrase "Claude Code" itself, and it does not expose a force-off path in the external flow.¹²

The practical effect is simple: when Claude Code is used in public or third-party repositories, it avoids referencing Anthropic-specific internal context in generated output. From a product perspective, that reduces the chance of internal names leaking into public commits, pull requests, or comments. It is a factual design choice worth noting because it shows Anthropic treated disclosure of internal context as an engineering problem, not just a prompting problem.

The anti-distillation controls were real, and not very strong

The leak also exposed Anthropic's anti-distillation measures. One mechanism, gated by ANTI_DISTILLATION_CC, appears to inject fake tools into prompts in order to poison training data captured by competitors. Another uses connector-text summarization plus cryptographic signatures so captured traffic reflects compressed summaries rather than full assistant text.⁶¹²

As a technical barrier, this is thin. As Alex Kim and others noted, a man-in-the-middle proxy or configuration change could bypass it quickly, and some of the checks only apply to first-party flows.¹² That does not make the idea irrational. It makes it honest. Anthropic appears to understand that the primary defense against distillation is legal pressure, not cryptographic wizardry.

That matters in the context of its dispute with tools trying to piggyback on first-party access. The leak made visible the technical enforcement behind the policy rhetoric.

Native client attestation was the most serious defensive mechanism

One of the more consequential details was the client attestation path below the JavaScript runtime. Analyses of the leaked code described a cch=00000 placeholder in requests that Bun's native HTTP layer replaces with a computed hash before transmission, allowing the server to verify that the request came from a real Claude Code binary.¹²

This is effectively API DRM. Call it attestation if you want the neutral term.

From a security engineering perspective, it is understandable. If you want to prevent gray-market clients from replaying first-party privileges, you need something stronger than a static header. From an ecosystem perspective, it explains why Anthropic was willing to fight third-party wrappers so aggressively. The company was not just policing branding. It was protecting a technical enforcement boundary.

The rest was revealing, weird, or both

The leak also surfaced a pile of smaller details that collectively humanize the codebase while exposing its edges.

There were 187 hardcoded spinner verbs, including "scurrying," "recombobulating," "topsy-turvying," "hullaballooing," and "razzmatazzing." They were not model generated. Someone wrote them by hand.⁶¹²

There was a frustration detector in userPromptKeywords.ts, built as a regex that matches phrases such as wtf, ffs, piece of shit, fuck you, and this sucks, then logs an is_negative: true analytics signal. It reportedly does not alter behavior. It just measures user pain. Rahat Hasan highlighted the code on X as evidence that Anthropic was tracking how often users rage at the assistant. Boris Cherny replied that the team literally visualizes this signal on an internal dashboard called the "fucks" chart.¹²¹³

That sounds absurd, but it is also normal product analytics in blunt form. If users are swearing at your tool, they are having a bad time. A cheap lexical detector is a reasonable metric.

The code also exposed model codenames, including Capybara and Mythos for a v8 line with one million token context, plus references to Numbat, Fennec, Tengu, and unreleased Opus 4.7 and Sonnet 4.8 identifiers.⁶¹² It included a buddy or companion system built as an April Fools Tamagotchi, complete with 18 species, rarity tiers, RPG stats, and a 1 percent shiny mechanic. Some species names were encoded via String.fromCharCode() to avoid obvious grep hits.⁶

It also reportedly revealed a compaction loop bug wasting around 250,000 API calls per day, fixed with three lines of code.⁶¹¹ That detail is funny, but it is also a reminder that the economics of agent systems are often dominated by tiny control-loop mistakes, not model prices.

The DMCA fiasco was both predictable and incompetent

Anthropic's legal response was faster than its containment plan. The company filed a DMCA notice aimed at the original leaked repository, often identified as nichxbt/claude-code. GitHub's initial enforcement swept far wider than intended and disabled more than 8,100 repositories, many of them unrelated.³¹⁴

Anthropic later called the mass takedown an accident and narrowed the request to the original repository plus 96 forks. GitHub restored the affected projects.³¹⁴ By then, the code was already mirrored broadly, including stripped versions on IPFS with telemetry removed.⁶¹¹

The collateral damage was not hypothetical. Theo Browne (t3.gg), one of the most visible developers in the JavaScript ecosystem, posted that his Claude Code fork had been disabled, despite containing no leaked source at all. His fork existed only because he had submitted a PR weeks earlier to edit a Claude Code skill file. "Absolutely pathetic," he wrote, sharing the GitHub takedown email.¹⁵ Thariq Shihipar, an engineer on the Claude Code team, replied acknowledging it was a "communication mistake" and linked to the retraction notice.¹⁶ Boris Cherny separately responded to broader criticism of the mass takedowns: "This was not intentional, we've been working with GitHub to fix it. Should be better now."¹⁷

When your DMCA sweep hits a developer with 200,000+ followers whose repo did not contain the leaked code, you have not contained the problem. You have created a second news cycle.

This is the part where 2012 internet instincts collide with 2026 internet reality.

DMCA can still remove convenient copies from centralized platforms. It cannot claw back a viral archive once mirrors, torrents, and content-addressed storage have taken over. The window for meaningful containment was measured in minutes. After that, legal action was mostly performative, and the overbreadth made Anthropic look careless twice in one day.

The deeper problem is that the takedown campaign accidentally validated the leak's significance. If the goal was to avoid giving more oxygen to the mirrors, nuking thousands of repositories achieved the opposite.

The clones changed the legal stakes immediately

The most consequential downstream event was not the mirroring. It was the speed of clean-room reimplementation.

Sigrid Jin, a 25-year-old UBC student, reportedly used a tiny human team, around ten OpenClaw agents, and OpenAI Codex to rewrite the project in Python within hours. The result, Claw-Code, reportedly passed 100,000 GitHub stars in about a day and was described as the fastest-growing repository on the platform.¹⁰¹¹¹⁸ A separate Rust effort, Claurst, pursued a clean-room reimplementation in a lower-level systems language.¹⁰¹¹

Then xAI reportedly handed Jin free Grok credits, which was less a business development move than an accelerant tossed onto an already burning PR problem.¹⁰

This is where the story stops being a simple leak and becomes a legal stress test. Traditional clean-room reimplementation depends on separation, time, and cost. AI-assisted rebuilding compresses all three. If agents can inspect behavior, generate replacement code, and iterate fast enough to produce a plausibly original implementation in hours, the traditional enforcement model starts to wobble.

Gergely Orosz argued that a Python rewrite produced this way is a new creative work, not a simple copy.⁶¹⁰ That question has not been tested cleanly in court. It will be. There is too much money at stake for it not to be.

There is also an irony Anthropic cannot easily dodge. Dario Amodei has previously implied that Claude wrote substantial portions of Claude Code. If the original product is heavily AI-generated and the clone is also AI-assisted, copyright arguments about authorship and originality get messy fast. A company can still assert rights in selection, arrangement, and human-directed contributions. It just does not get to pretend the facts are clean.

The Axios attack made the same day much worse

If this had been only a source leak story, it would already have been a bad day for npm. It was not.

Between 00:21 and roughly 03:20 or 03:29 UTC on March 31, attackers attributed by Google and Microsoft to the North Korea linked actor tracked as UNC1069, also known as Sapphire Sleet, compromised the Axios npm package by hijacking maintainer credentials and publishing malicious versions 1.14.1 and 0.30.4.⁴⁵ Those releases pulled in a malicious dependency and delivered WAVESHAPER.V2, a cross-platform RAT targeting Windows, macOS, and Linux. The malware used postinstall execution and attempted to self-delete after installation to reduce forensic visibility.⁴⁵

That is a serious incident on its own. Axios sits at or above 100 million weekly downloads in normal conditions.⁴ It is foundational plumbing.

Now add the Claude Code leak. Developers were suddenly racing to inspect packages, clone mirrors, diff behavior, and test rewrites. Claude Code itself uses Axios for HTTP, according to public analysis.⁶¹² The timing created a perfect trap: people poking around one major npm drama could easily ingest a second one.

The same week, LiteLLM was reportedly backdoored through a separate three-stage attack involving credential harvesting, Kubernetes lateral movement, and a systemd persistence mechanism.¹⁹ That pattern matters. These are not isolated anomalies. They are signals that the AI tooling stack has become a high-value target before it has developed mature operational defenses.

What this actually means

The first conclusion is the simplest. Source map leaks are preventable. This was not zero-day wizardry. It was packaging failure. Mature release pipelines catch this.

The second conclusion is more important. The real damage was not exposure of current source. It was exposure of hidden product direction. KAIROS, the anti-distillation controls, the memory hierarchy, the browser and swarm paths, the undercover behavior, the attestation layer, all of that tells competitors what Anthropic thinks matters next.

The third conclusion is that npm supply chain security is in worse shape than the industry wants to admit. One day delivered both a flagship proprietary code leak and a state-linked compromise of a core dependency. If you build on JavaScript, you are operating in an ecosystem where trust is routinely transitive, under-verified, and easy to abuse.

The fourth conclusion is that DMCA is a weak response to decentralized distribution. It still works against convenience. It does not work against determined replication. Once the code hit IPFS and derivative rewrites started shipping, the takedown fight was already strategically lost.

The fifth conclusion is the one lawyers are going to spend years arguing about. AI-assisted clean-room builds change the economics of copyright enforcement. The doctrine was built for human teams, documentation walls, and long timelines. Agentic reimplementation collapses those assumptions. Courts can try to map old rules onto the new process. They cannot unmake the speed advantage.

My take is blunt: Anthropic's worst mistake was not leaking code. It was failing to understand what kind of secret it was actually protecting. Implementation details matter. Operational ideas matter more. If you keep your roadmap executable inside a public artifact pipeline, a packaging mistake becomes strategic intelligence loss.

And if your response is to spray DMCA notices while the ecosystem is actively digesting a nation-state npm compromise, you are not operating from strength. You are operating from panic.

Notes

Jeremy Kahn, "Anthropic source code for Claude Code leaked after data packaging error," Fortune, March 31, 2026, https://fortune.com/2026/03/31/anthropic-source-code-claude-code-data-leak. ↩
Ravie Lakshmanan, "Claude Code Source Leaked via npm Packaging Error, Anthropic Confirms," The Hacker News, April 2026, https://thehackernews.com/2026/04/claude-code-tleaked-via-npm-packaging.html. ↩
Maxwell Zeff, "Anthropic took down thousands of GitHub repos in DMCA mistake, then walked it back," TechCrunch, April 1, 2026, https://techcrunch.com/2026/04/01/anthropic-took-down-thousands-of-github-repos. ↩
Austin Larsen et al., "North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack," Google Cloud Blog, April 1, 2026, https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package. ↩
Microsoft Threat Intelligence, "Mitigating the Axios npm package compromise," Microsoft Security Blog, April 1, 2026, https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios. ↩
"Diving into Claude Code's Source Code Leak," Engineer's Codex, March 31, 2026, https://read.engineerscodex.com/p/diving-into-claude-codes-source-code. ↩
Srinivasan Balakrishnan, "Claude Code's source code appears to have leaked via npm package sourcemap," VentureBeat, March 31, 2026, https://venturebeat.com/technology/claude-codes-source-code-appears-to-have-leaked. ↩
"Bun's frontend development server: Source map incorrectly served when in production," GitHub issue oven-sh/bun#28001, filed March 11, 2026, https://github.com/oven-sh/bun/issues/28001. ↩
Alex Kim, "The Claude Code Source Leak: fake tools, frustration regexes, undercover mode, and more," March 31, 2026, https://alex000kim.com/posts/2026-03-31-claude-code-source-leak. ↩
Hugh Langley, "Claude Code leak reveals features, sparks clone wars, and raises legal questions," Business Insider, April 2026, https://www.businessinsider.com/claude-code-leak-what-happened-recreated-python-features-revealed-2026-4. ↩
Lee Sustar, "The Claude Code source leak," Layer5 Engineering Blog, 2026, https://layer5.io/blog/engineering/the-claude-code-source-leak. ↩
Alex Kim, "The Claude Code Source Leak: fake tools, frustration regexes, undercover mode, and more," March 31, 2026, https://alex000kim.com/posts/2026-03-31-claude-code-source-leak. ↩
Rahat Hasan (@Rahatcodes) and Boris Cherny (@bcherny), posts on X discussing Claude Code frustration analytics and the internal "fucks" chart, March 31, 2026. ↩
Michael Kan, "Anthropic Issues 8,000 Copyright Takedowns, Then Reverses Course," PCMag, April 1, 2026, https://www.pcmag.com/news/anthropic-issues-8000-copyright-takedowns. ↩
Theo Browne (@theo), post on X regarding DMCA takedown of t3dotgg/claude-code fork, April 1, 2026, https://x.com/theo/status/2039411851919057339. ↩
Thariq Shihipar (@trq212), reply to Theo Browne on X, April 1, 2026, https://x.com/trq212/status/2039415036645679167. ↩
Boris Cherny (@bcherny), response to broader DMCA criticism on X, April 1, 2026, https://x.com/bcherny/status/2039426466094731289. ↩
"Claude Code leak spawns fastest-growing GitHub repo ever," Cybernews, April 2026, https://cybernews.com/tech/claude-code-leak-spawns-fastest-github-repo. ↩
Thomas Claburn, "Axios npm backdoor RAT lands amid wider package security chaos," The Register, March 31, 2026, https://www.theregister.com/2026/03/31/axios_npm_backdoor_rat/. ↩

Claude Mythos: What We Actually Know (and What We Don't)

Solomon Neas — Tue, 31 Mar 2026 01:09:36 +0000

On March 26, 2026, Fortune broke a story that Anthropic had accidentally exposed details of an unreleased AI model through a misconfigured content management system.¹ The model is called Claude Mythos. Anthropic confirmed it exists, called it a "step change" in capabilities, and said it's already being tested by early access customers.²

Within 48 hours, the cybersecurity sector shed billions in market cap, unverified claims about 10 trillion parameters were circulating on social media, and half the AI commentary space was writing eulogies for the cybersecurity industry. The actual verified reporting tells a more interesting story than the hype cycle.

How the Leak Happened

The leak came from Anthropic's own content management system. Digital assets uploaded through the CMS were set to public by default unless someone explicitly changed the setting to private. Nearly 3,000 assets that had never been published to Anthropic's website were sitting in a publicly searchable data store, accessible to anyone with the technical knowledge to query it.¹

The discovery was made independently by Roy Paz, a senior AI security researcher at LayerX Security, and Alexandre Pauwels, a cybersecurity researcher at the University of Cambridge. Fortune confirmed and reviewed the material before publishing.¹

Among the exposed documents was a draft blog post announcing Claude Mythos. The post was structured as a web page with headings and a publication date, suggesting it was part of a planned product launch. After Fortune contacted Anthropic, the company secured the data store and acknowledged the leak was caused by "human error in the CMS configuration."³

There's real irony here. A company that builds AI models it says pose "unprecedented cybersecurity risks" got caught leaving internal documents in an unsecured public data store because someone forgot to flip a toggle. Anthropic was quick to clarify that Claude, Cowork, and their other AI tools were not involved in the configuration error.³

What the Draft Blog Post Actually Says

The leaked draft describes Claude Mythos as "by far the most powerful AI model we've ever developed." It introduces a new tier of Claude models called Capybara, positioned above Opus in Anthropic's existing lineup of Opus, Sonnet, and Haiku.²

Two versions of the draft blog post surfaced online, identical except for the model name: one uses "Mythos," the other uses "Capybara." Both versions use the same subtitle ("We have finished training a new AI model: Claude Mythos") and the same justification for the name, saying it was chosen to evoke "the deep connective tissue that links together knowledge and ideas."⁴ Anthropic appears to have been deciding between the two names.

The key claims from the draft:

Training is complete. The model is being trialed by early access customers.
Performance is described as "dramatically higher scores on tests of software coding, academic reasoning, and cybersecurity, among others" compared to Claude Opus 4.6.²
The model is "very expensive for us to serve, and will be very expensive for our customers to use." Anthropic says it needs to make it "much more efficient before any general release."⁴
The rollout will start with cybersecurity-focused early access customers, with API access expanding gradually.⁴

Anthropic's official statement to Fortune: "We're developing a general purpose model with meaningful advances in reasoning, coding, and cybersecurity. Given the strength of its capabilities, we're being deliberate about how we release it. As is standard practice across the industry, we're working with a small group of early access customers to test the model. We consider this model a step change and the most capable we've built to date."²

The Cybersecurity Angle

This is where the story gets interesting for anyone in security.

The leaked draft describes Mythos as "currently far ahead of any other AI model in cyber capabilities." It warns that the model "presages an upcoming wave of models that can exploit vulnerabilities in ways that far outpace the efforts of defenders."²

Anthropic's plan, according to the draft, is to give defenders a head start: "We're releasing it in early access to organizations, giving them a head start in improving the robustness of their codebases against the impending wave of AI-driven exploits."²

This is not coming out of nowhere. Anthropic has been building toward this capability in public for months.

In February 2026, Anthropic launched Claude Code Security, a tool built into Claude Code that scans codebases for vulnerabilities and suggests patches for human review. Unlike traditional static analysis tools that match code against known vulnerability patterns, Claude Code Security reads and reasons about code the way a human security researcher would, tracing data flows and catching complex flaws that rule-based tools miss.⁵

The same month, Anthropic's Frontier Red Team published research showing that Claude Opus 4.6 had found over 500 high-severity vulnerabilities in production open-source codebases. These were bugs that had gone undetected for decades despite years of expert review and millions of hours of automated fuzzing.⁶ One example: Claude found a memory corruption vulnerability in GhostScript by reading the Git commit history, identifying a security-relevant patch, and then finding an unpatched code path where the same class of bug still existed.⁶

And in November 2025, Anthropic disclosed that it had detected and disrupted what it called the first documented large-scale AI-orchestrated cyber espionage campaign. A Chinese state-sponsored group had manipulated Claude Code into attempting infiltration of roughly thirty global targets, including tech companies, financial institutions, and government agencies. The AI performed 80 to 90 percent of the campaign, with human intervention required at only four to six critical decision points.⁷

If Mythos represents a real improvement over Opus 4.6 in these capabilities, both sides of the security equation just shifted.

The Market Reaction

Cybersecurity stocks took a beating on Friday, March 27. The iShares Cybersecurity ETF dropped 4.5%. CrowdStrike, Palo Alto Networks, and Zscaler each fell about 6%. SentinelOne dropped 6%. Okta and Netskope fell over 7%. Tenable plummeted 9%.⁸

This wasn't the first time. Cybersecurity stocks had already dipped in February when Anthropic launched Claude Code Security.⁸ The sector has been under persistent pressure from the growing narrative that AI models will automate vulnerability discovery faster than security vendors can keep up.

Some analysts pushed back on the panic. Borg at a financial research firm argued that the news should actually be bullish for cybersecurity spend long-term, since companies will need to accelerate adoption of AI-infused security tools to respond to AI-powered attacks at machine speed.⁹

The short-term read from the market was simpler: if an AI model can find exploits faster than your security product, your security product has a problem.

What We Don't Know

Here's where the verified reporting ends and the speculation begins.

Parameter count: Claims of 10 trillion parameters have been circulating widely. This number does not appear in Fortune's reporting or in Anthropic's official statements. As one Substack writer noted, "new and unconfirmed details, ten trillion parameters, ten billion dollars to train, were circulating alongside claims that came directly from Fortune's reporting" within hours of the original story.¹⁰ Treat it as unverified.

Benchmarks: We have Anthropic's claim of "dramatically higher scores" over Opus 4.6 in coding, reasoning, and cybersecurity. We do not have specific benchmark numbers, leaderboard rankings, or third-party evaluations.

Release timeline: The draft describes early access testing and acknowledges the model needs to become more efficient before general release. No date has been given.

Final naming: Whether the model ships as Mythos, Capybara, or something else entirely is still undecided, based on the existence of two draft versions.⁴

Whether the hype is warranted: Remember GPT-5. OpenAI made similar claims about a transformative leap in capabilities. The actual release was widely considered a disappointment that fell short of the company's promises.¹¹ Frontier model announcements and frontier model performance in the real world are not the same thing.

The Competitive Context

Anthropic is not the only company pushing the frontier right now. OpenAI has reportedly finished pretraining a new model codenamed "Spud," with CEO Sam Altman internally claiming it can "really accelerate the economy."¹² Both companies are expected to time their strongest model releases ahead of planned IPOs later this year.⁴

The pattern is familiar. Each lab announces a step change, each release comes with safety caveats and controlled rollouts, and each time the actual impact takes months to assess once the models are in the hands of real users.

What makes the Mythos leak different from the usual release cycle is the cybersecurity dimension. Anthropic did not choose to reveal this model. And the information that leaked was not marketing copy optimized for launch day. It was internal planning documents that included frank assessments of the risks.

What This Means for Defenders

If you work in cybersecurity, the takeaway is not "AI is going to replace your job." It's "the tools available to attackers just got substantially better, and the tools available to you did too."

Anthropic's decision to give cybersecurity organizations early access to Mythos is a signal about where they think the model's impact will be felt first. Their own track record with Opus 4.6 supports that: 500+ zero-days found in hardened open-source projects, a documented state-sponsored campaign disrupted, and a vulnerability scanning tool that reasons about code instead of pattern-matching against known signatures.

The models are getting better at finding bugs. The question is whether defenders adopt these capabilities faster than attackers do. That's always been the question in security. The tools just got a lot more powerful on both sides.

Notes

Originally published at solomonneas.dev. Follow me for more security engineering and AI infrastructure content.

Jeremy Kahn, "Exclusive: Anthropic Left Details of Unreleased AI Model, Exclusive CEO Event, in Unsecured Database," Fortune, March 26, 2026, https://fortune.com/2026/03/26/anthropic-leaked-unreleased-model-exclusive-event-security-issues-cybersecurity-unsecured-data-store/. ↩
Jeremy Kahn, "Exclusive: Anthropic 'Mythos' AI Model Representing 'Step Change' in Power Revealed in Data Leak," Fortune, March 26, 2026, https://fortune.com/2026/03/26/anthropic-says-testing-mythos-powerful-new-ai-model-after-data-leak-reveals-its-existence-step-change-in-capabilities/. ↩
Kahn, "Exclusive: Anthropic Left Details." ↩
Matthias Bastian, "Anthropic Leak Reveals New Model 'Claude Mythos' with 'Dramatically Higher Scores on Tests' Than Any Previous Model," The Decoder, March 27, 2026, https://the-decoder.com/anthropic-leak-reveals-new-model-claude-mythos-with-dramatically-higher-scores-on-tests-than-any-previous-model/. ↩
Anthropic, "Making Frontier Cybersecurity Capabilities Available to Defenders," Anthropic News, February 20, 2026, https://www.anthropic.com/news/claude-code-security. ↩
Nicholas Carlini et al., "0-Days," Anthropic Frontier Red Team, February 5, 2026, https://red.anthropic.com/2026/zero-days/. ↩
Anthropic, "Disrupting the First Reported AI-Orchestrated Cyber Espionage Campaign," Anthropic News, November 2025, https://www.anthropic.com/news/disrupting-AI-espionage. ↩
Jordan Novet, "Cybersecurity Stocks Fall on Report Anthropic Is Testing a Powerful New Model," CNBC, March 27, 2026, https://www.cnbc.com/2026/03/27/anthropic-cybersecurity-stocks-ai-mythos.html. ↩
"Cybersecurity Stocks Plunge as Anthropic's 'Claude Mythos' Leak Sparks AI Fear," Investing.com, March 28, 2026, https://www.investing.com/news/stock-market-news/cybersecurity-stocks-plunge-as-anthropics-claude-mythos-leak-sparks-ai-fear-4584897. ↩
Stephen Fitzpatrick, "What the Heck Is Mythos?" Substack, March 30, 2026, https://fitzyhistory.substack.com/p/what-the-heck-is-mythos. ↩
"GPT-5 Turned Out to Be a Major Letdown," Futurism, accessed March 30, 2026, https://futurism.com/gpt-5-disaster. ↩
"OpenAI CEO Sam Altman Reportedly Teases a 'Very Strong' Model Internally That Can 'Really Accelerate the Economy,'" The Decoder, accessed March 30, 2026, https://the-decoder.com/openai-ceo-sam-altman-reportedly-teases-a-very-strong-model-internally-that-can-really-accelerate-the-economy/. ↩

Replacing SCCM with FOG Project

Solomon Neas — Sun, 29 Mar 2026 23:33:08 +0000

Replacing SCCM with FOG Project

When I moved our infrastructure from Hyper-V to Proxmox, I also took the chance to rip out one of the heaviest pieces of the old stack: SCCM.

For an enterprise with thousands of endpoints and a full Microsoft licensing budget, SCCM can make sense. For four instructional labs with 72 workstations, it was too much. It wanted Windows Server, SQL Server, licensing baggage, and constant babysitting just to do the thing I actually needed: boot a machine over the network, lay down a clean image, put it back in the domain, and get out of the way.

FOG Project was the answer.

This post is the technical deep-dive for the imaging side of the migration. For the full Hyper-V to Proxmox migration story, see the migration deep-dive.

The environment I was replacing

The target was straightforward on paper:

4 classrooms
72 total workstations
3 hardware-specific Windows 11 images
47 machines with known MAC addresses at import time
25 machines that would need to self-register on first PXE boot
Active Directory domain join after imaging
Room-specific OU placement

The architecture ended up looking like this:

FOG server: Debian Trixie 13 LXC on Proxmox, 10.0.1.20
Domain controllers / DHCP: Windows Server, 10.0.1.10 and 10.0.1.11
Domain: LAB.LOCAL
Join account: svc-domainjoin@LAB.LOCAL
Rooms: Room-A, Room-B, Room-C, Room-D
Images: Win11-Lab-G4, Win11-Lab-Ultrawide, Win11-Lab-G9

I did not build images in Proxmox VMs. I built them on reference machines that matched the real lab hardware. The rooms were not identical. One had HP G4s, one had HP G9s, and two rooms had Dell FCT2250s paired with Dell UltraSharp 49" curved monitors (U4924DW/U4919DW), which needed their own driver set.

Three golden images, three hardware profiles:

Room	Image
Room-A	Win11-Lab-G4
Room-B	Win11-Lab-Ultrawide
Room-C	Win11-Lab-Ultrawide
Room-D	Win11-Lab-G9

Active Directory prep

The Linux box gets the attention in a FOG write-up, but the boring Windows prep is what made the deployment clean.

I created a least-privilege service account called svc-domainjoin and delegated only what FOG needed on the classroom OUs: create computer objects, delete computer objects, and full control on descendant computer objects.

The OU layout was one OU per room. Then I delegated permissions with dsacls:

dsacls "OU=Room-A,DC=LAB,DC=LOCAL" /I:T /G "LAB\svc-domainjoin:CC;computer"
dsacls "OU=Room-A,DC=LAB,DC=LOCAL" /I:T /G "LAB\svc-domainjoin:DC;computer"
dsacls "OU=Room-A,DC=LAB,DC=LOCAL" /I:S /G "LAB\svc-domainjoin:GA;;computer"

Same pattern on all four classroom OUs.

Before touching imaging at all, I cleaned house in AD: moved 38 misplaced computer objects into the right OUs, deleted 60 stale ones from old naming schemes, unlinked the SCCM GPO from the room OUs, and exported a CSV of all 72 lab machines.

Then I set DHCP options 66 and 67 on the classroom scopes to point to FOG:

Option 66: 10.0.1.20
Option 67: initially ipxe.efi

Should have been enough. It was not.

The SCCM ghost in DHCP

PXE still misbehaved on some scopes even with the scope-level options pointing to FOG.

The culprit was stale SCCM and WDS policies still attached to several scopes. DHCP policies take priority over scope options. Clients matching the PXE vendor class were quietly getting sent to the retired SCCM server at 10.0.1.14 instead of FOG at 10.0.1.20. The old policies referenced smsboot\x64\wdsmgfw.efi and smsboot\x64\wdsnbp.com with the old boot server IP.

Eleven of those policies, spread across five scopes. Once I removed them all, PXE stopped getting hijacked by dead infrastructure.

Note: If PXE settings look right but clients keep booting somewhere else, check DHCP policies before you blame FOG.

FOG on Debian Trixie: three bugs in a trenchcoat

The FOG server was a Debian 13 LXC container on Proxmox. When I first looked at it, the web UI was running, which made it look installed.

It was not. The backend was missing entirely. No TFTP boot files. No NFS exports. No FOG services. The web UI was a shell with nothing behind it.

Re-ran the installer:

cd /tmp/fogproject/bin
bash installfog.sh -y

Trixie had other plans.

Bug 1: wrong `osid`

FOG had the wrong OS ID in .fogsettings. It detected the machine as Arch Linux instead of Debian. Fix in /opt/fog/.fogsettings:

osid='3'

to:

osid='2'

Without that, every package operation targeted the wrong distro.

Bug 2: `libcurl4` renamed on Debian 13

Debian 13's t64 transition renamed libcurl4 to libcurl4t64. FOG's installer still asked for the old name. I patched the package check in functions.sh to handle Debian >= 13.

Bug 3: `lastlog` became `lastlog2`

FOG's installer checks lastlog to verify user creation. Trixie dropped it for lastlog2. Quick fix:

apt-get install -y lastlog2
ln -sf /usr/bin/lastlog2 /usr/local/bin/lastlog

Once I patched all three, the installer completed and the backend finally matched the web UI.

NFS inside LXC: the container wall

With the installer patched, the next wall was image storage. FOG uses NFS for capture and deployment. Inside a Proxmox LXC container, kernel NFS does not cooperate:

mount: /proc/fs/nfsd: permission denied

I tried the usual Proxmox container feature flags:

pct set <CTID> -features nesting=1,nfs=1
pct reboot <CTID>

Better, but still not a reliable kernel NFS server. I stopped fighting it and went userspace: nfs-ganesha.

apt install nfs-ganesha nfs-ganesha-vfs

One annoying gotcha: Ganesha's pseudo paths cannot nest. Having /images and /images/dev as pseudo paths breaks child lookup. I had to flatten the namespace.

The working /etc/ganesha/ganesha.conf:

NFS_CORE_PARAM {
    Protocols = 3,4;
    mount_path_pseudo = true;
    allow_set_io_flusher_fail = true;
}

EXPORT {
    Export_Id = 1;
    Path = /images;
    Pseudo = /images;
    Protocols = 3,4;
    Access_Type = RO;
    Squash = no_root_squash;
    FSAL { Name = VFS; }
    CLIENT { Clients = *; Access_Type = RO; }
}

EXPORT {
    Export_Id = 2;
    Path = /images/dev;
    Pseudo = /imagesDev;
    Protocols = 3,4;
    Access_Type = RW;
    Squash = no_root_squash;
    FSAL { Name = VFS; }
    CLIENT { Clients = *; Access_Type = RW; }
}

The critical line for LXC: allow_set_io_flusher_fail = true;. Without it, Ganesha dies with EPERM on PR_SET_IO_FLUSHER. That flag lets it skip the kernel call and keep running.

Verify with showmount -e localhost and rpcinfo -p localhost. If both look right, NFS is serving.

Note: Kernel NFS in LXC was a dead end. Userspace NFS was the practical way through it.

The golden image pipeline

With the server side stable, the real work was image prep. Same process every time:

clean install Windows 11 on the reference machine
install drivers, software, updates, and room-specific settings
keep it off the domain
install the FOG client if needed for post-deploy tasks
clean it aggressively
sysprep and shut down
PXE boot and capture in FOG

Step 5 became its own thing. The cleanup one-liner I kept copy-pasting between machines. Ugly, but it works:

Stop-Service wuauserv -Force; Remove-Item C:\Windows\SoftwareDistribution\* -Recurse -Force -EA SilentlyContinue; Start-Service wuauserv; Dism /online /Cleanup-Image /StartComponentCleanup /ResetBase; Remove-Item C:\Windows\Panther\* -Recurse -Force -EA SilentlyContinue; Remove-Item C:\Windows\Temp\* -Recurse -Force -EA SilentlyContinue; Remove-Item C:\Windows\Prefetch\* -Recurse -Force -EA SilentlyContinue; Remove-Item "$env:TEMP\*" -Recurse -Force -EA SilentlyContinue; Clear-RecycleBin -Force -EA SilentlyContinue; cleanmgr /sagerun:1; C:\Windows\System32\Sysprep\sysprep.exe /oobe /generalize /shutdown

I started calling it the Frankenstein command. It's stitched together from half a dozen different guides and does way too much in one line. But for repeatable image prep, it earned its place.

Broken down:

Stop-Service wuauserv -Force / Remove-Item SoftwareDistribution / Start-Service wuauserv: kill Windows Update, nuke the cache, bring it back.
Dism /online /Cleanup-Image /StartComponentCleanup /ResetBase: collapse superseded component versions. Frees real space.
The four Remove-Item lines: purge Panther logs, system temp, Prefetch, and user temp.
Clear-RecycleBin: self-explanatory.
cleanmgr /sagerun:1: Disk Cleanup with preconfigured settings.
sysprep.exe /oobe /generalize /shutdown: strip machine identity, stage OOBE, power off.

Note: After sysprep shuts the machine down, do not let it boot back into Windows before capture. If it does, you just spent your sysprep state and get to do it again.

Sysprep on Windows 11: Appx package hell

The worst part of this project was not FOG. It was Sysprep.

If you've fought Windows 11 Sysprep before, you know the error. If you haven't, it looks like this in the Panther logs:

Sysprep was not able to validate your Windows installation.

More specifically:

Package <app> was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.
Failed to remove apps for the current user: 0x80073cf2.

On Windows 11 23H2 and 24H2, the Microsoft Store silently updates Appx packages per-user. That creates a version mismatch between the installed state and the provisioned state. Sysprep sees it, panics, refuses to generalize.

What I tried that did not work:

Remove-AppxPackage -AllUsers
Remove-AppxProvisionedPackage
the mythical SkipAppxValidation registry setting
editing Generalize.xml
renaming AppxSysprep.dll

Some fail outright. Some appear to work, then the packages come back after a reboot. Some just swap one error for a different one.

What actually worked: changing the source image entirely.

I used Chris Titus Tech's WinUtil to build a MicroWin ISO. Instead of installing stock Windows and spending hours ripping Store junk back out, I started from a clean ISO that never had the Appx baggage in the first place.

Prevention over cleanup:

build MicroWin ISO
install on the reference machine
configure drivers and software
disconnect from the network before sysprep if needed
run the cleanup command
sysprep, shut down, capture immediately

That was the difference between fighting Sysprep every time and having it just work.

PXE on newer hardware: `snponly.efi`

One more issue that looked like FOG but wasn't. A newer motherboard would download ipxe.efi, start up, and freeze at:

iPXE initializing devices...

No ok. Just stuck.

iPXE's built-in NIC driver couldn't handle the newer chipset. The fix: switch DHCP option 67 from ipxe.efi to snponly.efi.

The difference is simple. ipxe.efi ships its own NIC drivers. snponly.efi delegates to the UEFI firmware's native SNP driver. On newer boards, the firmware driver works where iPXE's doesn't.

One DHCP change, ipxe.efi to snponly.efi, and the machine booted straight to the FOG menu. It became the default for all our UEFI clients.

72 systems, deployed by room

With images captured and PXE stable, FOG could finally do its job.

Bulk imported the workstation list from CSV:

47 had MAC addresses ready for direct import
25 had no active lease at the time, so they were left to auto-register when first PXE booted

Each host got the right image and room group. Deploying a room was: select the group, schedule a deploy task, PXE boot the room. That's it.

FOG uses Partclone under the hood, so it only transfers used blocks. A 500 GB drive with 30 GB used doesn't push 500 GB over the wire. It pushes roughly 30 GB, compressed. Room-wide imaging is faster than people expect.

After deployment, the FOG client sets the hostname, joins the domain via svc-domainjoin, and drops the computer object in the correct OU. Multicast is also available for imaging an entire room simultaneously.

What I learned

Setting up FOG is not just "install FOG." It's DHCP policy archaeology, AD delegation, Windows image hygiene, boot loader compatibility, and the reality of running services inside Linux containers.

The short list:

DHCP policies override scope options. Check for leftover WDS/SCCM policies before blaming FOG.
A running web UI does not mean FOG is installed. Verify TFTP, services, and NFS.
FOG on Debian Trixie needs manual patches. osid, libcurl4t64, lastlog2.
Kernel NFS in Proxmox LXC is a dead end. Use nfs-ganesha.
Build images on reference machines. VM images don't carry driver quirks correctly.
Debloat before install, not after. MicroWin saves hours of Appx cleanup.
Test Sysprep on something disposable first. Appx breakage on your finished image is a bad time.
snponly.efi for newer hardware. If iPXE hangs at device init, switch boot files.
Never boot a sysprepped machine before capture. Generalize is one-shot.
FOG's hostName is VARCHAR(16). Plan your naming accordingly.

Once the rough edges were filed down, the day-to-day got simple. Pick the room. PXE boot. Image. Domain join. Done. Way less overhead than SCCM ever was.

That's the kind of boring I want from lab infrastructure.

This post is part of a larger infrastructure migration series. For the full Hyper-V to Proxmox migration story, see the project page on solomonneas.dev.

Originally published at solomonneas.dev.

I Built 7 MCP Servers for Security Tools. The Protocol Was the Easy Part.

Solomon Neas — Mon, 23 Mar 2026 20:59:54 +0000

I wanted my AI agent to talk directly to my security stack. Not through copy-pasted log snippets. Not through screenshots of dashboards. Actual tool calls against live data.

So I built seven MCP servers. Wazuh. Suricata. Zeek. TheHive. Cortex. MISP. MITRE ATT&CK. All open source, all on my GitHub. Project page: https://solomonneas.dev/projects/security-mcp-servers.

The protocol layer took a weekend. The context engineering took weeks. That ratio surprised me.

What I Actually Built

API-based servers talk directly to running services. Wazuh MCP hits the manager's REST API on port 55000 for alerts, agent status, vulnerability scans, and file integrity events. TheHive and Cortex connect to their respective APIs for case management and observable analysis. MISP pulls threat intelligence feeds and IOC lookups.

Log-based servers parse files on disk. Zeek MCP reads from a log directory (JSON or TSV format), letting you query connection logs, DNS, HTTP, SSL, and file analysis data. Suricata MCP reads EVE JSON logs for IDS alerts, flow data, and protocol metadata.

Knowledge-base servers work offline. The MITRE ATT&CK server downloads STIX 2.1 bundles and lets you query techniques, tactics, groups, software, and mitigations without hitting any external API.

Each server exposes a focused set of tools. Wazuh has get_alerts, list_agents, get_vulnerabilities, get_fim_events. Zeek has query_connections, search_dns, get_ssl_certs. Suricata has get_alerts, get_flow_stats, search_protocols.

Every tool does one thing with predictable output. Full code and docs at github.com/solomonneas.

Testing Against Live Infrastructure

Every server got tested against real running services on my home infrastructure.

Wazuh MCP was tested against my Wazuh 4.14.1 instance running on Proxmox. I queried live alerts, pulled agent status for my connected machines, ran vulnerability scan results, and verified file integrity monitoring events. The agent reconnection workflow got tested end-to-end: listing disconnected agents, checking last keep-alive, triggering restarts.

Zeek and Suricata servers were tested against actual captured traffic. Real log files through both parsers, connection correlation across source/destination pairs, DNS query lookups, and stress-tested time-window filtering with large log directories. Edge cases like malformed log entries and mixed JSON/TSV formats got handled explicitly.

TheHive and Cortex were tested against their APIs with sample cases and observables. MISP was tested with real IOC lookups. The MITRE ATT&CK server was verified against the full STIX 2.1 enterprise bundle.

The goal was not just "does the tool call succeed." It was "does the model get back data it can actually reason about for a real investigation."

Context Design Is the Real Engineering

Security telemetry is exactly the kind of data language models handle poorly. It's verbose, repetitive, and full of fields that matter sometimes and are noise the rest of the time.

Take Wazuh alerts. A single alert has 40+ fields. Dump all of that into a model and ask it to "analyze the situation." You'll get a vague summary that touches everything and understands nothing.

My first versions returned raw API responses. The model would pick whatever fields were easiest to talk about instead of whatever actually mattered.

So I started designing the context layer. For Wazuh, I filter to severity 8+ by default and return a focused subset: timestamp, rule description, agent name, source IP, and MITRE technique. For Zeek, I pre-aggregate by source/destination pair and surface unusual patterns first. For Suricata, I separate IDS alerts from flow metadata. Detections first, network context second.

Where It Gets Interesting

A Wazuh alert fires for a suspicious process. The model checks Zeek for that host's network activity. Finds outbound connections to an unusual IP. Queries ATT&CK for technique mapping. Checks MISP for threat intel on the destination.

That correlation chain used to take 15 minutes of clicking through interfaces. Now it takes one question.

I'm not replacing analysts. I'm killing the mechanical evidence-gathering that burns time before a human reaches the real decisions.

The Lesson

The protocol is a solved problem. MCP works. The bottleneck is what happens between raw data and the model's context window. Filtering, ordering, scoping, pre-summarizing. That's where analysis quality is determined.

A model with access to every field in every log is worse off than one that sees the right 15 fields in the right order.

Seven servers. All open source. All tested against live infrastructure. Code at github.com/solomonneas. The protocol was a weekend. The context design is ongoing. That's the ratio that matters.

I Migrated Our Entire Infrastructure from Hyper-V to Proxmox. Here's Everything I Learned.

Solomon Neas — Sat, 14 Mar 2026 06:45:04 +0000

Domain controllers, file servers, network monitoring, imaging, WiFi controllers. All of it moved from Microsoft to open source. No downtime. No data loss. Here's the complete playbook.

Why We Left Hyper-V

Broadcom acquired VMware and started charging $350/core/year for VCF licensing. They killed the VMware IT Academy program entirely. The institution moved from vSphere to Hyper-V as a cost-saving measure, but I'd already done a VMware to Proxmox migration on my own infrastructure at that point. That migration opened my eyes to how good Proxmox actually is.

It's more lightweight. The web UI gives you more granular control than Hyper-V Manager ever did. Snapshots, live migration, ZFS, LXC containers, and full KVM virtualization all in one platform. Completely free. No per-socket licensing, no Windows Server dependency, no CALs. One less thing Microsoft gets to hold over your budget.

Hyper-V felt heavy by comparison. Limited Linux VM support, clunky management (RDP into the host just to touch anything), and tight coupling to Windows Server licensing. Once I'd seen what Proxmox could do, going back to Hyper-V felt like a downgrade.

The question was never "should we migrate?" It was "how do we migrate production Active Directory, network monitoring, file servers, and imaging infrastructure without breaking anything?"

The Power of Root on a Proxmox Host

One thing that surprised me coming from Hyper-V: you have full root access to the Proxmox host. It's just Debian under the hood. You can SSH in, run any Linux command, script anything, automate everything. Hyper-V locks you into PowerShell remoting or RDP. Proxmox gives you a real shell on a real Linux system.

Need to resize a disk? One command. Snapshot a VM? One command. Migrate a VM between hosts? One command. Everything in the web UI is also available from the CLI through qm (VM management), pct (container management), pvesm (storage), and pvecm (cluster). You can script your entire infrastructure.

But the real game changer is the Proxmox VE Helper Scripts community project. These are one-liner bash scripts that spin up fully configured LXC containers or VMs for common services. Need a Pi-hole? One command. Docker host? One command. Home Assistant, Nginx Proxy Manager, Plex, Grafana, Wireguard? One command each.

# Example: spin up a Docker LXC in seconds
bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/docker.sh)"

The script handles everything: downloads the template, creates the container, configures networking, installs the service, and starts it. What would take 30 minutes of manual setup takes 60 seconds. I used these for several of our auxiliary services and they just work.

Compare that to Hyper-V where deploying a new service means: create a VM, install Windows or manually download an ISO, walk through the installer, configure networking, install the actual application. The gap in operational speed is enormous.

The Domain Controller Leapfrog

This was the part that scared me most. Domain controllers are the heartbeat of a Windows network. Every authentication, every group policy, every DNS lookup flows through them. Get this wrong and the whole campus goes dark.

The conventional wisdom is clear: never V2V a domain controller. Converting a DC's virtual disk risks USN rollback, which permanently corrupts the AD replication database. There's no recovery path short of rebuilding the entire domain.

Instead, I used what I call the "leapfrog" method. We had two DCs: DC1 and DC2, both on Hyper-V.

Step 1: Transfer all five FSMO roles to DC2. Verify DHCP scopes, DNS zones, and AD replication are healthy. DC2 is now running the show.

Step 2: Delete DC1. Build a fresh Windows Server VM on Proxmox. Promote it to domain controller. AD replication syncs everything from DC2 automatically.

Step 3: Transfer all FSMO roles to the new DC1 on Proxmox. Verify everything.

Step 4: Delete DC2 on Hyper-V. Build fresh on Proxmox. Promote. AD replicates from DC1.

Both domain controllers are now on Proxmox. Zero downtime. Zero data loss. The whole process was honestly easier than I expected because AD replication just works when you let it do its job.

The PowerShell for the FSMO transfer is one command:

Move-ADDirectoryServerOperationMasterRole -Identity "NEW-DC1" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, `
  PDCEmulator, RIDMaster, InfrastructureMaster

Always verify with repadmin /showrepl after each promotion and transfer. If replication shows errors, stop and fix them before proceeding.

Linux VM Migration: The V2V Process

For Linux VMs (LibreNMS, Netdisco, Switchmap), I used direct disk conversion. The process:

Create a "shell" VM in Proxmox. Set the OS type, match the BIOS to the source Hyper-V generation (Gen 1 = SeaBIOS, Gen 2 = OVMF UEFI), but do not create a hard drive. The disk list should be empty.
SCP the VHDX from the Hyper-V host to Proxmox:

scp "C:\Path\To\Disk.vhdx" root@PROXMOX_IP:/var/lib/vz/dump/

Import and attach on the Proxmox side:

qm importdisk 102 /var/lib/vz/dump/Netdisco.vhdx local-lvm

Then in the GUI: Hardware > double-click Unused Disk 0 > add as SCSI. Set boot order to prioritize scsi0.

Post-migration gotchas:

Network interface names change (eth0 becomes ens18). Update your netplan config.
Install qemu-guest-agent so Proxmox can see the VM's IP and gracefully shut it down.
LibreNMS needed a full permissions reset. Run validate.php as the librenms user and follow every instruction it gives you.
Netdisco needed its database host changed to localhost in deployment.yml and a session cookie key added to prevent crashes.

Killing DFS, Simplifying Drive Maps

The old environment used a DFS namespace to abstract file server paths. For a single-server environment, DFS adds complexity that provides no benefit: 30-minute referral TTL, client cache issues, and another layer to troubleshoot when users can't access files.

I ripped it out and replaced it with Group Policy Preferences drive mappings using item-level targeting:

*X:\* mapped for faculty and staff, pointing to the full file server
*Y:\* mapped for students, pointing to the student folders only

Security group membership determines which mapping a user gets. No login scripts, no DFS, no namespace caching. If a user is in the Faculty-Staff group, they get X:\. If they're in the Students group, they get Y:\. Simple.

UniFi Controller: Windows VM to LXC Container

This one was almost comical. The UniFi controller was running on a Windows 11 VM inside Hyper-V. To manage the WiFi, you had to RDP into the Hyper-V host, then log into the Windows VM from there. No SSH. No remote management. Just nested RDP sessions.

The migration:

Export the UniFi backup (.unf file) from the Windows controller
Create an LXC container on Proxmox using the official UniFi template
Upload the .unf backup and restore

All WAP configurations, SSIDs, and client data came over intact. WiFi was back up in minutes. And now it runs in a lightweight container instead of a full Windows 11 VM. The resource savings alone made it worthwhile.

Replacing SCCM with FOG Project

Microsoft SCCM is powerful but absurdly heavy for an educational lab environment. It needs Windows Server, SQL Server, per-device licensing, and significant infrastructure just to image workstations.

FOG Project does everything we actually need: PXE boot imaging, hardware inventory, and centralized workstation management. It runs on Linux, costs nothing, and the web UI is straightforward.

The Golden Image Pipeline

I build golden images as Proxmox VMs (not on physical hardware) so I can snapshot before Sysprep. This is critical because if Sysprep fails, you cannot simply run it again. The only recovery is reverting to a snapshot.

Step 1: Install and debloat. Set up a clean Windows 11 installation on a reference machine. Run Chris Titus Tech's Windows Utility to strip all the bloatware (Candy Crush, Spotify, Xbox, etc.) and disable telemetry. This handles both installed and provisioned packages, which is important because leftover staged Appx packages are the number one cause of silent Sysprep failures.

Step 2: Sysprep and shutdown. Once the machine is configured how you want it, run sysprep.exe /generalize /oobe /shutdown /unattend:C:\Windows\Panther\unattend.xml. The unattend file handles BypassNRO (Windows 11's forced internet requirement) and automates the OOBE setup after deployment. The machine shuts down after Sysprep completes. Do not power it back on.

Step 3: FOG capture. Schedule a capture task in the FOG web UI for that machine, then PXE boot it. FOG captures the sysprepped image as-is, sitting at OOBE. When the image gets deployed to a workstation later, the unattend.xml automates the OOBE setup, the FOG service agent kicks in for background management, and AD auto-join handles domain membership. No manual touch required.

Per-Classroom Deployment

Each classroom has different hardware, so I maintain separate images per room. Every workstation is registered in FOG via CSV import (hostname + MAC address), grouped by classroom. When a room needs reimaging, I select the group, schedule a deploy task, and FOG uses Partclone to push the image. Partclone only writes used blocks, so imaging is fast even on large drives.

The FOG agent runs on every workstation with a dedicated fog-service Active Directory service account. DHCP points PXE boot to the FOG server using snponly.efi for UEFI network boot. A machine needing reimaging just needs to PXE boot and everything happens automatically.

WSUS: Closing the Update Loop

The last piece of the imaging puzzle was patch management. Without centralized updates, every golden image would need constant rebuilding just to stay current. And letting 60+ lab machines pull updates directly from Microsoft on their own schedule is a recipe for bandwidth problems and inconsistent states.

I set up WSUS (Windows Server Update Services) directly on DC1. For an environment this size (four classrooms and a handful of staff machines), a dedicated WSUS server would be overkill. Running it on the domain controller keeps the footprint small and the management simple.

The update pipeline works in two stages:

Test lab first. New updates land in WSUS but aren't auto-approved. I have a WSUS computer group for a small set of test machines. Updates get approved for the test group first. They run for about four to five days. This buffer is intentional: it's enough time for the community to flag zero-day issues, botched patches, or driver conflicts before anything hits production.

Then classrooms. After the test window passes clean, I approve updates for the classroom groups. WSUS pushes them from the local server, so machines pull patches over the LAN instead of each one hammering Microsoft's CDN individually. Faster downloads, less bandwidth, and every machine in a room ends up on the same patch level.

This also means the golden image for FOG doesn't need to be rebuilt every Patch Tuesday. WSUS handles ongoing patching after deployment. The golden image only needs updating when there's a major feature release or a change to the base software stack.

What I'd Do Differently

Document interface names before migration. Every Linux VM had a different post-migration network issue because the interface name changed. A quick ip link show before the migration would have saved debugging time.

Test Sysprep on a throwaway VM first. My first Sysprep attempt failed because of a leftover Xbox app. Always run through the full golden image pipeline once as a dry run before committing to your production image.

The SOC Stack

I also migrated the full security operations stack: Wazuh for endpoint detection and SIEM, Cortex for automated analysis, TheHive for case management, and MISP for threat intelligence sharing. Same V2V process as the other Linux VMs. These were already running on Linux, so it was disk conversion, interface rename, guest agent install, and verify services. Nothing special, but worth mentioning because people forget about their security tooling when planning hypervisor migrations.

The Final Tally

When everything was done, the infrastructure footprint looked like this:

4 standalone Proxmox servers running production workloads: domain controllers, network monitoring (LibreNMS, Netdisco, Switchmap), Samba AD file server, FOG imaging, UniFi controller, and the SOC stack (Wazuh, Cortex, TheHive, MISP)
6-node Proxmox cluster for the NetLab environment, where students run hands-on lab exercises
10 total Proxmox hosts, all on open-source infrastructure

Total hypervisor licensing cost: $0.

The migration took planning and careful execution, but none of it was technically complex. The hardest part was convincing myself that AD replication would actually work as advertised. It did.

Originally published at solomonneas.dev. Find more of my writing on infrastructure, security tooling, and AI agents at solomonneas.dev.