> all frontier models benefit from more tokens not just Kimi K3
Past a point, that doesn't hold and the score plateaus.
Token hungry models tend to plateau at a much higher token count. Because Kimi K3 is a token hungry model – and 100M tokens (including cache hits) seems at the edge of the plateau for these evals – it could disproportionately benefit from a higher token budget.
For Kimi K3 specificially, policymakers are interested in whether it can find and exploit the same scope of vulnerabilities as models like Mythos. In that context, an answer of "yes, but with quintuple the token budget" is materially different from "no, it performs significantly below the most recent frontier cyber-capable models".
(As an aside, I like the UK AISI and think they're the best example of that kind of group!)
> Kimi K3 performs significantly below the most recent frontier cyber-capable models
UK AISI cyber evals seem to under-elicit capabilities from quirky models [1]. Kimi K3 is a token-hungry model, and I suspect it hit the eval's 100M token limit well before saturating scores [2].
This gap was true for GLM 5.2 as well; they ranked it at Opus 4.5 level [3]. Both anecdotally and with a held-out eval, I've found GLM 5.2 to be better at security research than Opus 4.6 [4]. But it's a quirky model that degrades quickly at long context lengths.
Personally, I'd rank Kimi K3 above Opus 4.8 and lower than GPT 5.6 Sol in its ability to find vulnerabilities and exploit them. But it's not far from the frontier.
[1]: From the UK AISI: "Our setup likely slightly underestimates open weight models’ maximum capability: we didn’t pursue specific elicitation or optimisations which could have improved performance" (https://www.aisi.gov.uk/blog/how-far-behind-the-frontier-are...).
[2]: Their eval also counts cache hits towards the token budget; the 100M token budget is comparable to a ~5M token budget in other evals.
Almost exactly a year ago, we released Opus 4.1. It was definitely capable of finding vulnerabilities, and people were using custom harnesses to do so quite effectively.
The newer models are still more capable, but there were people doing this and writing about it (e.g. XBOW).
Yes, I think you could probably get something similar from Opus 4.5 (2025). Definitely Opus 4.6. I still think recent models are more capable, though!
Some of the model behaviors that make it better at pentesting, like persistence, can be improved with harness-level tricks (e.g. alloys, automated nudges, pre-fill to promote persistence, coordinated swarms, etc).
You mentioned the UK AISI's evals. Their harness is like basic Claude Code with compaction, and it doesn't include any of these tricks (afaik). As a result, I interpret their evals as a lower-bound of capabilities.
Newer models are still more capable, and they require almost no harness to find and exploit vulnerabilities. They're also more capable of performing more complex long-horizon attacks. But we've been past the threshold of modes capable of autonomous hacking for a while now [1].
Regardless of whether this statement is PR, consider that many people in frontier labs are taking this – and similar incidents – as an expected/prophesied step on the path towards AGI, expect the trends to continue, and are still marching forward without demonstrably adequate safeguards.
It has been clear since January that cybersecurity capabilities are solidly within the realm of autonomous hacking [1]. Sandbox escapes are extremely common [2]. I regularly open claude.ai/code and ask the agent to try to escape a sandbox that has "no internet access", and it usually finds a way [3]. (I know this is neither OpenAI nor training infrastructure, but the general pattern holds.)
I don't think models are uncontainable at this point. I do, however, think safeguards at frontier labs aren't adequate for their expected rate of capabilities growth.
This is despite many well-intentioned people working hard to decrease risk. But if you can't demonstrate adequate safeguards at the frontier, then maybe you shouldn't be pushing it.
Kimi K3 only supports "max" reasoning effort right now, but they plan to enable other levels soon [1].
When I looked at traces from benchmarking, I saw a lot of backtracking and uncertainty while reasoning ("wait, but..."). This also happens with GPT 5.6 and Fable with xhigh/max thinking, albeit to a lesser degree.
I think that explains part of the token inefficiency. Hopefully it will improve with lower reasoning effort settings.
1) This Sankey chart is missing some layers, and as a result it's kinda misleading. Some examples:
- I'm no longer at Anthropic, and many others are no longer at OpenAI.
- Tom Brown didn't jump straight from a group dating app to co-founding Anthropic; he spent several years at DeepMind and OpenAI.
- Brian Krausz worked several places in the ~decade between his YC startup and Anthropic. He then left Anthropic but was brought back in with the Stainless acquisition.
- Stefan Stokic ran a non-YC startup for five years before joining OpenAI.
2) I don't think 35 people joining Anthropic or 70 joining OpenAI at some point after doing YC is a substantial concentration at a macro level. That's <1% of YC founders, even if you include those who no longer work at either of the companies.
3) As for why people joined: beyond the compensation, it isn't clear that a startup is more impactful than powerful AI in their domain. Here's an excerpt from an email I sent to one of the Anthropic co-founders when I was considering joining in 2024:
> For context, my YC company builds dev tooling for bioinformatics. [...] I no longer have the conviction that our niche-specific dev tooling is going to have a significant impact on the field as we approach expert-level AI.
Ultimately, the core value of our product was actually supplanted by LLMs; bioinformaticians are much better at writing code and managing infrastructure with LLMs.
I think more and more folks are seeing the impact of what they'd build as a subset of what powerful AI could do, and as a result they end up joining a lab.
I'm on the list. I had real professional experience with HPC infra for comp bio, but that wasn't my role at Anthropic. There's a lot more to do at the company than manage infrastructure.
Tom Brown, an Anthropic co-founder who was also a YC founder, does lead compute. There were many years between his YC company and Anthropic, including time at OpenAI.
Others on the list went straight from their startup to OpenAI/Anthropic but to a team that fit them well. For example, Stefan went to a team at OpenAI where he works with startups, Lenny went to work on product (early ChatGPT), and Raza's YC startup was evals/observability for LLMs.
I think Inkling actually makes sense as a sustainable open-weight model!
A few months ago, I tried using their Tinker product to finetune/post-train an open weight model, but I found it easier and cheaper to just build from scratch.
Ideally, I want to test RL environments on a small model and then scale up to a large model. That's hard to do right now, in part because there's no good family of open-weight models with a great small and large MoE variant [1]. It's extremely time consuming and hard to build long-context training infra for different models with different architectures.
If they go all-in on integrating Tinker with their own models and building efficient long-context training I could see myself using Tinker with Inkling.
Because of that, I think building their own models actually makes sense! And it seems like there's a corresponding business model to support it.
[1] Qwen models are the closest: Qwen 3.6 35B A3B is a capable small MoE model, and larger open weight Qwen models exist. But they aren't as performant as the alternatives, because their frontier models – like Qwen 3.6 Plus – are no longer open weight.
I think this actually makes sense as a sustainable product for Thinking Machines!
A few months ago, I tried using Tinker to finetune/post-train an open weight model, but I found it easier and cheaper to just build from scratch.
Ideally, I want to debug RL environments on a small model and then scale up to a large model. That's hard to do right now, in part because there's no good family of open-weight models with a great small and large MoE variant [1].
Concretely, my go-to small model for finetuning is Qwen 3.6 35B A3B. To test with a large model, I need to switch to Kimi K2.6 or GLM 5.2. It's extremely time consuming and hard to build long-context training infra for different models with different architectures.
In theory, their Tinker product already solves that with a consistent training API over several open weight models. But when I tried to use it, I found it easier and cheaper to just build from scratch. If they go all-in on integrating Tinker with their own models and building efficient long-context training, I could see myself using Tinker with Inkling.
Because of that, I think building their own models actually makes sense! And it seems like there's a corresponding business model to support it.
[1] Qwen models are the closest: Qwen 3.6 35B A3B is a capable small MoE model, and larger open weight Qwen models exist. But they aren't as performant as the alternatives, because their frontier models – like Qwen 3.6 Plus – are no longer open weight.
I assume they do hallucinate, just like with coding or finding vulnerabilities.
You can try to minimize it (e.g. with a reviewer agent, which Claude Science and Biomni have), but nothing is perfect, so I limit autonomous work to verifiable problems and review it.
I can't speak for Claude Science, but I prefer using Biomni as an agent for bio over Claude Code with a custom setup because a) Biomni stays on the frontier for bio, b) it has a config that just works and skills I trust are correct, and c) it has better built-in abstractions for long-running sessions.
As a concrete example, computational biology jobs sometimes run for hours on the Biomni HPC. When they're done, the session needs to reawaken, process the results, iterate, etc. You can implement something like this with agent callbacks, but it's not as straightforward.
This repeats many times for many integrations, so it's just simpler for me to use an agent that's built for exploratory bio and already has all of this. Claude Science has some of these features, so I imagine they're aiming for something similar.
I built one of the connected tools included in this launch (the Biomni HPC [1]), and I have spent an inordinate amount of my life working on this problem. (I also worked at Anthropic, but not on this product.)
As other comments have pointed out, this is for data science – but it's capable of more than making plots and writing papers [2]. It has integrations with many databases and computational tools, including a researcher's institutional cluster.
That alone is valuable. I founded a startup after struggling with this problem at a bio startup; integrating these tools and databases is hard and time consuming. If the only outcome of this product is that great APIs are built for LLMs, it will be a massive positive impact. Many databases used in computational genomics are still only accessible through FTP!
LLMs are particularly good at navigating these tools and databases. It's often very specialized, but straightforward, work that benefits from in-context skills. Seeing an early glimpse of my former customers – bioinformaticians – using LLMs to solve this problem is what led me to join Anthropic in 2024.
Also, this pattern isn't fundamentally constrained to data science: you can also integrate with a wet lab or a CRO for some kinds of science. This is what I'm spending my time on now.
This type of science doesn't solve everything, but it's useful in some niches. For example, progress on many rare diseases is bottlenecked by researcher attention rather than a fundamental breakthrough.
For that eval, I used an account that was labeled as a known red-teaming org by Anthropic, and I read the traces. There were no refusals or obvious avoidance behaviors, though it may have been silently nerfed.
On the same eval, Opus 4.7 and 4.8 outperformed GLM 5.1, but GLM 5.2 is on par again with Opus. So it's at least partially measuring capabilities without respect to refusals.
One possible contributing factor is that model capabilities are shaped differently (an example of this is GLM 5.1 vs. DeepSeek v4 Pro: https://dualuse.dev/posts/deepseek-v4-thinks-different). So if you use RL-based "distillation" from multiple models like Opus 4.x and GPT 5.x, you could get a more capable model.
Email is my [email protected]
Formerly at Anthropic, co-founder of Toolchest (a YC startup), and a bio startup