That post still works, and the script still runs. But it taught the wrong objective for half the contests people play. And it assumed the person running it was you, pasting code into a Live Script. Both of those changed, so I rebuilt the thing.

The repo is the same one: github.com/nothans/dfs-optimizer. It now has a function library, an app for exploring the options, a test suite, and a section for coding agents. In 2026 the “user” of a tool like this is as likely to be Claude Code or OpenAI Codex with a MATLAB session open as it is to be a human with a mouse. This post is the new tutorial.

What the 2022 script got right, and what it got wrong

The 2022 model was one binary variable per player and a handful of linear constraints: one QB, one defense, two to three running backs, three to four receivers, one to two tight ends, nine players total, salary under the cap. Maximize projected points. That is still the core, and the new code returns the identical lineup on the same data. There is a test that proves it.

What it got wrong is subtler. “Maximize projected points” is the correct objective for a cash game, a 50/50 or a double-up, where you’re paid if you finish in the top half. You want the highest floor, and the highest projection is a decent proxy.

It’s the wrong objective for a tournament (a GPP, guaranteed prize pool), where a few thousand entries compete for a top-heavy payout and the winner needs a top-1% finish. In a tournament, the highest-projected lineup is the lineup everyone else has too. You want ceiling and you want to be different. That means correlated players (a QB and his receiver score on the same plays), lower-owned players (so a hit separates you from the field), and more than one lineup.

Get the data

The projections still come from Daily Fantasy Fuel. Pick the DraftKings or FanDuel tab, clear any filters, let the whole table load, then click Download CSV and save the file. The button exports the rows on screen, so a filtered view gives you a filtered file. The header looks like this:

first_name, last_name, position, injury_status, week, game_date, slate, team, opp,
spread, over_under, implied_team_score, salary, L5_dvp_rank, L5_fppg_avg,
L10_fppg_avg, szn_fppg_avg, ppg_projection, value_projection, ownership_projection

That last column matters. Projected ownership is what makes the tournament levers work, and the 2022 post ignored it.

You don’t need to import the file by hand anymore. The loader reads it directly, drops anyone marked out, and keeps every original column:

players = dfs.loadProjections("DFF_NFL_cheatsheet.csv");

If you don’t have a download handy, the repo ships a synthetic 13-game slate in the same header, with made-up names, so every example below runs as-is, and you’ll meet a few of those names again before this is over.

The app, in five clicks

Open MATLAB in the repo folder (or click the Open in MATLAB Online badge on the README) and run:

DFSOptimizerApp

It opens on the sample slate. Levers on the left, results on the right.

Click one: the Cash game preset, then Optimize. This is the 2022 script with a face. One lineup, maximum projection, no stacking, ownership ignored. On the sample slate it lands at 176.4 projected points and a summed ownership of 192%, which is a polite way of saying “everyone has these players.”

Click two: the Tournament preset, then Optimize. Now the sidebar asks for a QB stack (one receiver or tight end from the QB’s own team), a bring-back (one skill player from the opponent), and no defense against your own QB. It also wants a small penalty on projected ownership and twenty lineups, where nobody appears in more than half and every pair differs by at least three players. A progress bar counts them off, about a quarter second each.

Click any row to see the roster. The summed ownership drops into the 70 to 150 range and the QB column shows the portfolio spreading across three or four quarterbacks instead of one.

Click three: lock and exclude. The Player pool tab is the whole slate with two checkbox columns. Tick Lock on a player you believe in and Exclude on one you don’t, and every solve from then on honors it.

Click four: Exposure. This is the chart I wanted in 2022 and didn’t have. Your exposure per player across the twenty lineups, next to the field’s projected ownership. The gap is leverage. A player you have at 40% who the field has at 2% is where a tournament gets won or lost.

Click five: Simulate. A projection is a mean, not a promise. The Monte Carlo tab draws fifty (or five hundred) noisy versions of the projections, re-solves the lineup for each one, and counts who made it. A player who’s optimal in 60% of the draws is a play. A player who’s optimal only at the exact point estimate is a coin flip with a good agent.

There’s a sixth button, Copy as code, and it’s the one I use most. It writes your current sidebar as a function call and puts it on the clipboard, so a session in the app turns into a script you can rerun next week:

players = dfs.loadProjections("data/sample_DFF_NFL.csv");
[lineups, summary, exposure] = dfs.generateLineups(players, 20, ...
    Site="DraftKings", SalaryCap=50000, OwnershipWeight=0.05, StackSize=1, BringBack=1, ...
    AvoidQBvsDST=true, MaxExposure=0.5, MinUnique=3, Randomness=0.1, Seed=1);

The levers, one constraint each

The app is a thin layer over a package called +dfs, and every lever is a name-value option on dfs.optimizeLineup. Each one is a single linear constraint on the same binary variables the 2022 script used. Plain words first, then the code, lever by lever.

Stack. For every quarterback in the pool, “the number of his own receivers and tight ends you pick is at least k times whether you picked him.” When you don’t pick him the right side is zero and the constraint sleeps. When you do, it demands k partners. No big-M tricks, one row per QB.

L = dfs.optimizeLineup(players, StackSize=2);

Bring-back. The same shape, aimed at the opponent’s skill players. It bets on a shootout.

L = dfs.optimizeLineup(players, StackSize=1, BringBack=1);

No QB against your own defense. A pairwise exclusion: QB plus the opposing defense is at most one. Your defense scores when his offense fails. Do not root against yourself.

L = dfs.optimizeLineup(players, AvoidQBvsDST=true);

Ownership penalty. Instead of maximizing projection, maximize projection minus lambda times projected ownership. On the sample slate, a lambda of 0.05 with a two-man game stack gives up 3.8 points and sheds 23 points of summed ownership.

[L, info] = dfs.optimizeLineup(players, OwnershipWeight=0.05);

Exposure and uniqueness. When you build twenty lineups in a row, each new solve gets two extra rules: players at their exposure cap sit out, and “the overlap with every earlier lineup is at most nine minus u players.”

[lineups, summary, exposure] = dfs.generateLineups(players, 20, MaxExposure=0.4, MinUnique=3);

FanDuel. Different cap, a four-per-team limit, three-team minimum. One word.

L = dfs.optimizeLineup(players, Site="FanDuel");

If you like your math in one block, this is the whole model:

maximize    sum_i (p_i - lambda * o_i) x_i
subject to  sum_i x_i = 9
            1 QB, 1 DST, 2-3 RB, 3-4 WR, 1-2 TE
            sum_i s_i x_i <= cap
            players from at least 2 games            (DraftKings)
            at most 4 per team, at least 3 teams     (FanDuel)
            partners of QB q  >= k * x_q             (stack)
            opponents of QB q >= b * x_q             (bring-back)
            x_q + DST facing q <= 1                  (no QB vs DST)
            overlap with earlier lineup <= 9 - u     (uniqueness)
            x_i in {0, 1}

