DEV Community: Solomon Neas

GPT-5.5 Is OpenAI's Workstation Model

Solomon Neas — Sun, 26 Apr 2026 20:55:33 +0000

OpenAI shipped a model built for work, not only chat.

GPT-5.5 is the clearest version yet of what OpenAI wants the high-end model lane to become: a workstation model. Less chatbot. More Codex, browser control, spreadsheets, documents, research loops, computer use, and long-running tool work.

That distinction matters because the launch makes more sense once you stop reading it as a normal model card race. OpenAI is saying something more specific than "GPT-5.5 is smarter than GPT-5.4." The model is supposed to carry more of the actual work: understand a messy goal, plan, use tools, check itself, move across software, and keep going until the task is finished.¹

That is the pitch. The interesting question is whether the early evidence backs it up.

My read: GPT-5.5 looks like a serious jump for agentic work, especially inside Codex. The launch-day fog cleared fast: API access arrived one day later and pricing is now official. The remaining caveats are cost, routing, mixed early developer reactions, and safety controls that will matter a lot for cyber and bio work.

What OpenAI Actually Released

OpenAI released GPT-5.5 on April 23, 2026. The base model rolled out to Plus, Pro, Business, and Enterprise users in ChatGPT and Codex. GPT-5.5 Pro rolled out to Pro, Business, and Enterprise users in ChatGPT.¹

The launch-day API caveat aged quickly. OpenAI updated the launch post on April 24 to say GPT-5.5 and GPT-5.5 Pro are now available in the API, and the API changelog says GPT-5.5 is available through Chat Completions, Responses, and Batch. GPT-5.5 Pro is available through Responses for harder problems that benefit from more compute.¹²⁸

That update changes the practical read. This is no longer a launch-day access story. It is a migration story. If you are moving a real workflow, check the exact endpoint, auth path, context mode, caching behavior, and tool support before swapping defaults.

The official positioning is direct. OpenAI says GPT-5.5 is strongest in agentic coding, computer use, knowledge work, and early scientific research. It highlights coding and debugging, online research, data analysis, documents, spreadsheets, software operation, and tool use across longer tasks.¹

Greg Brockman framed it as a "new class of intelligence" that can complete difficult computer work with less micromanagement, while remaining token efficient and low latency at scale.⁶ Sam Altman framed the release around iterative deployment and democratized access to capable models, especially as cybersecurity capability keeps rising.⁵

That combination tells you where OpenAI wants the conversation to go. GPT-5.5 is not being sold as a better answer box. It is being sold as a better worker inside a tool harness.

The Benchmark Story Is Strong, but Not Clean

OpenAI's headline numbers are good.

The company reports 82.7 percent on Terminal-Bench 2.0, up from 75.1 percent for GPT-5.4, and above Claude Opus 4.7 at 69.4 percent and Gemini 3.1 Pro at 68.5 percent.¹ That benchmark matters here because it tests command-line workflows that require planning, iteration, and tool coordination. In other words, it maps pretty closely to the Codex story.

OpenAI also reports 84.9 percent on GDPval wins or ties, 78.7 percent on OSWorld-Verified, 55.6 percent on Toolathlon, 84.4 percent on BrowseComp, 51.7 percent on FrontierMath Tiers 1 to 3, 35.4 percent on FrontierMath Tier 4, and 81.8 percent on CyberGym.¹

That is a strong launch table. It is also a table that should be read carefully.

The Decoder had the best skeptical read I found. It points out that GPT-5.5 does not dominate everything. Claude Opus 4.7 leads GPT-5.5 on SWE-Bench Pro, 64.3 percent to 58.6 percent. Gemini 3.1 Pro leads the base GPT-5.5 model on BrowseComp. GDPval improves only modestly over GPT-5.4, from 83.0 percent to 84.9 percent.¹⁴

That does not make the launch weak. It makes the launch specific. GPT-5.5 looks strongest where the task is agentic, tool-heavy, and operational. It is not an across-the-board demolition of every competing model.

That is actually more useful than the normal "new best model" headline.

The Codex Angle Is the Real Story

The most interesting claims are not in the generic ChatGPT framing. They are in Codex.

