Jun 30, 2026 Jun 30, 2026 Last week I released webernetes, a partial port of Kubernetes to TypeScript to make it possible to run clusters in the browser. I ended up generating almost 100,000 lines of code in 552 commits across 629 files. It took me 2 months. The demo below is a webernetes cluster. It runs entirely in your browser, and it’s genuinely doing much of the same work a real Kubernetes cluster does: pod lifecycles, cluster DNS and networking, container garbage collection, IP allocation, Deployment and ReplicaSet tracking, and more. The blue dots represent pods sending requests to each other. Interactive Webernetes demo showing HTTP requests moving between three pods from a Deployment across three Kubernetes nodes. A cluster in your browser Starting simulated cluster. node-1 node-2 node-3 The question I’ve been getting most often is: “Did you compile Kubernetes to WebAssembly?” The answer is no. A simple “hello, world!” Go program compiled to WebAssembly is ~540KiB gzipped. That alone is already bigger than webernetes, which is ~140KiB gzipped. Compiling all of Kubernetes to WebAssembly would no doubt mean sending megabytes over the wire. I did try to check, but unfortunately there are compile-time errors because Kubernetes calls system-level APIs that aren’t available in the browser. Instead, webernetes is: As a result of the desire to keep webernetes small, it doesn’t pull real images from a registry like Docker Hub. Instead, it has its own browser-based registry and you define images using a TypeScript API. Images look like this: 1import * as w8s from "@ngrok/webernetes";2 3class HelloWorld extends w8s.BaseImage {4 static readonly imageName = "hello-world";5 static readonly imageVersion = "1.0";6 7 async exec(ctx: w8s.ProcessContext, argv: string[]): Promise<number> {8 ctx.listenHttp(8080, async (_ctx, request) => {9 return {10 status: 200,11 body: "Hello, world!",12 };13 });14 return await ctx.waitUntilKilled();15 }16} To deploy your image into a cluster, you do this: 1import * as w8s from "@ngrok/webernetes";2 3class HelloWorld extends w8s.BaseImage {4 // as before ...5}6 7const cluster = new w8s.Cluster();8await cluster.registerImage(HelloWorld);9 10const [pod] = await cluster.apply([11 {12 apiVersion: "apps/v1",13 kind: "Deployment",14 metadata: { name: "hello-world-deployment" },15 spec: {16 replicas: 1,17 selector: {18 matchLabels: { app: "hello-world-pod" },19 },20 template: {21 metadata: {22 labels: { app: "hello-world-pod" },23 },24 spec: {25 containers: [26 {27 name: "hello-world-container",28 image: "hello-world:1.0",29 },30 ],31 },32 },33 },34 },35]); And then you can use the webernetes API to interact with the cluster, like this: 1// List all pods in the default namespace2const pods = await cluster.api.corev1.listNamespacedPod({3 namespace: "default",4});5 6// Watch for changes to pods in all namespaces7const informer = cluster.informer("pods", (type, pod) => {8 console.log(`pod ${type}: ${pod.metadata?.name}`);9});10 11// Stop the informer when you're done12await informer.stop();13 14// Listen to pods sending requests and responses to each other.15// This is how I visualise the moving dots above.16cluster.on("request", (event) => {17 console.log(`request: ${event.request.method} ${event.request.url}`);18});19cluster.on("response", (event) => {20 console.log(`response: ${event.response?.status}`);21});22 23// Use the cluster network to send a request to a pod. This will also trigger24// the request/response event handlers above.25const pod = pods.items[0];26const resp = await cluster.fetch(`http://${pod.status?.podIP}:8080/`);27console.log(resp.body); // "Hello, world!" There are plenty more examples in the webernetes repository. Webernetes is intended to be used to make interactive Kubernetes content; it’s not a production-ready Kubernetes distribution. It doesn’t need to run real images. It just needs a way for creators to set up specific workloads to illustrate the thing they’re trying to teach. Over time, it is my intention to expand webernetes to support more Kubernetes features. Right now, it doesn’t support ConfigMaps, Secrets, pod resources, persistent volumes, and a whole host of other things I haven’t needed yet. As I make more content with this library, I’ll implement more of what I need. If you’re looking to build on webernetes and it doesn’t support something you need, please reach out! I’m s.rose@ngrok.com and I’d be happy to help you become a contributor. Almost all of the webernetes code was authored by LLMs. I expect people to be dubious of the project as a result. I expect to be accused of slop-porting Kubernetes for views, but I’m going to try to show you that’s not what I’ve done. I did two things that I think make this a slop-free project: The first point, by far the most time-consuming, is how I gained the confidence that the vast majority of the code is line-for-line identical to the Kubernetes Go codebase. The second point is how I made sure the lexical similarity translates to identical behaviour in practice. Any mistakes that remain in the codebase after my review are on me, and I’ve no doubt some exist. If you find any, please let me know by opening an issue. The stories I’ve read about LLMs being used to write a C compiler or port Bun from Zig to Rust were made possible by having an automated way to assert correctness. Anthropic had plenty of existing C compilers to compare against, and Bun had a large existing test suite that its maintainers trusted enough to merge over 1 million lines of new Rust code without manual review. I didn’t have those things. If I wanted a test suite, I’d need to write it myself. If I wanted to compare against real Kubernetes, I’d need to figure out a way to do it. Most of the code in webernetes is ported from the Kubernetes Go codebase. I ported it with LLMs because I was confident that would be faster than typing it by hand, but the problem I quickly encountered was that LLMs suck at porting code. No matter how hard I tried, they kept making mistakes. The mistakes came in a few flavours: Map instead, leading to incorrect behaviour.I know at least a few of you are screaming “SKILL ISSUE” and are ready to comment saying I need to get better at prompting. That could be true! I would love to see an example prompt that perfectly one-shots porting this table test from Go to TypeScript. You stand to save me an enormous amount of time in future. Until then, for me to have confidence in an LLM porting something, I need to review the output. I’m not aware of any shortcuts. It’s all well and good to know that the code is side-by-side identical, but does it actually work? Go and JavaScript have different runtime environments, so it was always possible that the same code would behave differently in each. I also ended up having to create JavaScript versions of channels, mutexes, Go’s select statement, and other Go-isms. I needed to know they worked in non-trivial scenarios. To feel good about this, I wrote tests where the exact same code is run against both webernetes and a k3s cluster. To do this, I needed to have an API for webernetes that matched an existing Kubernetes API. I picked kubernetes-client/javascript because it’s the official client library for Kubernetes in JavaScript, and it has TypeScript types. Here’s an example test: 1import { expect, it } from "vitest";2import { kubernetes } from "../../test/harnesses/kubernetes";3 4// `kubernetes.describe` does some magic behind the scenes to set up either a5// k3s (https://k3s.io/) cluster or a webernetes cluster and pass that in via6// the `context` argument.7//8// Then I can run either `pnpm test:node` or `pnpm test:browser` to run tests9// against k3s using a Node environment, or webernetes using a headless browser.10kubernetes.describe("Pods", (context) => {11 const { core } = context;12 const { getTestNamespace, waitFor } = context.helpers;13 14 it("should be able to delete a pod", async () => {15 // Tests get their own unique namespace for isolation from each other16 const namespace = await getTestNamespace();17 18 await core.createNamespacedPod({19 namespace,20 body: {21 metadata: { name: "delete-test" },22 spec: {23 containers: [24 {25 name: "pause",26 // Webernetes has an implementation of this image built-in27 image: "registry.k8s.io/pause:3.10",28 },29 ],30 },31 },32 });33 34 // Make sure the pod definitely exists before moving on.35 await waitFor(async () => {36 const pods = await core.listNamespacedPod({ namespace });37 const found = pods.items.find((pod) => pod.metadata?.name === "delete-test");38 expect(found).toBeDefined();39 });40 41 await core.deleteNamespacedPod({42 name: "delete-test",43 namespace,44 });45 46 // Wait until the pod is definitely gone before declaring success.47 await waitFor(async () => {48 const pods = await core.listNamespacedPod({ namespace });49 const found = pods.items.find((pod) => pod.metadata?.name === "delete-test");50 expect(found).toBeUndefined();51 });52 });53}); The core object, with its createNamespacedPod and deleteNamespacedPod methods, is an example of the kubernetes-client/javascript API. The kubernetes.describe(..) helper I created to run these tests injects a core object that points at k3s when I run pnpm test:node , and at webernetes when I run pnpm test:browser . These are the integration tests for the project. They make sure that my porting work is correct and my custom browser-based container runtime and cluster network are working in a way that matches a real cluster. Whenever I spot a bug while working with the library, the first thing I do is create a test that passes against k3s and fails against webernetes. Then I use that feedback loop to get an LLM to help me understand and fix the problem. At time of writing, webernetes has 204 integration tests. They sit alongside 1,855 unit tests, most of which are direct ports from the Kubernetes Go codebase. I think so, yes. When I got PRs from human beings, back in the good old days, what I expected to find were good tests and good code. I have the same expectation of LLMs. The difference in 2026 is that, while I generally trusted my human colleagues to do good work, I feel quite safe assuming that an LLM won’t. You need to review its output, and you need to insist on tests. It’s not enough to do one or the other, either. Without reviewing at least the test code, how do you know what success criteria the LLM is working to? And if you review all of the code but have no tests, do you really trust your squishy human brain to reason through every possibility? I don’t. I don’t even trust myself to do this with my own hand-written code. Because they don’t get tired and they type really fast, I think LLMs complement our human weaknesses really well. It’s fun to ask the LLM to come up with edge cases you haven’t thought of, then write tests for them if they make sense. You can do this dozens of times if you want, until the suggestions are nonsense. The LLM won’t mind! Combining my unique strengths of taste and understanding with the LLM’s ability to write fast, without fatigue or wrist pain, has been the biggest step change in what feels possible since I started my career in 2012. Given the retrospective nature of this post, I thought it’d be fun to make some graphs showing how the project evolved. The first one shows lines of code over time. webernetes lines of code by week Chart showing weekly Git additions, deletions, and cumulative net lines for Webernetes from April 20 through June 15, 2026. Use left and right arrow keys while focused on the chart to review each week's values. | Week | Added lines | Deleted lines | Net lines | Total lines | |---|---|---|---|---| | Week of Apr 20 | 17,074 | 5,434 | 11,640 | 11,640 | | Week of Apr 27 | 14,759 | 5,739 | 9,020 | 20,660 | | Week of May 4 | 5,732 | 1,344 | 4,388 | 25,048 | | Week of May 11 | 9,520 | 4,151 | 5,369 | 30,417 | | Week of May 18 | 14,675 | 2,791 | 11,884 | 42,301 | | Week of May 25 | 12,927 | 1,073 | 11,854 | 54,155 | | Week of Jun 1 | 31,372 | 5,823 | 25,549 | 79,704 | | Week of Jun 8 | 25,165 | 6,337 | 18,828 | 98,532 | | Week of Jun 15 | 29,967 | 1,857 | 28,110 | 126,642 | This graph doesn’t quite capture the full reality. Early work was done in a branch of the repo behind this blog site, because it wasn’t obvious to me at the time that it would become its own project. The first commit to what would become the https://github.com/ngrok/webernetes repo was on April 21st. The graph also says ~126k lines, not the ~100k that I claimed at the start of the post. This is because the 100k number excludes non-TypeScript, comments, and the demo app. LLM token consumption over time Chart showing weekly combined uncached input, cached input, and output token usage across Codex and Claude sessions for Webernetes from April 20 through June 15, 2026. Use left and right arrow keys while focused on the chart to review each week's values. | Week | Uncached input tokens | Cached input tokens | Output tokens | |---|---|---|---| | Week of Apr 20 | 3,874,487 | 78,082,526 | 606,678 | | Week of Apr 27 | 7,645,946 | 254,519,999 | 726,881 | | Week of May 4 | 2,885,324 | 121,050,752 | 282,128 | | Week of May 11 | 10,309,560 | 344,972,032 | 827,846 | | Week of May 18 | 15,866,022 | 637,270,656 | 1,288,182 | | Week of May 25 | 11,077,746 | 318,710,272 | 892,938 | | Week of Jun 1 | 33,380,099 | 837,972,608 | 2,834,083 | | Week of Jun 8 | 28,875,156 | 794,703,104 | 2,407,530 | | Week of Jun 15 | 104,155,857 | 2,196,467,968 | 6,420,826 | Make sure you really take in the magnitude of the two Y axes. Coding agents consume far more cached input tokens than any other type of token, especially if you’re often filling up long context windows. Yeah… about that. I was working on the demo app and thought it would be cool if it had support for Deployments. I didn’t think it would take long. I was wrong. In my panic, I threw lots of tokens at the problem. The LLM’s first attempt at porting the required components missed a huge amount of functionality, so I kicked off a team of agents to identify the chain of dependencies and port each component over with even more sub-agents. I then used yet another set of sub-agents to review everything. I’m not sure how I feel about this style of working with LLMs, but it undeniably got the job done more quickly than I would have. I still did my manual review at the end, but the token efficiency feels extremely poor. API-equivalent LLM token cost by week Chart showing weekly API-equivalent token costs across Codex and Claude sessions for Webernetes from April 20 through June 15, 2026. Use left and right arrow keys while focused on the chart to review each week's values. | Week | API-equivalent cost | |---|---| | Week of Apr 20 | $40.52 | | Week of Apr 27 | $187.26 | | Week of May 4 | $83.42 | | Week of May 11 | $248.87 | | Week of May 18 | $436.61 | | Week of May 25 | $241.53 | | Week of Jun 1 | $670.91 | | Week of Jun 8 | $613.95 | | Week of Jun 15 | $1,811.64 | My time was still the most expensive line item in the project, even at the end. If you got this far in the post, you may also enjoy watching the series I recorded with my colleague Ryan Blunden chronicling the making of webernetes as it happened. You’ll get to see all of my early misplaced optimism, as well as some insight into how I work mostly hands-free with voice control and eye tracking. Part 1 Part 2 Part 3 is coming soon! Please take webernetes for a spin! File issues! Email me at s.rose@ngrok.com when you build something cool or get stuck! I want this project to thrive and make a difference, and I can’t do that without your help.

Introducing Claude Sonnet 5 Claude Sonnet 5 is built to be the most agentic Sonnet model yet. It can make plans, use tools like browsers and terminals, and run autonomously at a level that, just a few months ago, required larger and more expensive models. For many developers, the agentic AI era began with Sonnet-class models: Claude Sonnet 3.5, 3.6, and 3.7 were the first models that showed impressive skills in coding and tool use. More recently, though, the clearest gains in agentic capabilities have been in our Opus-class models. Sonnet 5 narrows the gap: its performance is close to that of Opus 4.8, but at lower prices. It’s a substantial improvement over its predecessor, Sonnet 4.6, on important aspects of agentic performance like reasoning, tool use, coding, and knowledge work: Our safety assessments found that Sonnet 5 shows an overall lower rate of undesirable behaviors than Sonnet 4.6, and is generally safer to use in agentic contexts. Evaluations also show that it has a much lower ability to perform cybersecurity tasks than our current Opus models. From today, Claude Sonnet 5 is available across all plans: it is the default model for Free and Pro plans, and is available to Max, Team, and Enterprise users. It’s also available in Claude Code and on the Claude Platform, where it launches with introductory pricing of $2 per million input tokens and $10 per million output tokens through August 31, 2026, after which it will be priced at $3 per million input tokens and $15 per million output tokens. Developers can use claude-sonnet-5 via the Claude API. Working with Claude Sonnet 5 The charts below compare the performance of Sonnet 5 with Sonnet 4.6 and Opus 4.8 at different effort levels on the agentic search evaluation BrowseComp and the computer use evaluation OSWorld-Verified. Sonnet 5 (orange line) is a strict improvement over Sonnet 4.6 (gray line) and covers a much wider range of cost-performance options than Opus 4.8 (yellow line). It provides substantially improved cost efficiency at medium effort; its higher-effort performance can match Opus 4.8 on some tasks. Between Sonnet 5 and Opus 4.8, users can adjust the effort level to find the right balance of cost and performance. Feedback from our early access partners has been consistent: Sonnet 5 is much more agentic than its predecessors. Testers described how it finishes complex tasks where previous Sonnet models would stop short, how it checks its own output without explicitly being asked, and how it does all this agentic work at an attractive price point: Claude Sonnet 5 gives our agents a strong execution layer for multi-step software engineering work. It handles sustained coding, tool use, and debugging well across messy technical contexts, and has been especially useful for workflows where follow-through and technical grounding matter. We handed Claude Sonnet 5 a two-part job—update Salesforce account tiers, send a launch announcement to enterprise contacts—and it finished end to end. That used to stall halfway. For day-to-day automation, it’s a no-brainer. Claude Sonnet 5 gets more done with less. Same output quality, fewer steps to get there. It refuses unsafe requests cleanly and consistently, too. At Lovable, we’re putting powerful tools in the hands of millions of builders. A model that knows when to say no is just as important as one that knows how to build. We ran Claude Sonnet 5 against dozens of our most challenging real pull requests, and it carried each one through to a tested, verified result on its own — freeing our engineers to focus on the judgment, the decision, and the final sign-off. I asked Claude Sonnet 5 to investigate a bug. Unprompted, it wrote a reproducing test, implemented the fix, then stashed it to confirm the bug came back without the change. All in a single pass. With Claude Sonnet 5, agents stay on plan, follow our conventions, and ship clean multi-step changes, all at an efficient cost. Claude Sonnet 5 is at its best on brownfield code—race conditions, hidden tests, the parts nobody wants to touch. It traces a failure to its actual root cause and ships a durable fix instead of patching the symptom. Claude Sonnet 5 sits on the Pareto frontier for Eve’s plaintiff-law tasks. We see the clearest gains in legal research and analysis, at a price-to-performance ratio that made the choice to migrate easy. ClickHouse agents explore live data and produce insights on the fly, so time-to-insight matters when testing new models. Claude Sonnet 5 reasons in tighter steps and gets our users to answers noticeably faster. That speed is a difference our customers feel. At Pace, our computer-use agents run insurance workflows—submission intake, FNOL, loss runs—on the systems our operations teams already use. Claude Sonnet 5 consistently takes the right action and does it quickly, which is what real insurance work demands. Safety evaluations Our pre-deployment safety evaluations found that Sonnet 5 was overall an improvement on Sonnet 4.6. On agentic safety, the model is better at refusing malicious requests and resisting hijack attempts in prompt injection attacks. The model shows lower rates of hallucination and sycophancy than Sonnet 4.6. On our automated behavioral audit, which tests a wide range of misaligned behaviors such as cooperation with misuse and deception, Sonnet 5 scored lower (that is, safer) overall. However, it did show somewhat higher rates of misaligned behavior on this assessment compared to the more capable Opus 4.8 and Claude Mythos Preview. We did not deliberately train Sonnet 5 on cybersecurity tasks. It can perform some routine, non-harmful cyber tasks, but on evaluations testing potentially dangerous cyber skills, such as developing software exploits, it shows substantially poorer performance than models such as Opus 4.8 and Mythos 5. Scores from one evaluation, which tested models’ ability to develop exploits for vulnerabilities in the Firefox browser, are shown in the chart below. Sonnet 5 was never able to develop a full working exploit, but it does show a slightly higher rate of partial success than Sonnet 4.6. This latter change is likely due to improvements in general intelligence rather than specific training. Since Sonnet 5 is somewhat stronger than its predecessor on these tasks, we’ve launched it with cyber safeguards enabled by default. These safeguards—which detect and block dangerous cyber usage in real time—are the same as those present in Claude Opus 4.7 and 4.8 (because we judged that the overall level of cybersecurity risk from Sonnet 5 was low, the safeguards are less strict than those launched with Fable 5, which block a much wider range of cybersecurity tasks).1 Our full assessment of Sonnet 5 across many safety and capability evaluations is reported in the Claude Sonnet 5 System Card. Availability and pricing Claude Sonnet 5 is available everywhere today at an introductory price of $2 per million input tokens and $10 per million output tokens through August 31, 2026. It then moves to standard pricing at $3 per million input tokens and $15 per million output tokens.2 We’ve increased rate limits across Chat, Cowork, Claude Code, and the Claude Platform3 to accommodate the higher token usage of higher effort levels; users can select whichever level makes sense for their particular project. Changelog Edit June 30, 2026: In the original version of this post, we included a cost-performance chart for the BrowseComp evaluation that was based on data from a simpler methodology that did not reflect the standard methodology we use for agentic search evaluations. This had the result of underestimating Sonnet 5's performance on the evaluation. We have now updated the chart so that it matches the methodology that we used and discussed in the Sonnet 5 system card (which used a 10M token budget with compaction and programmatic tool calling). We have also updated the surrounding text. Footnotes 1 Sonnet 5 is part of our Cyber Verification Program, which is available today on the native Claude Platform, the Claude Platform on AWS, and Claude in Microsoft Foundry (hosted on Azure and Anthropic), and coming soon on Claude in Google Vertex. Organizations that are already enrolled in the Cyber Verification Program automatically have the same access on Sonnet 5, with no need to reapply. Overall, we recommend Claude Opus 4.8 for cybersecurity work that requires reduced guardrails. 2 Sonnet 5 is an upgrade to Sonnet 4.6, but it uses an updated tokenizer that changes how the model processes text to improve performance (this is similar to the tokenizer change we introduced with Claude Opus 4.7). The tradeoff is that the same input can map to more tokens: roughly 1.0–1.35× depending on the content type. The introductory pricing is set so that the transition to Sonnet 5 is roughly cost-neutral. 3 On April 26, 2026, we raised Sonnet and Haiku rate limits at every usage tier and simplified to three tiers (Start, Build, and Scale) on the native Claude Platform. You can view your tier and current limits in the Claude Console or read the documentation to learn more. - Humanity’s Last Exam: We updated the grader model for Humanity’s Last Exam and have updated the Sonnet 4.6 score to 34.6% (no tools) and 46.8% (with tools). This is the reason the score differs from that reported in the Sonnet 4.6 launch blog. - OSWorld-Verified: We made changes to how we run the OSWorld-Verified evaluation to more accurately reflect the model’s performance in the real world, and have updated the Sonnet 4.6 score to 78.5%. This is the reason the score differs from that reported in the Sonnet 4.6 launch blog. Related content Redeploying Fable 5 Fable 5 returns globally July 1. We're also proposing an industry-wide framework for scoring jailbreak severity, together with Amazon, Microsoft, Google, and other Glasswing partners. Read moreClaude Science, an AI workbench for scientists, is now available Claude Science is a customizable app that integrates the tools and packages researchers most often use, produces auditable artifacts, and provides flexible access to computing resources. Read more

I’ve been testing every major frontier model release since the start of the year, and when Anthropic dropped Sonnet 5, I wanted more than a vibe check. I got tired of one-off tests I couldn’t repeat or compare over time, so I built something better: the How I AI Bench, a repeatable eval harness I constructed live using Claude Code while recording this episode. I ran Sonnet 5 blind against four other frontier models (Sonnet 4.6, Opus 4.8, GPT-5.5, and Gemini 3 Pro) across PRD quality, prototype generation, agentic task completion, and agent personality. The results were not what I expected.

What you’ll learn:

1. What Anthropic claims Sonnet 5 improves over Sonnet 4.6, and where the benchmark data actually backs that up

2. How I built the How I AI Bench in under 45 minutes using Claude Code, starting from my own stored session history

3. Why I combined human vibe scoring (70%) with LLM as judge scoring (30%) instead of trusting either alone

4. How to set up a local HTML scoring page so you can rate AI outputs on gut feel and export those scores as JSON

5. Which model I recommend for PRDs, which for complex prototypes, and which for chatting with an agent daily

Brought to you by:

Runway—The creative AI platform for images, video and more

Hyperagent—Deploy fleets of agents that handle real work

In this episode, we cover:

(00:00) Sonnet 5 is out

(01:55) What Anthropic claims

(04:02) Why I’m done with one-off vibe checks

(05:05) Building the How I AI Bench live with Claude Code

(07:42) The scoring system

(10:43) Agent voice eval

(11:57) Quick recap

(13:58) Results: The How I AI index leaderboard

(21:21) What I’m improving for the next run

(22:16) Generating a Claire-weighted index

(23:53) Model-by-task recommendations

Tools referenced:

• Claude Sonnet 5: https://www.anthropic.com/news/claude-sonnet-5

• Claude Opus 4.8: https://www.anthropic.com/news/claude-opus-4-8

• GPT-5.5 (OpenAI): https://openai.com/index/introducing-gpt-5-5/

• Gemini 3 Pro (Google DeepMind): https://deepmind.google/models/gemini/pro/

• Cursor: https://www.cursor.com/

Other references:

• SWE-bench Pro (agentic coding benchmark referenced): https://www.swebench.com/

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

30th June 2026 - Link Blog What's new in Claude Sonnet 5 (via) Claude Sonnet 5 came out this morning. I always head straight for the "what's new" developer docs because they tend to have more actionable information than the official announcement post. Anthropic say of Sonnet 5 that "its performance is close to that of Opus 4.8, but at lower prices". The system card helps explain how they were able to release the model without being blocked by the US government: Sonnet 5 is significantly less capable at cyber tasks than Mythos 5: its safeguards are thus similar to those we apply to Opus 4.7 and Opus 4.8 (models that are more capable than Sonnet 5 but much less capable than Mythos 5). Of note from the "what's new" API changes: - Sampling parameters temperature ,top_p ,top_k are no longer supported. - It has a 1 million token context window and 128,000 maximum output tokens. - It features "the same set of tools and platform features as Claude Sonnet 4.6" - Adaptive thinking is on by default, unless you specify "thinking": {type: "disabled"} . - The pricing is the same as Sonnet 4.6: $3/million input, $15/million input, with an introductory discount to $2/$10 until 31st August. But... - The model has a new tokenizer, where "The same input text produces approximately 30% more tokens than on Claude Sonnet 4.6." - effectively a 30% price increase. I used my Claude Token Counter tool to try out the new tokenizer. Here are my results for several larger documents: | Document | Sonnet 4.6 | Opus 4.7 | Sonnet 5 | |---|---|---|---| | Universal Declaration of Human Rights (English) | 2,356 | 3,347 1.42x | 3,341 1.42x | | Universal Declaration of Human Rights (Spanish) | 3,572 | 4,753 1.33x | 4,747 1.33x | | Universal Declaration of Human Rights (Chinese, Mandarin Simplified) | 3,334 | 3,366 1.01x | 3,360 1.01x | | sqlite_utils/db.py (4,279 lines of Python) | 44,014 | 56,118 1.28x | 56,113 1.27x | So the new token is roughly 1.4x times more expensive for English, 1.33x for Spanish, 1.28x for Python code and effectively the same cost for Simplified Mandarin. Here's the pelican. It's nothing to write home about. Sonnet 5 thinks it looks like a goose.

If you feel like things are accelerating in AI, you are probably right. Better AI models from the leading American AI labs have been releasing more quickly than ever (though government interventions stopped access temporarily to two of the most powerful models, Claude Fable and GPT-5.6).

But it isn't just release timing. The evidence points to accelerating capability gains as well (though the frontier stays jagged, and AIs remain weak in many places). This is especially obvious when we look at the ability of AIs to do real work. There are a few good assessments that try to measure how much human work AIs can do. Two of the most famous, from METR and the UK’s official government AI Security Institute, estimate the amount of human programmer hours’ worth of effort the AI can do with a single prompt. GDPval compares human experts in many fields to AI performance using professional judges. They are all increasing at a better than exponential rate.

Another organization doing similar experiments, Epoch, recently found Opus 4.7, working on its own for 14 hours, was able to build a software package that would take 2-17 weeks of human engineering work (it cost $251 in tokens). Again, AI systems cannot pass every test, nor are they always cheap to run, but they are definitely improving at a very rapid rate. In my own experiments, I found Fable was able to work autonomously for 9 hours to execute on very complex software projects that would have taken a team well over a week to do.

So far, I have focused on the frontier models, those with the highest “intelligence.” They are made by three American companies — Anthropic, OpenAI, and Google (though it has been a while since Google has released a new model). But there is a second set of near-frontier AI models that typically lag 6-12 months behind the frontier, all of which are from China. These are open weights models, which means that anyone can use or modify them after release (as opposed to the frontier models which are proprietary). That makes them quite cheap to operate. They, too, are climbing up an exponential improvement curve, though lagging the American closed models. You can see this in my graph of AI performance in a test called AA-Briefcase, which simulates a complex multi-week consulting engagement where AI has to do many kinds of analysis. The open-weights Chinese models (other countries produce open weights models, but none are near the frontier) are on their own exponential curve, behind closed US models

But abstract graphs only get you so far, and they can hide how jagged the frontier is (and also the fact that the open weights models, while very impressive, do not always perform as well as their benchmarks would indicate). To get real insight, you need to try using AI for different use cases and rigorously assess how good they are in the areas that matter to you. As a fun example, I created a test where AIs have to build an interactive simulation of a harbor evolving over time. You can play with all the result here. I think it gives an interesting perspective on how much models can differ from each other in areas like design, stylistic approach, and even judgement. As systems do ever longer tasks, these hard-to-benchmark factors become more important.

The way we use AI is changing

As AIs can do longer and longer tasks, the way people are using AI is changing. Until recently, the dominant way to use AI was as a co-intelligence. You would ask the AI to do something, check the results, and then ask for it to do the next step of your job. By careful prompting and human attention, you could guide AIs to do complex and long-term tasks.

This approach to using AI is still common and useful, but, increasingly, it is not the way AI is being used for valuable work. Long-running, smart, and self-correcting AI systems do not need constant human intervention, and they require a different way of working (this is also the subject of my upcoming book, Co-Existence, which you might want to pre-order here). And, as opposed to chatbots, agents come with extra machinery: harnesses that give the AI access to tools and an environment to act in, and apps built for agents like Claude Code or OpenAI's Codex. As a result, the already increasing ability of AI models can be improved still further by a good harness or app.

So work is increasingly about assigning work to agents, rather than working together with chatbots. A joint study by OpenAI and academic economists shows how quickly this is happening inside their own organization. Critically, it isn’t just coders who are using agents. Legal, HR, and other non-tech functions have adopted agents at nearly the same rate. OpenAI may be a sort of canary in the coal mine for what will happen elsewhere in work.

Increasingly, work at OpenAI looks like managing AI. A quarter of OpenAI workers have at least four agents running at one time every week. And, as coding is done by AIs in specialized harnesses and apps, other roles start to become coders of a sort. And they are good at it. A separate study of Claude Code users found that software engineers had a similar success rate to other professions when actually using Claude code on coding tasks.

What actually mattered was not the profession of the user, but their expertise. The more domain experience someone had, the more successful they were in using Claude Code in that domain. And, even more interestingly, the more useful output they got from Claude from each prompt.

We are moving from a world where non-experts use chatbots to fill in gaps to one in which experts use agents to get work done. And the best way to use agents is to think of yourself as a manager.

A moment in time

Being on an exponential means each change over a fixed window is larger than the one before it. If your organization wrote an AI plan any time before the winter of 2025, it described a system that could do a couple of hours of work with a fairly high error rate. A few months later, you can get sixteen hours or more of work from a single prompt. This is why AI keeps feeling like it is making leaps, even though it is a curve on a graph, we keep experiencing a steady doubling of capability as a series of shocks. We are very bad at feeling exponentials from the inside, and we are currently inside one.

I think this also explains the turbulence around AI better than the usual stories about hype. AI is not capable of being a real cybersecurity threat until suddenly it is, causing sudden and improvised policy changes at the highest level of government. Markets discount whether AI might threaten to undermine a business model until suddenly it can, leading to massive swings in stocks. These lurches these get read as signs of an immature field that will eventually settle into something stable. I don’t think it is going to settle anytime soon. The instability is what happens when institutions that move at the speed of people (or worse, committees) try to track a capability curve that is very much not human in nature. And as long as we are on some sort of exponential, and for as long as it lasts, the gap only widens.

Subscribe now

Share

30th June 2026 We’ve received notice that the Department of Commerce has lifted export controls on Claude Fable 5 and Mythos 5. We'll begin restoring access tomorrow, and will share an update soon. — Anthropic, on Twitter 30th June 2026 We’ve received notice that the Department of Commerce has lifted export controls on Claude Fable 5 and Mythos 5. We'll begin restoring access tomorrow, and will share an update soon. — Anthropic, on Twitter