Last week, Anthropic accidentally left nearly 3,000 internal files in a publicly searchable data store. Among them: a draft blog post announcing a new model called Claude Mythos, described internally as “by far the most powerful AI model we’ve ever developed.”
The company blamed a CMS configuration error. Security researchers found the cache first. Fortune broke the story. And within hours, Anthropic confirmed the model is real: a new tier, sitting above Opus, representing what they called “a step change” in performance.
Before Anthropic locked down the data store, technology-focused news leaker M1Astra archived both versions of the draft blog post and created a live website backup, showing two copies of the same announcement: one branded “Mythos,” one branded “Capybara,” suggesting Anthropic was still deciding on the name when the leak hit.
Cybersecurity stocks dropped 4 to 7 percent in a single session. CrowdStrike fell 7.5%. Palo Alto Networks dropped 6%. The iShares Cybersecurity ETF hit its lowest close since November 2023. All on the basis of a leaked draft blog post from an AI lab claiming advancements in its cybersecurity capabilities.
This all happened, by the way, the same week major news outlets reported that Anthropic is eyeing an October IPO at a $380 billion valuation. Make of that timing what you will.
Here’s what we actually know, what we don’t, and what you should be doing about it right now.
The leaked draft describes Mythos as a new model tier, not just a version bump. Mythos sits above Opus in the same way Opus sits above Sonnet. Bigger, more capable, more expensive. The draft claims “dramatically higher scores” on coding, reasoning, and cybersecurity benchmarks compared to Opus 4.6.
The cybersecurity angle is the headline grabber. Anthropic’s own draft warned that Mythos is “currently far ahead of any other AI model in cyber capabilities” and that it “presages an upcoming wave of models that can exploit vulnerabilities in ways that far outpace the efforts of defenders.” Anthropic has reportedly been privately warning senior government officials that models at this capability level make large-scale cyberattacks significantly more likely this year.
The company is restricting early access to cybersecurity-focused organisations first. The draft also acknowledged the model is “very expensive for us to serve, and will be very expensive for our customers to use.”
A second leak days later, where Claude Code’s full source code was accidentally published to NPM instead of just the compiled version, provided further corroboration that the Mythos model was actively in preparation.
Here’s what I’d ask you to do before forming your opinion on Mythos: hold two things in your head simultaneously.
First, the capability jump is probably real. The scaling laws haven’t broken. Training on next-generation hardware (GB300 chips) does produce measurably more capable models. We have seen this pattern play out with every significant compute increase over the last three years. The cybersecurity evidence is particularly compelling because vulnerability discovery is one of the domains where model capability translates most directly into measurable output. It’s not subjective, either you find the zero-day or you don’t.
Second, the narrative around it is being carefully shaped. The leaked draft is marketing copy for a product launch. It reads like a blog post because it is one. There are no public benchmark scores, no pricing, no context window details, no independent verification. The language (”by far the most powerful,” “unprecedented,” “step change”) is doing commercial work. It is calibrated to land with investors, enterprise buyers, and the press in exactly the way it has landed.
Both of these things can be true at the same time. The model is probably very good. The story being told about it is also optimised for maximum impact at a moment when Anthropic is preparing for the most consequential financial event, an IPO, in its short history.
Read accordingly.
Most coverage is asking: how powerful is Mythos? That’s interesting but not actionable. The question that matters if you work with these models, whether you’re building production systems or managing a team that uses AI every day, is different.
It’s this: which parts of how we work with AI are genuinely ours, and which parts are workarounds for the model not being good enough?
Every team and every production system accumulates layers over time. Some encode real business logic: your policies, your compliance requirements, your quality standards. Those are yours. They should survive any model upgrade. But a lot of other parts of those layers are compensations. Workarounds for model limitations that were real six or twelve months ago. When a materially more capable model arrives, those layers don’t just become unnecessary. They become drag.
1. Treat every model upgrade as a deletion opportunity. Before you test whether the new model does your current workflow better, test whether pieces of it can be removed entirely. Run your prompts with sections deleted. Run your pipeline with stages bypassed. Measure what gets worse versus what stays the same or improves. The right first test isn’t “does it perform better?” It’s “how much of the existing system does the new model make unnecessary?”
2. Separate your “what” from your “how” in writing, today. Tag every component in your system prompts and workflows as either an outcome specification or a procedural instruction. When the new model drops, you test by removing “how” components and keeping “what” components. If you haven’t tagged them, you won’t know which is which under time pressure.
3. Log your human interception rates now. For every verification step, human review stage, and fallback path in your workflow, start measuring how often it actually changes the output. Not how often it runs, how often it matters. When the new model arrives, you re-measure. If the rates drop, you know which steps to thin out.
4. Identify your org chart’s model dependency. Look at every role and process that exists because of AI limitations. For each one, ask: “If the model’s error rate dropped by 80%, would this role or process still exist in its current form?” You’re not making staffing decisions today. You’re building the map so you can move fast when the capability jump is real and measurable.
5. Build your next system around outcomes and tools, not procedures. Define what you want accomplished, the constraints it must satisfy, and the tools it can use. Stop there. Don’t write the procedures up front. It assumes the model can’t do it with its own intelligence. If it fails, add the minimum scaffolding necessary and tag it as compensating complexity so you know to re-test it on the next model.
At Visory, we’re thinking through this right now. We’re looking at every layer in our system and ask a simple question: is this here because of our business, or because of the model? The first category stays. The second category becomes a candidate for simplification or removal when a more capable model arrives.
If you’re a power user chatting with Claude (or any other frontier model), the practical implication is straightforward. You can be less prescriptive about method and more specific about outcome. As models get more capable, the leverage shifts from telling them how to work to telling them what done looks like. Describe the end state. Explain the constraints. Provide the inputs. Let the model figure out the path.
If you’re leading a team that uses AI in its workflows, the question is whether your processes were designed around what the AI can do right now, or whether they’re designed to be upgraded when capabilities improve. Most teams I talk to have built around current limitations without documenting which pieces are limitations-driven versus business-driven. That documentation is the preparation that actually matters.
The hype cycle around Claude Mythos will play out on its own schedule. There will be breathless coverage when it launches. There will be benchmark wars. There will be debates about pricing and access tiers.
None of that changes what you should do today. To use a sports analogy, you should be “Running to where the ball is going”. Practically speaking, this means we should try and anticipate the changes ahead of time and prepare for them.
The preparation that counts is about building systems, whether that’s a production platform or your own personal workflow, where you know which parts are yours and which parts are the models. Because Mythos isn’t the last step change, it’s just the next one. And the one after that will arrive faster than you expect.
The teams and individuals who thrive through these transitions aren’t the ones who react fastest to each new model announcement. They’re the ones who’ve built the habit of asking, with every system and every workflow: what here is mine, and what here is scaffolding I can let go of?
At Visory, we’ve been building this way for two years now. Not because we predicted Mythos, but because when you run AI in production every day, you learn quickly that the only constant is that the model will get better and your architecture needs to accommodate that.
Review your approach, ask the first principle questions, run to where the ball is going. Do it now. You’ll thank yourself when the next model drops, whether it’s called Mythos, Capybara, or something else entirely.
If this resonated, share it with someone who is navigating the same shift. Best, Thomas
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.