OpenAI Developers described GPT-5.5 as OpenAI's strongest agentic coding model to date, saying it can carry coding tasks further end to end: understanding a codebase, making changes, debugging, testing, and validation.³ They also said GPT-5.5 is more token efficient than GPT-5.4 in Codex for most users.⁴

That is the part I would watch. Not the one-off benchmark. The real test is whether it can stay useful across the full engineering loop.

Early users are already talking in those terms. Simon Willison said he had previewed GPT-5.5 in Codex for weeks and had especially good results using it for security reviews against code written by other models.⁸ His blog post captured the awkward day-zero detail: before the API opened on April 24, GPT-5.5 was already accessible through the Codex subscription path that OpenAI appears to tolerate for tools like Codex and OpenClaw.⁷²⁸

Dan Shipper and the Every team are more bullish. Their day-zero read is that GPT-5.5 is fast, friendly, strong at coding, strong at knowledge work, and plausible as a daily driver. Shipper wrote that it has "serious conceptual clarity" and can hold complex plans across long work sessions.⁹

But Every's own caveats are important. Their review says Opus 4.7 still writes better plans, has better attention to detail on some work, and remains stronger for frontend, product design, and underspecified vibe-coding tasks. They also call out Ruby as a weak spot.¹⁰

That sounds right. GPT-5.5 may be the better default workhorse. That does not mean it is the best taste model or the best ambiguous-product partner.

My Local Gauntlets Matched the Workstation Thesis

The public benchmark table is useful, but I care more about the thing I can actually feel in a tool harness: does the model finish real work, verify it, and explain what changed?

So I ran GPT-5.5 through a small local gauntlet set inside OpenClaw. This is not a public benchmark. It is my own working set for Codex-style tasks: broken ops scenarios, a frontend component build, a security audit, and a production system design prompt. The point was not to prove universal superiority. The point was to see whether the workstation framing holds up when the model has to use files, make changes, and pass verification.²⁵²⁶

Local gauntlet	Result	What mattered
Ops Gauntlet 001: NovaPay reconciliation outage	7/7 verification, 18/18 manual score	Found five config and permission faults, fixed them, produced a clean postmortem, and ignored old OOM/TLS/MongoDB noise.
Ops Gauntlet 002: DataForge silent pipeline failure	8/8 verification, 18/18 manual score	Treated it as stale output instead of a crash, found the FIFO log trap, empty worker count, config path mismatch, missing table, and stale cache.
Frontend Build: generic React TypeScript data table	27/27	Produced a single-file component with sorting, filtering, pagination, selection, theme toggle, keyboard behavior, ARIA, responsive layout, and real TypeScript compile validation.
Security Audit: vulnerable Express app	27/27	Found all 17 planted issues with line numbers, CVSS estimates, exploitability notes, impact, and fixes.
System Design: 50,000 events/sec log aggregation	30/30	Covered all 10 requested sections with sizing math, shard counts, retention, alert routing, failure modes, a 3 month rollout, and a $7,670/month cost model under the $8,000 cap.
Total local score	120/120	Stronger than I expected, especially on verification-heavy work.

The operational runs are the part I trust most. GPT-5.5 traced the incident shape, separated current faults from stale noise, and validated the full path afterward. That is exactly what I mean by a workstation model.

The frontend run was also strong, but with a caveat. It generated a clean, compilable table component. That is engineering execution. It is not the same thing as product taste. For visual design, I still want a human pass or a taste model in the loop.

A Few Before and After Checks

The visual redesign tests were useful for a different reason. They show the line between implementation and taste. GPT-5.5 can take a page from plain project-card energy to something much closer to a portfolio case study, but the final judgment still comes down to whether the page feels intentional instead of just decorated.²⁷ Worth saying: the original versions were not junk. Those were Opus 4.5 designs, so this was a comparison between one strong model pass and another, not between competence and collapse.

Before: the SOC project page was readable, but it felt like a normal project detail page.

After: better hierarchy and framing, but it still defaults to cards, pills, and gradient accents.

Before: solid content, but the page did not yet sell the NOC dashboard concept visually.