The FLEX spot isn’t a variable. It’s the slack between each position’s base count and its maximum, pinned by the total of nine. That trick was in the 2022 script and it’s still the reason the model stays at one variable per player.

The academic version, stacking constraints included, is Hunter, Vielma and Zaman’s “Picking Winners in Daily Fantasy Sports Using Integer Programming” from MIT. The levers above are the practical subset every serious optimizer ends up with.

Trust, then verify

Two things happen after every solve, and both are new.

First, the code checks the solver’s exit flag and refuses to hand you a lineup the solver didn’t actually finish. Second, the lineup goes through dfs.validateLineup, a function that knows nothing about the solver. It counts positions, adds salary, checks the games and teams, and complains in plain English if anything is off. If the solver and the validator ever disagree, you get an error, not a lineup.

There are 22 tests. The one I care about most feeds the same slate to the 2022 formulation and the new one and asserts they return the same players and the same 176.4 points. The model got a lot of new rules, but the old answer didn’t move.

The other user: a coding agent

MathWorks ships the MATLAB Agentic Toolkit. It does two things. It installs the MATLAB MCP Server, which gives a coding agent (Claude Code, GitHub Copilot, Codex, Gemini CLI, Amp) a live MATLAB session it can run code in, lint with, and test through. And it installs skills: curated MathWorks knowledge so the agent writes idiomatic MATLAB and stops inventing toolbox functions.

I used two of those skills to build the refresh. matlab-solve-optimization is where “check the exit flag, then validate independently” comes from. matlab-build-app is where the app’s layout comes from (it calls the sidebar-plus-display shape an Explorer, and it’s right). The skills read like design documents from someone who has built a lot of MATLAB apps and solved a lot of optimization problems, which is what they are.

Setting it up takes three steps:

1. Download agenticToolkitInstaller.mltbx, open it in MATLAB, and run setupAgenticToolkit("install"). Pick the skill groups you want; for this repo that’s Math and Optimization, MATLAB App Building, and MATLAB Core. (The installer is shared with the Simulink Agentic Toolkit, which is why the download lives in that repo’s releases.)
2. In MATLAB, run shareMATLABSession() so the agent works in the session you can see.
3. Open the repo in your agent. There’s an AGENTS.md (and a CLAUDE.md for Claude Code) that gives it the map, the rules for changes, and prompts that work.

Then you stop clicking and start asking. This is a real exchange from my session, with the agent driving MATLAB through the MCP server:

Me: Load the sample slate, build 20 DraftKings tournament lineups with a 2-man stack, 40% max exposure and 3 unique players per pair, and tell me the five players where my exposure is furthest above projected ownership.

Agent: Built 20 lineups (164.2 to 173.1 projected points, summed ownership 106% to 187%). Your biggest leverage plays:

Name	Pos	Team	Exposure	Field	Leverage
Nico Ironwood	WR	IND	40%	1.7%	+38.3
Cameron Quillon	WR	DEN	40%	7.5%	+32.5
Gideon Okafor	WR	LAR	40%	7.7%	+32.3
Elliot Ashcombe	TE	MIA	40%	8.7%	+31.3
Xavi Fenwick	WR	NO	40%	11.7%	+28.3

The names are fake because the slate is synthetic. The workflow isn’t. The agent called dfs.generateLineups, sorted the exposure table by leverage, and showed me the top five. Then I asked it to add a rule I had been meaning to write for a year (cap the players from any one game), and it added the constraint, a validator clause, and a test, ran the suite, and reported 23 of 23.

The README’s “getting started” section used to be steps for a person. Now the useful section is a list of prompts, each of which is a claim the agent can check by running the code.

The caveats, because it’s still football

Projections are still projections. The optimizer is only as good as the numbers you feed it, and the numbers are a mean over a game that hasn’t happened.

The Monte Carlo view uses per-position volatility guesses (quarterbacks are steadier than tight ends, defenses are chaos) that I picked, not measured. They’re labeled as working values in the code. Replace them with your own standard deviations if you have them; the simulator will use a StdDev column if it finds one.

The stacking wisdom is what the DFS sites and the MIT paper agree on, but the correlation numbers you see quoted around the internet are site-reported, not something I verified. Treat the levers as structure, not as guarantees.

And the sample slate’s players don’t exist. Please do not roster Nico Ironwood.

Go build one

The code is MIT-licensed at github.com/nothans/dfs-optimizer and on MATLAB File Exchange. The 2022 post is still there if you want to optimize a lineup.

Download a slate, run the Tournament preset, look at the exposure chart, and then argue with it. Let me know what your lineup looked like, and send a pull request if you teach it a new trick.

It did not write a single word back.

That’s Jev, and I think it’s one of the more interesting models to show up this year.

Yes, I made the meme. Jev couldn’t say that line if it tried. You’d have to ask it a yes/no question.

What Jev is

Jev comes from TypeSafe, a San Francisco lab that came out of stealth on September 15. OpenRouter added it three days later as typesafe/jev-1.13, so if you have an OpenRouter key, you already have Jev.

Every frontier lab has spent the last two years teaching models to think longer. TypeSafe went the other way. Jev reads whatever you hand it and answers one of three kinds of question, using only the options you give it.

• Noul: yes or no, as a probability.
• Choice: pick one of up to 255 options you describe.
• Score: place it on a scale you define, “Can wait” to “Blocking revenue right now.”

Every answer comes back with probabilities. No prose to parse, no JSON that’s almost JSON, no invented option. It’s an if-statement that understands English.

It’s also cheap: $0.042 per million input tokens, and output is free. My first call, three questions about one support ticket, came back in 0.6 seconds and cost $0.000017.

Where it fits

Most decisions inside software aren’t essays. They’re “which team gets this ticket,” “is this safe to run,” “is this spam,” “which of these 40 things matters.” We’ve been paying a chatbot to write a paragraph so we could regex one word out of it.

• Routing and triage. Tickets, emails, alerts, pull requests. Pick the queue, score the urgency.
• Gating agents. Before an agent issues a refund or runs a command, ask three yes/no questions. At 0.9 or higher, go. At 0.1 or lower, stop. In between, a human looks. OpenRouter published exactly this recipe.
• Checking an LLM’s homework. Did the answer stick to the source, or make something up? Ship the supported ones, escalate the rest.
• Sorting big piles. Thousands of documents, one question each, ranked by probability.
• Picking instead of writing. Pull the candidate dates or amounts out with a regex, then let Jev choose the right one.

The probabilities are the part I didn’t expect to love. When the model is unsure, it says so, and you fix things by moving a threshold, not rewriting a prompt.

What I built with it