After: this one really worked. The large type, stronger color, and dashboard visuals gave it real presence.

These images are why I would not call GPT-5.5 a pure coding model. It can move through code, content, layout, and QA in the same run. That is the workstation behavior. The limit is taste, not capability.

I pushed that a little further with two UI redraws that are closer to product-surface work than normal blog-page polish.

BroHunter started as a blunt, utility-first screen that already worked. The redesign just gave it more shape: grouped navigation, active hunts, Zeek signals, protocol mix, confidence markers, evidence queue, and a timeline that feels more deliberate.

Before: usable, but visually flat and not yet selling the investigation workflow.

After: one of my favorites. Better hierarchy, better grouping, and a much more confident hunting surface.

CyberBRIEF was a different test. The original leaned into cheesy security-page territory and felt imbalanced, so this one needed restraint more than volume. The goal was to make it feel like an editorial intelligence briefing product, calm enough to read, structured enough to scan, and distinct from the louder security-tool aesthetic.

Before: informative, but still closer to a plain report page than a polished briefing surface.

After: a big improvement. Calmer, more balanced, and much closer to a real briefing surface.

GPT-5.5 was not just filling in components or cleaning up CSS. It was moving between tone, information density, workflow cues, and product intent. That is closer to real interface work.

I still would not hand it the keys and walk away. Taste is still the part that needs a human in the loop. But the distance between "generate a working UI" and "generate a UI that feels like the product it is supposed to be" is getting smaller.

What This Means for OpenClaw and Third-Party Harnesses

This launch matters more if you run agents outside a model lab's first-party app.

OpenClaw's current docs already treat GPT-5.5 as a first-class OpenAI-family model, but the route labels matter. There are three practical paths: direct API-key billing through openai/gpt-5.5, Codex OAuth through openai-codex/gpt-5.5, and native Codex app-server behavior through openai/gpt-5.5 plus agentRuntime.id: "codex".¹⁷¹⁸

That is the cleanup I would not want to get wrong in a fanout. openai-codex/gpt-5.5 is not just an old compatibility alias. It is the recommended PI route for subscription setups. openai/gpt-5.5 is the direct OpenAI Platform route unless you explicitly force the Codex runtime. In my local OpenClaw session, GPT-5.5 is configured behind the gpt55 alias through Codex OAuth and exposed with text and image support. The docs list GPT-5.5 as a 1,000,000-token model, though OpenClaw can still set smaller runtime caps for latency and quality.¹⁷

OpenAI's Codex docs add another practical constraint: for most Codex tasks, start with gpt-5.5 when it appears in your model picker, but GPT-5.5 is currently available in Codex only when signed in with ChatGPT. It is not available with API-key authentication inside Codex, and Chat Completions support is deprecated for future Codex releases.²⁹

The bigger implication is ecosystem leverage. A lot of third-party agent harnesses have been boxed in by Anthropic's first-party gravity: Claude Code, Claude CLI, Max or Team entitlements, API-key routes, policy shifts, and uneven support for non-Anthropic tools. OpenClaw's docs still support Anthropic routes, but GPT-5.5 gives OpenClaw and similar harnesses a serious non-Claude work model with a supported subscription OAuth path. That matters for projects that cannot depend on Anthropic's ecosystem or do not want their agent stack coupled to one first-party harness.¹⁷¹⁸

OpenClaw also does more than pass the model name through. For GPT-5-family runs, it adds a shared behavior overlay across compatible providers, including openai/gpt-5.5, openrouter/openai/gpt-5.5, opencode/gpt-5.5, and similar refs. It supports WebSocket-first transport with SSE fallback, WebSocket warm-up, /fast mapped to priority processing on native OpenAI and Codex endpoints, server-side compaction for direct Responses API models, and a strict-agentic mode that retries plan-only turns when a tool action is available.¹⁷

For Hermes specifically, I do not see OpenClaw documenting a dedicated Hermes harness path. The docs show Hermes-family models through provider catalogs such as Venice, while the third-party gateway story is clearer through OpenCode, Kilo Gateway, and Vercel AI Gateway. OpenCode documents opencode/gpt-5.5, Kilo Gateway documents kilocode/openai/gpt-5.5, and OpenClaw's Vercel provider documents refs such as vercel-ai-gateway/openai/gpt-5.5. Vercel's own April 24 AI Gateway changelog exposes GPT-5.5 and GPT-5.5 Pro to AI SDK users as openai/gpt-5.5 and openai/gpt-5.5-pro.¹⁹²⁰²¹²²³⁰

That portability is the point. If GPT-5.5 is good at long-running coding, computer use, and tool work, third-party harnesses do not have to wait for Anthropic access to build credible agent workflows. They can route through native OpenAI, Codex OAuth where supported, or gateway catalogs that expose GPT-5.5.

Here is the practical cost picture as of April 28. The GPT-5.5 API prices are now on OpenAI's public pricing page, not just launch-day reporting. Short-context GPT-5.5 is $5 per million input tokens and $30 per million output tokens. Long-context GPT-5.5 is $10 per million input tokens and $45 per million output tokens. GPT-5.5 Pro matches GPT-5.4 Pro at short context and long context prices.²³

Model or route	Status	Input per 1M	Cached input per 1M	Output per 1M	100k input plus 20k output
GPT-5.5, short context	Official OpenAI API pricing	$5.00	$0.50	$30.00	$1.10
GPT-5.5, long context	Official OpenAI API pricing	$10.00	$1.00	$45.00	$1.90
GPT-5.5 Pro, short context	Official OpenAI API pricing	$30.00	Not listed	$180.00	$6.60
GPT-5.5 Pro, long context	Official OpenAI API pricing	$60.00	Not listed	$270.00	$11.40
GPT-5.4, short context	Official OpenAI API pricing	$2.50	$0.25	$15.00	$0.55
GPT-5.4, long context	Official OpenAI API pricing	$5.00	$0.50	$22.50	$0.95
GPT-5.4 Pro, short context	Official OpenAI API pricing	$30.00	Not listed	$180.00	$6.60
GPT-5.4 Pro, long context	Official OpenAI API pricing	$60.00	Not listed	$270.00	$11.40
GPT-5.3-Codex	Official OpenAI API pricing page	$1.75	$0.175	$14.00	$0.455

For Codex's token-based rate card, OpenAI lists GPT-5.5 at 125 credits per million input tokens, 12.50 credits per million cached input tokens, and 750 credits per million output tokens. GPT-5.4 is half that rate: 62.50, 6.250, and 375 credits. That lines up with the reported API story: GPT-5.5 is meaningfully more expensive per token, so the bet has to be fewer retries, fewer wasted loops, and more completed work per session.²⁴

The Price Story Is Still Annoying

Here is the less messy but still annoying part: the API is live now, and the official pricing confirms the launch reports.

Every and The Decoder had the short-context numbers right: GPT-5.5 is $5 per million input tokens and $30 per million output tokens, while GPT-5.5 Pro is $30 per million input tokens and $180 per million output tokens.¹⁰¹⁴²³

That doubles GPT-5.4's short-context base price. Long context raises the spread further: GPT-5.5 is $10 in, $45 out, compared with GPT-5.4 at $5 in, $22.50 out. OpenAI's argument is that GPT-5.5 uses fewer tokens to complete comparable Codex tasks, so the completed-task cost can still improve even when the per-token price is higher.¹²³

Maybe. That is plausible for hard tasks where retries are the real cost. It is less comforting for teams that already know their usage profile and watch token bills closely. Official pricing makes the decision easier to model, but it does not make it cheap.

Theo Browne put the skeptical developer reaction pretty cleanly: GPT-5.5 is smart, but "weird, hard to wrangle, and too expensive" at the reported $5 and $30 pricing.¹¹

That is the right tension. A model can be smarter and still lose some workflows if the cost curve or control surface feels wrong.

Safety Is Part of the Product Now

The system card matters because GPT-5.5 improves cyber and bio-relevant tasks, not only safe office work.

OpenAI says GPT-5.5 was evaluated under its Preparedness Framework, including targeted cybersecurity and biology red-teaming, and feedback from nearly 200 early-access partners.² The system card rates biological and chemical capability as High. It rates cybersecurity capability as High but below Critical. AI self-improvement remains below High.²