My research repo has 1,140 items in it: voice briefs, news digests, insights, bets, trend signals, blog drafts. I built a thing called Sieve that asks Jev the same question about every one of them and ranks the answers. “Talk-ready.” “Evidence against my community thesis.” “Feeds chapter two of the book.” “A hands-on build that could be demoed live at a developer meetup.” (My CABLE 82 talk came back first, at 95%. Correct.)

Then I checked it against my own filing. I’d already sorted every insight and trend signal into swimlanes by hand, so I stripped the labels and asked Jev to do it. Overall it agreed with me about 8 times in 10. When it said it was confident, 9 times in 10. When it was unsure, it was close to a coin flip, and it told me so.

Sieve is open source

I split Sieve into the engine and my stuff, and put the engine on GitHub: github.com/nothans/sieve. MIT licensed, just Node, no dependencies. Point it at any folder of Markdown, describe what counts as an item and which questions you care about in one config file, and it sifts the whole pile from the command line or a little web UI. My research notes and my config stay on my machine.

It ships with two demos: a made-up research notebook, and all 313 of Aesop’s fables. Ask the fables for “a trick that backfires on the trickster” and it reads every one of them in 1.4 seconds for about a third of a cent.

The Moral preset files every fable under its moral. The Dog and the Shadow came back 100% greed, which seems fair to the dog.

The repo also carries the Jev command-line tool on its own, so any script or agent can grab a typed answer when it needs one.

What tripped me up

Jev reads literally. Really literally. “Projects I could demo live on stage” ranked a Google product launch first, because Jev has no idea who “I” is. “Is this evidence against my thesis” came back as a shrug on everything. Asking for the concrete thing instead (“does this report a community that did fine without human trust?”) fixed it. TypeSafe documents all of this: no math, no counting, no date comparisons, and adversarial text can push it around. It also can’t tell you why, so you get a number and no reason.

The idea is already loose, too. Six open-source clones showed up within about 48 hours, at least one of them running on a single gaming GPU. What got copied is the shape: state in, typed questions in, probabilities out. I think that shape sticks around, whoever ends up serving it.

Creative uses I want to try

• Board game bots. A playtest bot that picks its move from the legal moves, with a persona written in the question.
• A notification bouncer. One yes/no before anything pings my phone: “Is this urgent enough to interrupt someone at dinner?” (Not “would I want this.” Jev doesn’t know who I am.)
• CABLE 82 tonight. Score every headline on “cozy Friday night viewing” and let the 1982 cable channel build its own lineup.
• Moderation with the thresholds in public. Every post gets the same small set of typed judgments, and members can see, and vote on, the numbers that decide what happens.
• A code review tripwire. “Does this diff touch authentication or payments?” before an agent is allowed to merge.
• Alt text that checks itself. Does this description actually say what the chart shows?
• Spreadsheet columns that think. Add a column called “urgency,” type what it means, fill 300 rows in seconds.
• Training its own replacement. Label a big pile of examples with Jev, then train a tiny local model on the labels.

It’s the first AI model I’ve met that’s better at listening than talking.

I know a few people like that. Not many.

What you need

Any of the big three AI chatbots, all of which have free tiers:

• ChatGPT
• Claude
• Gemini

They’re all good at this. Wordplay, puns, and pop-culture mashups are the kind of thing these models genuinely enjoy (if models can enjoy things).

The original version of this tutorial pointed to a custom GPT I built for exactly this job. You don’t need it anymore. You don’t need a name-generator website either. The base models got good enough that the wrapper became the long way around, and a plain chat with a decent prompt beats both.

The method

The 2024 version had a warm-up step where you told the AI your objective and asked it to respond OKAY before sending the real prompt. You can skip that now; the models don’t need to be eased into anything anymore. Everything goes in one prompt, and the whole method is three steps:

1. Open a new chat in ChatGPT, Claude, or Gemini.
2. Pick a prompt template below, replace the [BRACKETED] words, and send it.
3. When a direction makes you grin, ask for more: “give me 10 more like #3” works exactly like you’d hope.

The 20 prompt templates

1. Generate 5 funny fantasy football team names based on [PLAYER NAME]’s name or playing style.
2. Create 5 clever fantasy football team names inspired by the [TEAM NAME] and their history or current roster.
3. Come up with 5 witty fantasy football team names centered around [POSITION] players.
4. Blend NFL references with [MOVIE/TV SHOW/BOOK] to create 5 unique fantasy football team names.
5. Generate 5 punny fantasy football team names using football terminology and common phrases.
6. Create 5 alliterative fantasy football team names starting with the letter [LETTER].
7. Combine [CITY/STATE] references with football terms to make 5 locally-themed fantasy team names.
8. Generate 5 playful trash-talking fantasy football team names that imply dominating the competition.
9. Create 5 fantasy football team names that blend [PROFESSION] terminology with football references.
10. Come up with 5 fantasy football team names that incorporate [HOLIDAY/SEASON] themes.
11. Generate 5 appetizing fantasy football team names that combine [FOOD] with player names or football terms.
12. Create 5 fantasy football team names that blend [MUSIC GENRE/ARTIST] references with NFL players or teams.
13. Combine names of [HISTORICAL ERA] figures with football terminology to create 5 unique team names.
14. Generate 5 epic fantasy football team names inspired by [MYTHOLOGY] and NFL players or terms.
15. Create 5 geeky fantasy football team names that combine [SCIENTIFIC FIELD/TECH COMPANY] with NFL references.
16. Come up with 5 colorful fantasy football team names incorporating [COLOR] and player names or football terms.
17. Generate 5 wild fantasy football team names that blend [ANIMAL SPECIES] characteristics with NFL players or terms.
18. Create 5 electrifying fantasy football team names inspired by [WEATHER EVENT] and football references.
19. Blend elements from [FICTIONAL WORLD/UNIVERSE] with NFL references to create 5 fantastical fantasy football team names.
20. Generate 5 multi-sport fantasy football team names that combine NFL references with terms from [OTHER SPORT].

An example

My go-to demo is template #4: “Blend NFL references with Deadpool to create 5 unique fantasy football team names.” The best result it ever gave me is still Mercs with a Mouthguard, riffing on Deadpool being the Merc with a Mouth in the comics. That one made the jump to a real league.

The new trick: make it about your league

This is the part that didn’t exist in the original tutorial. A name-generator website hands everyone the same list. The AI can work with your league specifically. Paste in your context along with the template:

Here are the other team names in my league: [PASTE THE LIST]. I finished [YOUR FINISH] last season, and I just drafted [YOUR KEY PLAYERS]. Generate 5 fantasy football team names that fit this league and gently roast my rivals.

Names that reference your buddy’s decade-long championship drought hit different than anything a template can produce. This also works for the sadder traditions: ask for last-place punishment team names and it delivers those too.

Bonus: generate a logo

In 2024 this step required a separate image tool. Now ChatGPT and Gemini generate images right in the chat, so once you’ve picked your name, keep going:

Create a fantasy football team logo for “[YOUR TEAM NAME]”: bold, cartoon mascot style, sized for a league avatar.

Ask for two or three style variations and pick the one that looks best at thumbnail size, because that’s the only size your league will ever see it.

The name is the only part of your season you have full control over…

Appendix: 100 names that survived the cull

One more thing, since the whole post is about the method: I ran it on itself. A few hundred generated names across ten different template directions, then a hard cull of anything that sounded like it shipped with a default league. These 100 survived, each with the recipe behind it so you can find your player or your favorite reference. Steal freely; your league never has to know.

Quarterback puns

Running back puns

Pass catcher puns

Movie and TV mashups

Music mashups

Science and tech

AI-era names

Myth, history, and literature

Group chat trash talk

Deep cuts and current events

I was standing in the hardware store holding a dead coin cell, squinting at it, trying to remember if the Lutron dimmer in my hallway takes a CR2032 or one of the other fourteen round silver batteries that all look exactly the same. So I guessed. I bought two of the wrong one. Classic.

Here is the thing about a house. You slowly learn a thousand tiny facts about it. The vent sizes. The filter part numbers. The spa was installed in some year you’ll never remember. The good info is scattered across manuals in a junk drawer, an email from the installer, a photo of a model plate you took and never looked at again. By the time you actually need a fact, it’s gone.

I finally fixed it. Not with an app. With a folder.

The idea I borrowed

Earlier this year Andrej Karpathy posted a little pattern he called an “LLM wiki.” Instead of the usual retrieval setup where you chop documents into chunks and stuff them in a vector database, you just keep a folder of Markdown files that the AI itself writes and maintains. The model builds the connections once, when it learns something, instead of re-deriving them every single time you ask. The internet looked at it and went “wait, it’s just a folder? why did we ever do the other thing.”

Then Google Cloud made it official. On June 12 they published the Open Knowledge Format, or OKF. It’s a tiny, vendor-neutral spec: a directory of Markdown files, one concept per file, a bit of YAML at the top, an index, links between them. No database. No SDK. Readable by a human and by any agent. That’s the whole thing.

So I pointed it at my house. The project is called Abode 101.

What I actually built

Abode 101 is an OKF folder about my home. There’s a file for the Lutron dimmer, one for the swim spa, one for the HVAC vents, one for the smoke alarms. There’s an index.md the AI reads first so it knows where to look. To use it, I don’t open an app. I just talk to it in Claude Code.

you ▸ what's the battery for the Lutron dimmer?
abode ▸ Panasonic CR2032, per the install guide (page 10).

That’s the fact I drove to the store without. Now it’s one question away, and it tells me where it got the answer.

But a folder of files just sitting there is a filing cabinet. The magic is in two things the bare spec leaves out.

Thing one: the loop

OKF standardizes the files. It says nothing about keeping them fresh. Karpathy’s original idea had the AI do the maintaining, and that’s the part I cared about most, so I built it back in as a set of playbooks.

I capture a thing by telling it “I bought X,” or by dropping a manual, a receipt, or a photo of a label into an inbox folder. It reads whatever I throw at it, pulls out the real specs, and files them. Then overnight it does the boring homework I never do. It looks up the filter I just bought, finds the replacement part, figures out how often it needs changing, and adds a reminder. I wake up and my house knows more than it did when I went to bed.

Thing two: it refuses to guess

This is the part I’m proud of. Every exact fact carries its source and a confidence level. A battery type from the manufacturer’s manual is “verified” and it gets cited. A spec from a random Amazon listing is “reported” and ranked lower. And when I ask something it doesn’t actually know, it says so.

you ▸ what size is the kitchen toe-kick vent?
abode ▸ Not recorded. It's marked TODO, needs measuring. I won't guess.

An AI that says “I don’t know” instead of inventing a confident wrong number. For house facts, where the wrong answer means a second trip to the store or a part that doesn’t fit, that refusal is the feature.

I ran a little eval suite over it to make sure. Twenty-one questions, answered cold. It got the exact facts right, with sources, and on the three questions it shouldn’t know, it refused all three. That’s the behavior I want from something I’m going to trust with my house.

Why a folder beats an app

I could have built a slick app with a database. I’m glad I didn’t. The folder is portable, it diffs in version control, it works with any model, and I own it. There’s no service to shut down, no export button I’ll go hunting for in five years. When the next better model comes out, I point it at the same folder and it just works. Try that with your smart-home app from 2014.

Get it

I open-sourced the framework. The structure, the agent instructions, the playbooks, even the eval harness are all in the repo. My actual house data stays on my machine, gitignored, because you do not need to know my spa’s gallon count. You fork it and fill it with your own home.

→ github.com/nothans/abode101

Go give your house a memory. And maybe check what battery your dimmer takes before you drive to the store. Just a thought…

Microsoft Research just shipped a tool called SkillOpt that takes that idea literally.

SkillOpt is a text-space optimizer that trains reusable natural-language skills for frozen LLM agents through trajectory-driven edits, validation-gated updates, and deployable best_skill.md artifacts.

It treats the skill markdown you hand an agent (the instructions, the system prompt, the SKILL.md) as trainable state. It runs epochs. It has a batch size. It has a learning rate. It just never touches the model weights. The weights stay frozen behind the API. The thing that gets trained is the text.

The loop is short. Run the agent on a batch of tasks. Score each one. A second model reads the failures and proposes small edits to the skill file. Keep an edit only if it improves a held-out score. Repeat. What you get at the end is a best_skill.md you drop in front of the same unchanged model.

I wanted to see it actually work, so I gave it a job…

The setup

I had OpenAI Codex do the writing. The task: take a paragraph stuffed with AI slop and clean it up. The skill it started from was short:

Improve the passage so it reads a little better. Keep the meaning and roughly the length.

No mention of slop. No list of banned words. Nothing to go on.

The verifier was the part that mattered. I wrote a dumb little counter that scans the output for the tells (the canned phrases, the em-dashes) and returns how many are left. Fewer is better. That is the whole eval. Objective, cheap, no judgment calls.

Then I let SkillOpt run.

What it wrote

The seed turned into a thirty-line deslop skill. SkillOpt wrote it.

It worked out, on its own, that “remove AI slop” is a removal constraint and not a tone nudge. It named the exact phrases that kept leaking through (“let’s dive in,” “have you ever wondered,” “it’s worth noting,” “furthermore,” “in conclusion,” “great question”). It flagged em-dashes. And it caught the sneaky failure mode I never told it about: the model dodging a banned word by swapping in a synonym. That one became its own rule, the last line of the file:

Before answering, do a quick scan to ensure none of the original flagged words remain, including close synonyms you may have introduced.

The score went from passing half the held-out passages to passing all of them. The skill it wrote is one I would actually keep.

The part worth keeping

The optimizer is the easy part.