That is a big deal for defenders. It is also where the deployment details matter.

OpenAI says it is using stricter classifiers for higher-risk cyber activity, monitoring for impermissible use, and Trusted Access for Cyber so verified defenders can use sharper capabilities with fewer pointless refusals.¹²

There is also a caveat worth saying out loud. The system card notes that UK AISI found a universal jailbreak during testing. OpenAI updated its safeguard stack afterward, but UK AISI could not fully verify the final fix because of a configuration issue in the retest version.²

That does not mean the release is reckless. It does mean the safety story is still a live engineering problem, not a solved checkbox.

Enterprise Buyers Are the Audience

NVIDIA's post makes the enterprise angle obvious. The company says more than 10,000 NVIDIANs across engineering, product, legal, marketing, finance, sales, HR, operations, and developer programs are already using GPT-5.5-powered Codex internally.¹²

NVIDIA describes debugging cycles that used to take days closing in hours, and experimentation that used to take weeks turning into overnight progress in complex codebases.¹² That is marketing language, sure. It is also the exact buyer story OpenAI wants: not a chatbot for answers, but an agentic system that sits inside enterprise work.

Fortune added useful scale numbers from OpenAI: 4 million active Codex users, 9 million paying business ChatGPT users, more than 900 million weekly active ChatGPT users, and more than 50 million subscribers.¹³

Those numbers explain the launch cadence. GPT-5.5 arrived only weeks after GPT-5.4. The labs are not waiting for clean annual model eras anymore. They are shipping increments into massive distribution and letting the workflow layer absorb the change.

That is exciting. It is also a little exhausting.

The Early Community Reaction Is Split

Almost a week in, the outside read has settled into something more useful than launch hype.

The positive camp is not just saying "higher benchmark number." They are describing a model that feels better inside a work harness. Developer Tech's coverage repeats the pattern from OpenAI and early testers: implementation, refactors, debugging, testing, validation, fewer tokens in Codex, and longer context for real repository work.³¹ Ethan Mollick's review lands in the same place from a different angle. His strongest examples are not chat answers. They are Codex plus GPT-5.5 turning messy data into a draft academic paper, building a 101 page tabletop game, and using GPT-5.5 to build the gallery for his own model comparison.³²

That matches my own experience better than the generic chatbot coverage does. GPT-5.5 has been strong at orchestration, tool calls, reasoning through a failure, and fixing itself after verification catches something. The real improvement is not that it sounds smarter. It keeps the work loop intact longer.

The skeptical camp is also not wrong. Hacker News is doing what Hacker News does: turning the launch into a referendum on model motivation, agent harnesses, reasoning budgets, and whether modern models actually keep working when they say they will.¹⁶ Some Reddit and developer threads are excited about one-shot fixes and better Codex persistence. Others complain about usage limits, rollout friction, and a familiar feeling that the model is better but not magical.

That split is the story. People using GPT-5.5 for real multi-step work are more impressed than people sampling it like a chatbot. The model looks best when it has files, tools, tests, and a clear target state. It looks less special when the task is vague, taste-heavy, or bottlenecked by quota and cost.

This is where GPT-5.5 has to keep proving itself. The launch claims are strong. The benchmark table is strong. The early Codex reports are encouraging. But the thing people will remember is whether it finishes.

My Take

GPT-5.5 looks like OpenAI's most coherent answer yet to Claude's work-model advantage.

GPT-5.4 made OpenAI competitive again for a lot of agentic coding work. GPT-5.5 sharpens the pitch: faster than the big slow models, stronger inside Codex, better at carrying context across tools, and more practical for real workflows than a pure reasoning monster that burns time and budget.

But I would not flatten this into "OpenAI wins."

The better read is this: GPT-5.5 may become the default workhorse for people who live inside Codex-style systems. Opus may still be better when the work needs product taste, careful planning, frontend judgment, or a more opinionated collaborator. Gemini still has lanes where long-context research and web work remain competitive. The winner depends on the harness, the task, the budget, and how much human steering you want in the loop.

For builders, the practical advice is simple.