I went in assuming the clever bit was the model proposing edits. It isn’t. The clever bit is the verifier. Give SkillOpt a score and nothing else and it does nothing. I tried that first. It saw the failures, shrugged, and changed not a single line, because “you got a 0.6” tells it nothing about what to fix. The run that worked was the one where the verifier also said which words leaked. Same model, same loop. The difference was the signal.

So the rule of thumb is less “use the self-improving optimizer” and more: can you score this cheaply, and can you tell it why it failed. If yes, the skill mostly writes itself. If no, there is nothing to train and the fancy loop sits there idle.

That is also the catch, and it is the same catch hiding under every self-improving-agent demo. A slop counter is a clean verifier. Most of what you do in a day is not. “Was this brief any good.” “Did this post land.” No cheap score, no training. The optimizer was never the bottleneck. The verifier is.

So build the verifier first. Get that right and the skill mostly writes itself.

Bonus: a taste of running it

The repo is github.com/microsoft/SkillOpt. MIT licensed, Python.

Get it:

pip install skillopt
# or, to poke at the internals:
git clone https://github.com/microsoft/SkillOpt && cd SkillOpt && pip install -e .

The mental model is one small folder per task. A loader that hands over your examples, a rollout that runs your agent and scores it, and a seed skill to start from. SkillOpt’s whole job is to grow that seed.

The config reads like a training run, on purpose:

train:
  num_epochs: 4
  batch_size: 40
optimizer:
  learning_rate: 4        # max edits to the skill per step
  lr_scheduler: cosine
evaluation:
  use_gate: true          # keep an edit only if it beats the held-out score
model:
  optimizer: gpt-5.4      # the model that proposes the edits

Then it is one command:

python scripts/train.py --config configs/yourtask/default.yaml

The only part that is really on you is the scoring. Your rollout returns, per task, a pass/fail and a number between 0 and 1:

return {"id": task_id, "hard": passed, "soft": fraction_correct}

That is the whole contract. Give it tasks, a way to score them, and a skill to start from. It runs the epochs.

One side note: keep the tasks hard enough that the agent fails some of them. If it aces everything on the seed skill, there is nothing to learn and SkillOpt politely does nothing. Ask me how I know.

I read through it expecting to roll my eyes. Instead I sat there nodding, because I’d accidentally built a tiny version of the same thing for this blog.

The pitch

gstack’s whole argument is that solo builders don’t lose to big teams because they’re worse engineers. They lose because they skip process. One person at a keyboard, prompting Claude into existence one vibe at a time, eventually ships something that works. Until it doesn’t. No review. No second opinion. No one asking “wait, should we even build this?”

So gstack bakes the process in. Every skill is a slash command, and each command plays a role in a pipeline:

Think → Plan → Build → Review → Test → Ship → Reflect

You start a project with /office-hours, which hits you with six forcing questions before you write a line of code. Then /plan-ceo-review challenges your scope. /plan-eng-review draws the data-flow diagrams and enumerates the edge cases. You build. /review does a staff-engineer pass and auto-fixes the obvious stuff. /qa opens an actual Chromium browser, clicks through your app, finds bugs, and writes a regression test for each one it fixes. /ship runs the suite and opens the PR.

Each stage feeds the next. The CEO’s decisions constrain the engineer. The engineer’s plan constrains the build. Nothing happens in a vacuum. That’s exactly the part solo work gets wrong.

There’s a whole security wing too. A /cso skill that runs OWASP Top 10 and STRIDE threat modeling. A sidebar Claude that watches for prompt injection. A /careful mode that warns you before rm -rf ruins your afternoon. It’s a lot. The point isn’t that you use all of it. The point is that the roles exist, named and on call.

Why this looked familiar

Here’s the thing. I don’t ship code through a blog. I ship words. But the moment I saw that pipeline I recognized it, because the posts you’re reading go through the same kind of relay.

When I write here, an idea doesn’t go straight from my head to WordPress. It moves through stages, and each stage has one job:

• Research does the digging and writes up a structured report. Pitch, key facts, angle, the competition check.
• Refine tightens the structure and pacing without touching the voice.
• De-slop strips out the AI tells. The em-dashes, the “it’s not just X, it’s Y,” the forced enthusiasm, the closer that tries to sound profound.
• Voice rewrites it to sound like me. Short sentences. Plain words. No throat-clearing.
• Format turns it into clean WordPress blocks.

Each one hands off to the next. Same shape as gstack. A CEO who reframes the product is doing what my research stage does for a post. A designer who catches AI slop is, almost word for word, my de-slop pass. Garry Tan built an org chart for shipping software. I built a smaller one for shipping writing, and I didn’t even notice the resemblance until his showed up.

I’m not claiming I invented anything. The idea is in the water. Once you spend enough time working alongside an agent, you stop treating it like one genius who does everything and start treating it like a team you have to manage. You give each role a narrow job and a clean handoff. That’s not a trick. It’s just how good teams have always worked, now running in a terminal.

The number everyone’s going to argue about

gstack ships with a doc making a bold claim: Garry measured his own output and found he’s writing about 810 times more code per day than he did back in 2013 when he was coding part-time around a day job. Eleven thousand logical lines a day across his first 108 days.

Your skepticism alarm should be going off. So was his. He concedes up front that lines of code is a garbage quality metric. His own line: measuring programming progress by lines of code is like measuring aircraft-building progress by weight. So he deflates the number hard. Strips comments and blanks, applies a 2x penalty for AI being verbose and defensive, and lands at something like 5,700 lines a day. Still a wild figure. Still self-reported, so take it with salt.

But the interesting claim isn’t the speed. It’s the quality holding steady while the speed goes up. A 2 percent revert rate, right in line with the open-source baseline. Two thousand-plus automated tests with CI. A 95 percent success rate across 305,000 skill runs. His actual thesis is buried under the headline number:

“Testing at multiple levels is what makes AI-assisted coding actually work.”

That one I believe without reservation, because it’s the same thing the pipeline is really about. The process isn’t there to make the agent faster. It’s there to catch the agent when it’s confidently wrong, which it will be, several times a day. Every stage is a checkpoint, a chance for something to get caught before it ships. The payoff isn’t speed, it’s fewer mistakes reaching the end.

What I did with it

I’m not installing the whole thing. gstack is TypeScript and Bun and Playwright, built for shipping web apps, and Windows is a second-class citizen in it. Not my stack. Not my use case.

So I stole the front of it instead. The skill I keep coming back to is /office-hours: six forcing questions you have to answer before you’re allowed to build anything. Who is this for. What’s the sharpest version of it. What are you quietly avoiding. It’s a CEO review for an idea that doesn’t exist yet.

That maps straight onto the worst part of blogging, which is deciding what’s even worth writing. So I pointed it at this blog. Before a topic earns a draft, I run it through the same kind of interrogation in Claude Code. What’s the one sentence. Who already wrote it better. What’s the angle only I have. Why now. Most ideas die right there, which is the point. The ones that live show up to the draft stage already knowing what they are.

This post is one of them. gstack was the raw idea. The forcing questions are what turned “gstack exists, that’s neat” into something with an angle worth your time. The tool I borrowed from is the tool that helped me write about borrowing from it.

So here’s what you should know today. gstack is out there, it’s free, and even if you never run a line of it, the shape is worth stealing. Garry Tan built that discipline for code. I run a lighter version of it on words. You can point it at whatever you make. The pipeline is the product. The agent’s just the labor.

Fine for a side-project web app. Does not work for an inverted pendulum spinning on your desk.

The Pit and the Pendulum

MathWorks just published a Tech Talk by Brian Douglas. It is worth watching if you build hardware.

The setup is a Quanser cube servo with an inverted pendulum, a Raspberry Pi running the controller, and a coding agent wired into Simulink through the Simulink Agentic Toolkit. The agent’s job is to swing the pendulum up and balance it.

Balancing an inverted pendulum is a classic control problem because it’s unstable by nature. Get the math wrong and the pendulum falls. Get the code wrong and a 12V motor jerks the cube into something it shouldn’t.

What Happens If You Just Prompt It

The tempting move is the one most of us have done with web apps. Open a chat, describe the system, ask for the code. One prompt, big blob, ship it.

The MathWorks engineers walk through why that falls apart for hardware:

“If you rely on AI to generate code directly, that process is much less structured… it’s often unclear exactly how or why a particular implementation was created, making it harder to trust and verify.”

Brian Douglas

Hardware is unforgiving. You can’t roll back a destroyed motor with a git revert. When a physical system fails, you need to know which assumption broke, which equation got the wrong constant, which sample rate the controller is actually running at. A black box of generated C code doesn’t tell you any of that.

“You don’t want to let your AI agent skip parts of your engineering workflow. That’s how you can get yourself into trouble with a final product that doesn’t meet your objective or worse, is just purely unsafe.”

Brian Douglas

The Workflow Is the Script

The answer is to keep the AI inside the workflow engineers already trust: Model-Based Design. The agent doesn’t replace the workflow. It runs each step inside it, faster.

Define quantifiable requirements. Before any code, the human and the AI agree on what success looks like. Spin-up speed. Wobble limits. The 12V motor constraint. These targets become the benchmarks for verification later.

Use a trusted model. Instead of letting the AI invent a custom physics engine, the workflow points it at an existing Simulink model. The agent runs linearization through the Simulink Agentic Toolkit and reports the system’s poles back to the human. The math comes from validated tools, not from a language model freestyling differential equations.

Use a trusted controller. Same logic. The agent is told to use the MPC Toolbox. Model Predictive Control has decades of theory behind it and a deterministic implementation. If something looks wrong, you can tune it manually. You’re not debugging an optimizer the AI invented on the fly.

Verify in layers. Three stages before the code touches hardware:

• MIL (Model-in-the-Loop): the controller runs against the theoretical model
• SIL (Software-in-the-Loop): the generated embedded C code runs on a computer, behaving exactly like the simulation
• PIL (Processor-in-the-Loop): the C code runs on the actual target Raspberry Pi

Each layer catches different bugs. Skip one and you’ll catch that bug on hardware instead.

Deploy and iterate. Only after layered verification does the code go on the real pendulum.

“Instead of asking an agent to solve your problem however it wants, you tell it to follow an engineering workflow that you understand.”

Brian Douglas

The AI executes. The human directs.

The Hardware Truth

Here’s the part of the video I liked best. They ran the verified controller on the real pendulum and it didn’t quite work. The physical hardware behaved differently from the model.

This is what the vibe-coding fantasy ignores. Reality disagrees with simulation, especially the first time. You will need to iterate. The thing that matters is whether you can.

Because the team followed the workflow, they could. The model was traceable. The requirements were quantifiable. The controller was inspectable. They used the AI to update the physics model, ran it back through MIL, SIL, and PIL, and tried again. No starting over.

The workflow doesn’t promise perfect code on the first pass. It promises code you can fix.

The Director Pattern

A few months ago, I wrote about Seth DeLand’s framing of agentic AI for engineers. The headline idea: you’re not being replaced, you’re being promoted. The engineer becomes the one who defines the problem, sets the constraints, and shapes the space where the AI works.

The MathWorks Tech Talk is what that looks like in hardware. The AI isn’t the engineer. It’s the agent. You’re the director.

“Agentic AI is powerful, but for engineering, the value comes from how you use it. You get the speed and productivity benefits of AI without sacrificing trust, safety, or understanding.”

Brian Douglas

You don’t get speed and safety together by handing the AI a prompt and crossing your fingers. You get there by keeping the workflow you trust and letting the agent move faster inside it.

Speed without losing safety. Productivity without losing traceability.

For software, vibe coding is mostly fine. The blast radius is a wasted afternoon.

For hardware, the blast radius is a sparking motor and a pendulum on the floor.

OpenAI shipped gpt-image-2 on April 21, 2026, and it is the first image model that actually belongs in a production pipeline. Not because the pictures are prettier. Because the API finally does the things I kept wanting the old one to do.

What actually changed

Three things, and you can ignore the rest of the announcement.

It reads and writes legible text. OpenAI claims ~99% accuracy on typography, including CJK and right-to-left scripts. That is a big deal if you have ever tried to generate a product label or a slide deck header and gotten cursed runes back. The old model was a pixel painter. The new one is a pixel painter that can spell.

It thinks before it draws. There is a reasoning pass baked into the model now, a “think about the scene, then render” step. You do not have to configure it. You do not pay a thinking-mode surcharge on the standard API call. It just converges faster. Prompts I used to iterate on three or four times now land on the first or second try.

It edits images. Real editing, not “here’s a new image that vaguely resembles your old one.” You pass in a picture and a description of what you want changed, and the rest stays put. This is the capability that makes it worth wiring into a pipeline.

The minimum viable call

If you have Node 20+ and an OpenAI API key, this is the whole thing:

curl https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2",
    "prompt": "A cinematic 4K landscape of an AI data center at twilight",
    "size": "1536x1024",
    "quality": "high"
  }'

You get back base64 image data in data[0].b64_json. Write it to a file. Done.

One thing that tripped me up: do not send response_format. The docs say it is not supported, and they mean it. The API rejects the request with HTTP 400. All responses come back base64 only. If you want URLs, host them yourself.

The edit endpoint is the real unlock

Here is the image I generated first, a photorealistic 4K data center at twilight:

Now here is the same image after a single edit call: “replace the twilight clouds above the servers with a dramatic aurora borealis, ribbons of emerald green, magenta, and electric teal. Keep everything else unchanged.”

No mask. No Photoshop. The server racks are in the same positions. The orange horizon is preserved. The blue light trails between the racks still flow toward the vanishing point. Only the sky changed.