Use GPT-5.5 where persistence matters: refactors, testing loops, security review, operational docs, research synthesis, spreadsheet and document work, and agentic tasks with a clear target state.

Be more cautious where taste matters: frontend design, product direction, ambiguous prototypes, and writing that needs a sharp voice instead of smooth structure.

And do not treat launch-week model docs as frozen. GPT-5.5 went from "coming very soon" to live API in one day. Verify the current route, pricing, and auth mode before wiring production spend.

That last part is boring. It is also how you avoid building your launch-week plan on vibes.

Notes

1. OpenAI, "Introducing GPT-5.5" (April 23, 2026).
2. OpenAI, "GPT-5.5 System Card" (April 23, 2026).
3. OpenAI Developers, "GPT-5.5 is our strongest agentic coding model to date", X (April 23, 2026).
4. OpenAI Developers, "GPT-5.5 is more token efficient than GPT-5.4", X (April 23, 2026).
5. Sam Altman, "We believe in iterative deployment", X (April 23, 2026).
6. Greg Brockman, "GPT-5.5 is a new class of intelligence", X (April 23, 2026).
7. Simon Willison, "A Pelican for GPT-5.5 via the Semi-Official Codex Backdoor API", Simon Willison's Weblog (April 23, 2026).
8. Simon Willison, "I've been previewing this in Codex for a few weeks", X (April 23, 2026).
9. Dan Shipper, "GPT-5.5 'Spud' is out and it is a BEAST", X (April 23, 2026).
10. Every, "Vibe Check: GPT-5.5 Has It All" (April 23, 2026).
11. Theo Browne, "$5 per mil in, $30 per mil out", X (April 23, 2026).
12. NVIDIA, "OpenAI's New GPT-5.5 Powers Codex on NVIDIA Infrastructure, and NVIDIA Is Already Putting It to Work" (April 23, 2026).
13. Sharon Goldman, "OpenAI Launches GPT-5.5 Just Weeks after GPT-5.4 as AI Race Accelerates", Fortune (April 23, 2026).
14. Matthias Bastian, "OpenAI Unveils GPT-5.5, Claims a 'New Class of Intelligence' at Double the API Price", The Decoder (April 23, 2026).
15. Carl Franzen, "OpenAI's GPT-5.5 Is Here, and It's No Potato", VentureBeat (April 23, 2026).
16. Hacker News, "GPT-5.5" (April 23, 2026).
17. OpenClaw, "OpenAI", documentation checked April 28, 2026.
18. OpenClaw, "Model Providers", documentation checked April 28, 2026.
19. OpenClaw, "OpenCode", documentation checked April 28, 2026.
20. OpenClaw, "Kilo Gateway", documentation checked April 28, 2026.
21. OpenClaw, "Vercel AI Gateway", documentation checked April 28, 2026.
22. OpenClaw, "Venice", documentation checked April 28, 2026.
23. OpenAI, "Pricing", OpenAI API documentation (checked April 28, 2026).
24. OpenAI Help Center, "Codex Rate Card" (checked April 23, 2026).
25. Local OpenClaw benchmark artifacts for GPT-5.5 Ops Gauntlets 001 and 002, run April 23-24, 2026.
26. Local OpenClaw benchmark artifact, "GPT-5.5 Three-Gauntlet Scorecard," run April 24, 2026.
27. Local Astro preview screenshots from GPT-5.5 frontend redesign experiments, captured April 23-24, 2026.
28. OpenAI, "Changelog", OpenAI API documentation (checked April 28, 2026).
29. OpenAI Developers, "Models - Codex" (checked April 28, 2026).
30. Vercel, "GPT 5.5 on AI Gateway" (April 24, 2026).
31. Ryan Daws, "OpenAI Brings GPT-5.5 to Codex for Coding Tasks", Developer Tech (April 2026).
32. Ethan Mollick, "Sign of the Future: GPT-5.5", One Useful Thing (April 2026).

Originally published at solomonneas.dev/blog/gpt55-openai-workstation-model. Licensed under CC BY-NC-ND 4.0 - attribution required, no commercial use, no derivatives.

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/. ↩

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.