Try doing that with gpt-image-1. You cannot. The /v1/images/edits endpoint existed before, but the results it gave you were not the kind of thing you shipped to production. This is the feature I was waiting for.

The endpoint accepts multiple reference images, which you address inside the prompt as “image 1” and “image 2” for compositing. Style transfer, product placement, character relocation, all one API call.

Three creative moves the marketing post does not tell you about

Aspect ratios no one else gives you. The preset list is short, but size accepts custom values. Both dimensions must be multiples of 16, max edge 3840, aspect ratio up to 3:1, and total pixels between 655,360 and 8,294,400. That range covers Twitter cards at 1200×628, Instagram stories at 1080×1920, blog heroes at 1920×1080, and full 4K landscapes at 3840×2160. No cropping, no upscaling, no extra tooling.

One caveat the docs hide: anything above 2,560×1,440 is officially “experimental.” It works. I generated a 4K image for this post. But OpenAI is not promising SLA on it yet, so budget for occasional failures in production.

Batch consistency. The n parameter goes up to 8, and the model keeps characters and objects consistent across the set. For a product shot or a children’s book page, one call gives you eight variations that actually share visual DNA. Eight variations at medium quality costs about thirty cents. That is a lot cheaper than eight separate prompt-engineering sessions.

Reasoning as a debugging tool. Because the model thinks before drawing, iteration feels different. Vague prompts still produce vague images, but specific prompts land harder. I stopped writing six-paragraph mega-prompts and started writing three-sentence scene descriptions with hex colors and composition direction. The output got better.

Gotchas

Things I wish the docs had told me louder:

• No transparent backgrounds. If you need a PNG with alpha for icon work, you still reach for gpt-image-1. Route by use case.
• Masks are prompt-guided, not pixel-exact. If you are coming from Stable Diffusion, this will feel wrong. The mask tells the model which region to focus on. The model decides how to blend.
• C2PA watermarks are on by default. Every image ships with provenance metadata. Useful for trust, relevant if you were hoping to redistribute without attribution.
• Streaming partials cost extra. Each partial_images frame adds 100 output tokens. Fine for prototyping a UI. Expensive at scale.
• Pricing is per token. $8 per million input tokens, $30 per million output tokens, with the usual caching discount. A medium 1024×1024 lands around four cents. A high-quality 4K lands near eighty cents. The calculator on the docs page will save you some math.

Where to take it

If you are already using image generation in an app, switching is low-risk. Change the model string, drop response_format if you were sending it, and audit for transparent-background assumptions. Your latency will drop. Your text will be legible.

If you are not using image generation in an app, the editing endpoint is the reason to start. Every product that has ever wanted “make this photo match our brand” can now do it with three lines of code.

I rebuilt my cartoon pipeline around the new editing flow in about an afternoon. The first draft of this post was going to be a benchmark comparison. Then I looked at the aurora edit and realized there was nothing to benchmark. Either your tool can do it or it cannot.

gpt-image-2 can.

He didn’t say that. He left and started building something else.

GitButler raised $17 million to rethink version control from scratch. When the person who built the cathedral starts drawing blueprints for something new, you should probably look at the blueprints.

In a recent interview with a16z, Chacon laid out the problem in terms that made me stop scrolling. GitHub was designed for humans. Specifically, for humans working at human speed. And that assumption is baked into everything.

The Pull Request Was Built for People

Here’s the deal with pull requests. They assume someone will read them.

You open a PR. A teammate gets a notification. Maybe today, maybe tomorrow. They click through, scan the diff, leave a comment or two, approve it, and you merge. The whole cycle takes hours or days. Sometimes weeks if the reviewer is busy or the PR is big enough to trigger “I’ll get to it later” energy.

This works when your team is five humans shipping a few PRs a day. It even works at scale, if the scale is more humans. GitHub handled that part beautifully. Issues, reviews, discussions, profiles, stars. The social layer that made open source collaboration feel natural.

But pull requests were never designed for a teammate that generates 200 of them before lunch.

What Happens at a Thousand PRs Per Week

Stripe merged over a thousand agent-generated pull requests in a single week. Let that number sit for a second.

A thousand PRs. In one week. From AI agents.

Now picture yourself as the human on that team. Your GitHub notification count doesn’t just go up. It becomes meaningless. The PR queue isn’t a todo list anymore. It’s a firehose pointed at your inbox.

Code review breaks first. Be honest: when you do code review, do you really read every line? Chacon asked this same question in the interview and the answer is what everyone already knows. Not always. Not even close. At a thousand PRs per week, “cursory glance” becomes “triage by title.” You’re not reviewing code. You’re reviewing your faith in the system that generated it.

Commit history breaks next. Git log becomes a wall of “fix: update component” and “refactor: apply suggestion” with no narrative thread. The story of how your codebase evolved disappears under a flood of mechanical changes. git blame points to an agent. The context that used to live in commit messages evaporates.

Notifications break last, because they were already broken. But now they’re broken at scale. The signal-to-noise ratio doesn’t degrade gracefully. It collapses.

Chacon put it simply in the interview: the whole model assumes human-speed collaboration. When you introduce participants that work at machine speed, the model doesn’t bend. It shatters.

The Pull Request Is the Wrong Unit

Here’s the question I keep coming back to: what replaces the pull request?

Not “how do we make pull requests better for agents.” That’s the wrong question. That’s like asking how to make horse-drawn carriages faster when someone just showed you an engine.

The pull request is a unit of collaboration designed around a specific workflow. One person makes changes. Another person reviews those changes. They discuss. They merge. It’s turn-based. It’s sequential. It’s fundamentally a conversation between two humans about a diff.

When the “person” making changes is twelve agents working in parallel, and they’re generating changes faster than any human can read them, the conversation model doesn’t apply. You don’t need a better conversation. You need a different unit of work.

Chacon’s answer at GitButler is interesting. They built what he calls a “mega-merge” system where multiple branches coexist in a single working directory. Agents can see what other agents are doing in real time. Conflicts surface before they happen, not after someone tries to merge.

That’s a version control answer. But the platform question is bigger. What does the server-side look like? What does collaboration look like when most of the participants aren’t human?

What the Next Platform Actually Needs

I don’t know what the next GitHub looks like. Nobody does. But I can see the shape of the requirements from here.

Real-time conflict detection, not post-merge. GitHub tells you about conflicts when you try to merge. By then, someone (or some agent) has already done the work. In a world with twelve agents writing code simultaneously, you need to know about conflicts as they form. Not after.

Agent provenance. Which agent wrote this code? What prompt generated it? What was the reasoning chain? Right now, the best you get is a commit message that says “Generated by Claude” or “Co-authored-by: Copilot.” That’s like listing “computer” as the author. You need the full trail: the intent, the context, the decision points.

Review at the intent level, not the diff level. Humans shouldn’t be reading thousand-line diffs generated by agents. They should be reviewing the intent: “I asked the agent to refactor the auth module to use JWT instead of session tokens.” Did it do that? Did it break anything? Let another agent verify the diff. The human reviews the goal.

Trust scores on commits. Not every change carries the same risk. A CSS color change and a database migration are not equal. The platform should know this. Flag the high-risk changes for human review. Let the low-risk ones flow through with automated verification.

Parallel visibility. If three agents are working on the same codebase, each one should know what the others are doing. Not through pull requests after the fact. In real time. This is what GitButler’s mega-merge is trying to solve at the local level, but it needs to exist at the platform level too.

None of this looks like a pull request queue. It looks more like air traffic control. Multiple things moving at once, a human watching the board, stepping in when something looks wrong.

The Builder’s Question

GitHub won because it made one thing simple: collaborating on code with other humans. The entire product was built around that idea. It worked brilliantly for twenty years.

The next platform will win by making a different thing simple: collaborating on code with a mixed team of humans and agents. That’s a different design problem. The social features that made GitHub great (profiles, stars, discussions, PR reviews) were designed for people who have attention spans, opinions, and feelings. Agents have none of those.

Chacon said something in the interview that stuck with me. He said the constraint isn’t “can we produce the code” anymore. It’s “can we agree on what we want.” The bottleneck moved from implementation to communication. From typing to thinking.

If that’s true, the next collaboration platform isn’t optimized for code review. It’s optimized for intent. For specification. For making sure twelve agents and three humans are all building the same thing.

I don’t know who builds it. Maybe GitButler expands into the server side. Maybe someone we haven’t heard of yet starts from scratch. Maybe GitHub pivots faster than Chacon expects.

But I’m pretty sure of one thing. When it arrives, it won’t look like a pull request queue.

It’ll look like something we don’t have a name for yet.

So when I say that Anthropic just had one of the funniest self-owns in AI history, I’m saying it with genuine affection.

What Happened

On March 26, 2026, security researchers Roy Paz of LayerX Security and Alexandre Pauwels of the University of Cambridge found nearly 3,000 unpublished Anthropic documents sitting in a publicly accessible, unencrypted data store. Draft blog posts. Internal documents. Details about an unreleased model that the company hadn’t announced yet.

The root cause? Anthropic’s content management system was configured to make all uploaded assets public by default. Unless someone manually toggled a setting to “private,” everything was searchable by anyone with basic technical knowledge.

Fortune broke the story. Anthropic locked it down. But by then, everyone had already seen the surprise party decorations.

Among the exposed drafts was a blog post describing a new model called Claude Mythos. Anthropic has since confirmed the model is real, telling Fortune it represents “a step change” in performance and is “the most capable we’ve built to date.” A small group of early access customers is already testing it.

Meet Mythos

The leaked documents describe Mythos (internal codename “Capybara”) as a new tier of model above Opus.

Compared to Claude Opus 4.6, which only recently topped Terminal-Bench 2.0 at 65.4%, the leaked draft claims Capybara achieves “dramatically higher scores” on tests of software coding, academic reasoning, and cybersecurity.

No specific benchmark numbers have been released. “Dramatically higher” is doing a lot of work in that sentence. But the framing is clear: Anthropic considers this a generational jump, not an incremental one.

The model is also expensive. Anthropic acknowledged in the draft that Mythos is “very expensive for us to serve, and will be very expensive for our customers to use.” They’re working to make it more efficient before any general release.

The Cybersecurity Paradox

One of the leaked drafts describes Mythos as “currently far ahead of any other AI model in cyber capabilities.” It warns that the model could “exploit vulnerabilities in ways that far outpace the efforts of defenders.” Mythos can apparently find and exploit software vulnerabilities at a speed and scale that current cybersecurity tools can’t match.

You have to appreciate the comedy here. An AI company built a model so powerful at finding security holes that they’re worried about releasing it. And the reason we know this is because they left their own security holes wide open.

They built a model that finds vulnerabilities faster than defenders can patch them. Then they stored the announcement in a system where the default setting was “public.” The model finds flaws. The company forgot to check its own.

Wall Street, meanwhile, was not laughing. Cybersecurity stocks dropped hard on March 27. The iShares Cybersecurity ETF fell 3%. CrowdStrike and Palo Alto Networks dropped 7%. Tenable cratered nearly 11%. Okta and Netskope fell more than 6% each. The fear isn’t just about Mythos specifically. It’s about what happens when an AI model can automate threat detection and response at scale, commoditizing the products that cybersecurity companies charge premium prices for.

Defenders First

Anthropic’s release plan for Mythos is new. Instead of the usual approach (announce model, launch API, post benchmarks, collect revenue), they plan to release Mythos first to cyber defense organizations before making it broadly available.

The logic makes sense on paper. If the model is as good at finding exploits as the leaked docs suggest, you want the defenders to have it before the attackers do. Give the good guys a head start.

But I have questions.

What counts as a “cyber defense organization”? Government agencies? The Pentagon? CrowdStrike? A startup with “cyber” in the name? The criteria matter. And Anthropic hasn’t shared them, because they hadn’t planned to share any of this yet.

There’s also a part of me that wonders if this is partly great marketing. Telling the world “our model is too powerful for general release” is a very effective way to generate demand. Nothing sells like exclusivity.

This isn’t the first time a frontier model got a staggered release. OpenAI gave the US government early access to GPT-4. But Anthropic is making the security framing explicit and central. That’s new.

Safety as a Brand

Anthropic was founded in 2021 by former OpenAI researchers who left because they wanted to focus more on AI safety. That origin story is central to their identity. They’re not just an AI company. They’re the safety-first AI company. It’s in the pitch deck. It’s in every press release. It’s in the name of their alignment research.

The thing about building your brand around safety is that people notice when you trip over your own shoelaces. Alignment research is important. Constitutional AI is interesting work. But if your CMS is set to “public by default” and nobody catches it until a security researcher at Cambridge finds your secret model in a public bucket, people are going to have some fun with that.

This wasn’t a sophisticated attack. Nobody hacked anything. The documents were just there, sitting in the open, waiting to be found. A misconfigured toggle. “Human error,” Anthropic called it. Which, honestly, is relatable. Every engineer has shipped something with a default they forgot to change. It just usually doesn’t end up in Fortune.

I don’t doubt that Anthropic cares about safety. I think they do. But there’s a growing gap between “philosophical safety” (how do we align superintelligent systems) and “operational safety” (how do we not leave 3,000 confidential documents in a public database). You need both. The second one is less glamorous, but it’s the one that actually tripped them up this week.

I’m still a fan. I’m still going to use Claude tomorrow. But I will admit there’s something poetic about a company that warns its own model could be a cybersecurity nightmare, getting undone by a CMS default setting. You couldn’t write it better if you tried.