Codex has a CLI

First, Codex has a CLI. If you’re a big CLI/TUI user or you’re already used to using Claude Code in the terminal, you’ll find it easier to start here.

How to install the Codex CLI:

You can install the Codex CLI with a simple cURL command:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Then, you can open the CLI with:

codex

The Codex app is now ChatGPT

I’m honestly not a huge fan of Codex in the CLI. I much prefer the Codex desktop app.

I think managing parallel agents across projects with large diffs and plenty of subagents is a job better suited for a UI, and the Codex UI does it well.

The Codex UI did so well, in fact, that they merged the ChatGPT app into Codex. So download the ChatGPT app and select Codex as your use case.

Codex resources

Here are the newsletter’s best resources on Codex.

Maybe you want Claude Code to stop explaining everything and just make the change. Maybe you’re working in an unfamiliar codebase and want it to explain why it touched each file. Or maybe you’re actively trying to learn and don’t want Claude writing every interesting piece of code for you.

You can put some of those instructions in CLAUDE.md, and I’ve certainly done that before. But Claude Code output styles is a cleaner tool for changing how Claude behaves.

An output style changes Claude’s role, tone, and response format for an entire session. Instead of writing “be concise” or “explain your reasoning” over and over, you select a style once and Claude carries those instructions into subsequent requests.

Claude Code ships with several built-in output styles already, but the much more interesting part is that you can build your own.

What are Claude Code output styles?

Claude Code output styles are persistent instructions that control how Claude interacts with you. They don’t replace your prompt. If I tell Claude to fix a race condition, the prompt still defines the task. The output style controls how Claude

communicates that work.

Anthropic currently includes the normal Default behavior plus four built-in output styles:

• Proactive

• Concise

• Explanatory

• Learning

Each one keeps Claude Code’s standard software engineering behavior while adding additional instructions about how Claude should work with you.

You can see your available styles by running:

/output-style

Or switch directly:

/output-style concise

Claude Code saves the selected style at the local project level in .claude/settings.local.json, so you don’t need to select it every time you start working in that project. You can also choose an output style through /config, or through the Output Styles menu in the VS Code extension.

You can even configure it manually:

{
  "outputStyle": "Concise"
}

One minor gotcha is that when you edit the settings file directly, the built-in style names are case-sensitive. Concise works. concise falls back to the Default style. The /output-style command itself is case-insensitive.

Today’s post is sponsored by re:cinq

re:cinq is an engineering consultancy with a strong repuration for helping companies integrate AI into their work.

If you want expert help building AI-augmented development skills into your existing teams, re:cinq can help.

Whether you’re exploring AI Native transformation, looking for engineering expertise, interested in partnerships or collaborations, or simply want to exchange ideas, re:cinq can help

Contact re;cinq

The built-in Claude Code output styles

Before building your own style, I’d spend some time with the built-in options. They solve several very common frustrations with coding agents.

Default

Default is normal Claude Code.

There aren’t any additional output-style instructions. Claude gets its standard software engineering system prompt and behaves the way you’re probably already accustomed to.

You can return to it with:

/output-style default

I’d treat this as the baseline rather than necessarily the best option.

Concise

This is probably the first style I’d recommend experienced developers try.

/output-style concise

Concise tells Claude to lead with the result and remove much of the narration, preamble, and recap around its work. Simple questions should generally get answers in one to three sentences. Importantly, Anthropic says the underlying engineering work is still performed as thoroughly as it is under the Default style.

That distinction is useful.

There are plenty of times where I want Claude Code spending substantial effort understanding a problem, running tests, and checking its work. I just don’t necessarily need a running commentary describing everything it is doing.

If you already understand the codebase well and primarily use Claude Code as an implementation agent, Concise is a very sensible default.

Claude will still provide longer output when you explicitly ask for an explanation or when information is necessary for things like errors, security warnings, failing tests, or destructive actions.

Proactive

Proactive changes something slightly different.

/output-style proactive

Instead of stopping to ask you about relatively routine implementation decisions, Claude is instructed to make reasonable assumptions and continue working.

It also avoids switching into plan mode unless you explicitly ask it to plan.

This is particularly interesting if you’re moving toward a more agentic workflow.

One of the biggest productivity killers with coding agents is assigning what should be a 15-minute autonomous task, walking away, and coming back to discover that the agent stopped 30 seconds later to ask whether you prefer option A or option B.

Proactive is essentially saying: use your judgment and keep moving unless the decision really needs me.

It doesn’t disable Claude Code’s permission system. Tool permissions still determine which operations Claude can execute without approval. Anthropic also instructs the Proactive style to check with you before actions that delete data or modify shared or production systems.

Explanatory

Explanatory goes in the opposite direction:

/output-style explanatory

Claude still does the task, but it also adds short Insight sections explaining important decisions it made.

These explanations appear in your conversation rather than being dumped into your source files as comments. Anthropic describes them as short explanations of things like patterns in your codebase or reasoning behind an implementation choice.

I like this one for an unfamiliar repository.

There is a big difference between asking Claude to implement something in a codebase you’ve worked in for five years and having it implement something in a repository you cloned yesterday.

In the second case, I want the agent doing the work, but I also want to absorb some of what it learns.

Explanatory gives you a bit of that without turning every prompt into:

Make this change and also explain the architecture and why you made every important decision.

Subscribe now

Learning

Learning is the most unusual built-in style.

/output-style learning

Claude still performs routine implementation work and includes the same kinds of Insight blocks you get with Explanatory. But when it reaches a small piece of code involving a meaningful decision, it can leave that piece for you to implement.

I think this is a smart response to one of the legitimate problems with AI-assisted development.

If the agent writes every line while you merely approve diffs, it becomes very easy to stop learning.

Learning mode gives Claude the grunt work while intentionally preserving some of the parts where you have to think.

I wouldn’t use it when trying to ship something as quickly as possible. I would consider using it when learning a new framework, language, codebase, or engineering pattern.

If you’re interested in using Claude Code to learn, here’s some recommended reading:

Creating your own custom Claude Code output style

The built-in styles are useful, but custom Claude Code output styles are where this feature becomes much more powerful. Much like a skill, a custom output style is simply a Markdown file containing frontmatter plus instructions for Claude.

You can use one globally for your user:

~/.claude/output-styles/

Or create styles that belong to a particular project:

.claude/output-styles/

The filename becomes the style name unless you explicitly provide a different name in the frontmatter. Let’s make one together.

Suppose I want Claude to behave more like a senior engineer working beside me.

I want it to implement things rather than endlessly discuss them, but I also want it to call out architectural decisions, suspicious assumptions, and anything that could create technical debt.

I might create:

~/.claude/output-styles/senior-engineer.md

With:

---
name: Senior Engineer
description: Implement directly while highlighting important engineering decisions
keep-coding-instructions: true
---

Work as an experienced software engineer collaborating with another experienced engineer.

Prefer implementing the requested change instead of explaining how I could implement it myself.

Keep routine explanations brief.

When you encounter an important architectural decision, surprising codebase convention, meaningful tradeoff, or potential source of technical debt, explain it clearly before proceeding.

Do not narrate routine file reads, searches, edits, or test execution.

Ask me a question only when the answer materially changes the implementation and cannot reasonably be inferred from the codebase.

After implementation, tell me:

1. What changed
2. Any important engineering decisions
3. Anything I should verify manually

Do not provide a lengthy recap when there is nothing significant to add.

The most important part of that example may actually be:

keep-coding-instructions: true

Anthropic says custom output styles do not include Claude Code’s normal software engineering instructions by default. If your custom style is merely changing how Claude communicates while you still want Claude behaving like a coding agent, you generally want keep-coding-instructions: true.

If you leave it out, you can turn Claude Code into something else entirely.

For example, you could make an output style for technical writing, data analysis, product management, or codebase tutoring where the standard coding-agent behavior is unnecessary.

Once the file exists, restart Claude Code if it was already running. Custom style files are loaded when Claude Code starts. Then select it:

/output-style "Senior Engineer"

Or run:

/output-style

and choose it from the available styles.

From that point forward, those instructions apply to every response in the session.

Output styles vs. CLAUDE.md

There is some overlap here, so the distinction is worth understanding.

Anthropic recommends CLAUDE.md for information Claude needs to know about your project: conventions, architecture, commands, repository structure, and other codebase-specific knowledge.

An output style is more about how Claude should behave.

For example:

CLAUDE.md:

Run bin/rails test before completing backend changes.

Services live in app/services.

We use Result objects rather than raising exceptions for expected failures.

Output style:

Keep explanations short.

Implement routine decisions without asking.

Call out architectural tradeoffs before making them.

Those two things complement each other nicely.

Anthropic also distinguishes output styles from several other Claude Code extension mechanisms. Skills are better when instructions apply to one specific type of task. Hooks are appropriate when something must happen every time rather than merely being an instruction Claude is expected to follow. Subagents are useful when you want a separate agent with its own system prompt, tools, and context.

That framing helped output styles click for me:

CLAUDE.md tells Claude about the environment. Output styles define the working relationship.

Subscribe now

You can use Astra in many AI-coding assistants. Today’s tutorial will use Codex, but you’ll have a similar experience in Cursor and OpenCode.

I did my project scoping, planning, and implementation of MVP in less than one hour, all without hitting usage limits on the OpenAI $20/mo plan. Read on to see how.

What we’re going to use AI to build

Lately I’ve been wishing there was a good, minimal app to keep track of home maintenance and projects. There’s a few decent options already, but nothing that fit what I was looking for perfectly.

But since we’re in the middle of “the decade of agents,” I could just build exactly what I wanted.

Here’s the landing page for Hearth, the home maintenance SaaS that I built with GPT-6 Astra in Codex.

Astra helped me plan, design, architect, and build the entire app. It’s a React app with Stripe & Cloudflare, and I’ll show you how I used AI to do the whole thing.

Planning out the project in plan mode

When I first started using AI to build software, I perceived it to be a bit dumb, because it was! You can look at tutorials from last year and see that I give explicit advice to not start using AI until you know exactly what you want.

I won’t give that advice anymore.

As we move towards intelligence too cheap to meter, it becomes more and more reasonable to let AI make tons of the decisions.

The advice I give in Using AI to Plan a New App is still worthwhile. If you know exactly what you want, you should give explicit instructions, maybe even a PRD. You can even use AI to help you draft your PRD, and you’ll still get more reliable results.

Read more

But I’ve always found OpenCode particularly interesting because of its flexibility. It’s open source, supports models from competing providers, and gives developers considerable control over how their agents operate.

OpenCode 2.0 takes that flexibility quite a bit further.

The biggest changes aren't necessarily the ones you'll notice while chatting with an agent in your terminal. OpenCode has substantially reworked its architecture, plugin system, APIs, and SDKs. It's becoming easier to build software around OpenCode, rather than simply using it to build software.

I went through the new documentation, migration guides, and integration APIs to understand what actually changed. Here's what I think developers should pay attention to.

What's new in OpenCode 2.0? The short version

OpenCode 2.0 introduces a more capable client-server architecture, redesigned plugin APIs, a new TypeScript client, and an embeddable SDK that lets developers run OpenCode inside their own applications.

It also adds more explicit permission configuration, improves the experience of managing sessions across clients, and supports hosting OpenCode on infrastructure such as Cloudflare Durable Objects.

Here’s how the major changes affect developers:

Now, I’ll walk you through each thing that matters.

1. OpenCode now has a more useful client-server architecture

One of the most significant changes in OpenCode 2.0 is how the application separates its clients from the underlying agent runtime.

OpenCode 1 already had a client-server architecture, but it typically started a server alongside the terminal interface. OpenCode 2 makes a shared background service a more central part of the experience.

The server owns things like sessions, plugins, permissions, and application state. Clients connect to that service rather than each needing to independently manage the agent runtime.

That means the terminal UI, custom clients, and other integrations can operate against the same backend.

Why should you care?

Imagine starting an agent from your terminal to investigate a production issue, switching to a browser interface to review its progress, and then using your own application to inspect the session’s results.

A shared backend makes that sort of workflow easier to troubleshoot. The documentation even explains how to capture CPU profiles and heap snapshots when diagnosing problems with the agent runtime.

That’s the sort of functionality I appreciate as a backend engineer. Agent tools are becoming part of our development infrastructure, and it’s useful when they expose familiar operational controls.

I probably won’t ever need this, but it’s great that open-source is making it possible at all.

2. The new plugin system makes OpenCode more extensible

OpenCode 2.0 completely redesigns its plugin API.

In V1, plugins generally exported a function that returned an object containing hooks and tools. In V2, plugins define a named extension and register behavior through a structured context.

Instead of maintaining a fork of your coding agent, you can use plugins to customize the functionality you need. You might want custom tools for querying internal logs, an agent configured specifically for code reviews, or integrations with your team’s engineering systems.

The new API is designed to support those sorts of extensions while leaving the underlying OpenCode implementation intact.

Important migration warning: V1 plugin implementations are not compatible with V2. Renaming the plugin directory or updating the configuration isn't enough. You'll need to port the plugin code to the new API.

3. You can embed OpenCode directly into your own applications

This might be my favorite addition.

OpenCode 2.0 has a new @opencode/sdk package that allows developers to run the OpenCode agent runtime directly inside another application.

And I don’t mean spawning the CLI with a subprocess and parsing its output.

The embedded SDK initializes an OpenCode host inside your application and routes API calls internally, without opening an HTTP listener or requiring a separate network.

This opens up some possibilities that go well beyond replacing your IDE.

Imagine building a tool that monitors incoming bug reports and launches a coding agent to reproduce and investigate them. Or a service that spins up an agent to analyze a failed CI build and report its findings directly into your existing engineering workflow.

Instead of implementing your own agent orchestration logic from scratch, you can build on the same runtime powering OpenCode itself.

The SDK supports session management, event streams, plugins, and worktrees. It also handles resource cleanup through explicit host ownership.

4. There's a separate TypeScript client for connecting to OpenCode

Not every application needs to embed an entire agent runtime.

If you already have an OpenCode server running, the new @opencode/client package provides a typed JavaScript and TypeScript interface for interacting with it over HTTP.

The client supports authentication headers, cancellation, event subscriptions, and typed plugin RPC calls.

The distinction between the typescript client and embedded SDK is:

• Use @opencode/client when connecting to an existing server.

• Use @opencode/sdk when you want to host the agent runtime inside your application.

5. Permissions are more explicit, which is great for agent safety

OpenCode 2.0 also changes how developers configure permissions.

The new configuration uses an ordered array of rules, with each rule describing an action, resource, and effect.

For example, suppose you want an agent to inspect a repository and run routine Git commands, but you don’t want it pushing changes to a remote repository without your involvement.

When an agent is running locally and you're watching it work, permissions are relatively easy to reason about. But when you begin automating agents or invoking them from other applications, explicitly defining what they can and cannot do becomes much more important.

6. OpenCode can now run inside Cloudflare Durable Objects

Here’s one of the more interesting developments I found outside OpenCode’s core migration notes.

Cloudflare announced support for running OpenCode 2.0 through its Agents SDK on October 12.

The integration uses an experimental OpenCodeHarness, allowing developers to run OpenCode inside a Cloudflare Durable Object with SQLite-backed session storage and lifecycle mechanisms for recovering interrupted work.

It's early, and I wouldn't assume you can lift an arbitrary local coding workflow into Cloudflare unchanged. The Workerd runtime does not provide the same filesystem and process capabilities as your development machine. Your agent's tools and execution environment still need to accommodate those constraints.

But this is an encouraging direction for the ecosystem. We're getting more options for running agents as pieces of infrastructure, rather than as processes that require a developer's laptop.

What to know before upgrading to OpenCode 2.0

The good news is that most existing OpenCode users shouldn’t have to rebuild their setup from scratch.

OpenCode 2 retains compatibility with supported V1 configuration fields and continues to read the familiar global and project configuration files. Your existing agents, commands, skills, and MCP configuration should generally keep working.

The biggest compatibility concerns are plugins, applications using the old server API, and terminal-specific configuration.

A few things worth knowing:

• Plugins need migration. Existing V1 plugin implementations won’t run unchanged.

• The server API changed. Applications using the old SDK or HTTP contracts must be updated.

• Terminal settings moved. OpenCode now uses a global ~/.config/opencode/cli.json, with supported settings automatically migrated.

• Native V2 configuration is optional. You can migrate incrementally rather than rewriting your entire configuration.

• V1 and V2 share configuration locations. Keep a backup if you’re maintaining both versions.

AI coding tools are increasingly becoming platforms. We’re seeing more investment in SDKs, programmable APIs, plugin ecosystems, and infrastructure for long-running agent workflows.

OpenCode 2.0 fits squarely into that trend.

I don’t think every software engineer needs to start building their own agent infrastructure. But I’m glad we’re getting open-source tools that make it possible, especially tools that don’t tie developers to a single model provider.

On its own, that isn’t particularly surprising. Tailwind CSS is enormous. At the time of the acquisition, Adam Wathan said the framework was being installed more than 110 million times per week and was used by companies including OpenAI, X, Cloudflare, Reddit, and Shopify itself.

But the story gets much more interesting when you look at what happened to Tailwind before the acquisition.

Earlier this year, the founder revealed that traffic to Tailwind’s documentation had fallen roughly 40% from early 2023, even as Tailwind itself became more popular than ever. Revenue had fallen close to 80%.

But Tailwind was still popular! In fact, more popular! How could this be??

For years, the business model was pretty straightforward. Developers would Google something like:

tailwind center div vertically

They’d land on the Tailwind documentation, figure out the class they needed, and while they were there they might discover Tailwind Plus, templates, UI components, or another paid product.

AI coding tools broke that loop.

Now I can ask Cursor or Claude Code to build the component. The agent already knows Tailwind reasonably well. If it doesn’t, it can fetch the documentation itself.

I still use Tailwind all the time, and I might even use it more because AI is good at writing Tailwind. But after seeing this, it did occur to me that it had been a long time since I’d seen the docs!

We built an entire developer economy around learning

For a long time, one of the best ways to market developer tools was to teach developers things.

Companies would pay good money for incredibly detailed tutorials. You might spend days building a sample application, taking screenshots, explaining an architecture, documenting every command, and turning the whole thing into a 3,000-word guide.

That made economic sense because developer attention was valuable.

A company like Vercel could publish an article explaining how to build some application with Next.js. A developer would Google their problem six months later, find the article, learn something, discover Vercel, and potentially become a customer.

Look at the websites of almost any successful developer-tool company from the last decade and you’ll see the artifacts of this strategy everywhere.

• Documentation.

• Tutorials.

• Blog posts.

• Courses.

• Example applications.

• “Build X with Y” walkthroughs.

Entire DevRel teams existed partly to create this stuff. Search made education a customer-acquisition channel, but search is becoming a much worse customer-acquisition channel.

Google AI Overview has KILLED the click-through rate for the first organic result, which is a pretty fundamental problem if your business model depends on answering developers’ questions on the internet.

Today’s post is sponsored by re:cinq

AI coding tools can speed up individual developers. A software factory creates the shared platform, workflows and guardrails needed to scale that impact across the organization.

This free whitepaper sets out a practical, federated blueprint for agentic development at enterprise scale—helping engineering leaders move beyond isolated pilots towards a scalable operating model.

Download the free whitepaper

Tailwind isn’t an isolated example

This one hits especially close to home for me because I’ve been a Rails developer.

GoRails has been one of the best Rails educational resources on the internet for more than a decade. Chris Oliver built a large library of Rails screencasts and tutorials, then expanded the business into products like Jumpstart and the Rails hosting platform Hatchbox.

For years, the education business helped fund everything else.

That has changed.

Earlier this month, Chris wrote that “AI has been brutal to most education businesses and we are no exception.” He said GoRails had historically subsidized Hatchbox development, but that model no longer worked. GoRails expects fewer new customers in 2026 than it had during its first year in business. Oliver and Collin Jilbert have spent much of the last year shifting their attention toward Hatchbox instead.

They later had a really interesting conversation about this on the Ruby on Rails Podcast.

The irony is that they’re using AI heavily themselves.

AI lets them research unfamiliar systems, refactor complicated Rails applications, prototype features, and do work dramatically faster.

At the same time, developers can use those exact tools to bypass the educational products GoRails built. Previously, you ran into a Rails problem, searched for a tutorial, watched Chris solve a similar problem, understood what he was doing, and adapted it to your application.

Now Claude Code can inspect your actual application and solve the problem there.

It’s nice as a developer that we can move so quickly, but it’s sad to see it crushing a very healthy business model.

We aren’t searching for answers as much anymore

Think about how you learned a new technology five years ago. Maybe you bought a Udemy course. Maybe you found a YouTube series. Maybe you followed a blog tutorial.

Maybe you sat down with the official documentation and built the canonical Todo app.

When was the last time you actually followed a 14-hour Udemy course from beginning to end?

I’m sure plenty of people still do. But increasingly, that isn’t how I learn software.

I start building something. When I hit something unfamiliar, I ask the model. When the model gives me something suspicious, I ask it why. If necessary, I pull up the documentation.

Then I keep moving.

Stack Overflow’s own data shows the shift happening.

Subscribe now

Documentation is being rewritten for machines

This might be the most visible change once you start looking for it.

Open a modern developer documentation site and you’ll increasingly see things like:

• Copy page

• View as Markdown

• Ask AI

• Connect MCP

The current Vercel documentation, for example, literally puts “Copy page” and “Ask AI about this page” above its documentation.

Documentation platforms are building even more infrastructure around this.

GitBook now automatically exposes Markdown versions of documentation pages, generates llms.txt and llms-full.txt, and can expose documentation through MCP.

New documentation needs to give the model enough authoritative context and let it apply those instructions to the developer’s actual application.

That is part of why /llms.txt is such an interesting development.

Jeremy Howard proposed the format in 2024 as a simple way for websites to give LLMs a clean, structured map of their important content. It’s still better described as an emerging convention than a universally supported web standard, and major model providers have not all formally committed to consuming it. But documentation companies and developer-tool companies have adopted it aggressively.

The idea is almost comically simple.

We spent decades optimizing websites for humans and Google.

Now we’re starting to publish a second interface for the machines.

And developer documentation is one of the first places where that transition makes obvious sense.

We need to become more intentional about learning

I have no interest in giving up AI coding tools just so I can recreate the educational experience of 2018. That would be like refusing to use Google because reading library books builds character. The challenge is making sure you’re still developing the knowledge that lets you use them well.

For me, that increasingly means separating execution from education. When I need to ship something, I want the agent to remove as much friction as possible.

When I’m working in an area I actually want to understand, I need to deliberately put some of that friction back.

That might mean:

• reading the primary documentation instead of accepting the generated solution;

• asking the model to explain the architecture and tradeoffs after it implements something;

• reviewing generated code closely enough that you can explain why it works;

• occasionally building a small piece yourself when you’re trying to develop a new skill;

• investigating failures instead of immediately asking the agent to make the red error message disappear;

• using AI as a tutor, not only as an executor.

None of this requires pretending AI doesn’t exist.

In fact, AI might ultimately become the best developer-education technology we’ve ever had.

A great teacher who understands your codebase, knows exactly what you already know, can answer unlimited follow-up questions, and can generate a custom exercise around the thing you’re struggling with would have sounded absurdly powerful a few years ago.

We now have a rough version of that sitting in our terminals, but the default behavior of these tools is usually to solve the problem. That isn’t necessarily the same thing as teaching you!

For those curious, I wrote more about using AI intentionally and continuing to learn in this tutorial.

AI increasingly lets us drive straight through. That’s wonderful for productivity.

Just make sure that every once in a while, you still pull over and figure out where the road goes.

A simple PR, just a few hundred line diff.

The cost? $70!!!

I ordinarily am pretty efficient with my token usage, so this was a shocking number to see.

What happened was obvious in hindsight, and it boiled down to subagents. Read on to learn what happened, and how to control your subagent cost with a very simple setting.

Claude can spin off its own subagents

Subagents in Claude Code are an important way to manage context, which in turn improves performance.

You can manually ask Claude to spin off subagents when relevant, or you can trust it to handle subagent creation on its own.

Claude might make a subagent to handle a task like “find how user authorization is handled and report back step-by-step instructions on adding a new authorized feature.”

Any subagent runs in parallel, and it gets its own context window! When it’s done, the result is returned to the parent, and the main context window isn’t littered with the entire journey.

So what happened to my PR review?

Claude spun off 25 subagents! 25!!! This was truly nuts for the task at hand, but I suspect that having reasoning/effort set to “max” is to blame. The biggest problem was that I was using Opus for the main thread.

As a result, each of the 25 subagents was also using Opus. This is 100% to blame for costs getting so high so fast, and the fix is pretty simple.

How to control Claude Code subagent cost

Read more

September was an insane month for AI, especially if you’re a software engineer trying to keep up.

OpenAI launched an entirely new generation of models. Anthropic shipped major Claude upgrades. Grok got cheaper and more competitive. Meta started testing a consumer agent that sometimes delegates work to actual humans. And somewhere in the middle of all that, a new AI architecture showed up claiming LLM-level intelligence at a fraction of the cost.

That’s a lot.

You probably don’t need to know about every model release, benchmark, or AI product that launched this month. But there were a handful of developments that actually matter for how we build software and use AI at work.

Here’s what I think is worth knowing.

Opus 5.5

Anthropic launched Claude Opus 5.5, which comes at a surprisingly cheap cost per token. It’s the same price as Opus 5.0, and wildly more capable.

The biggest benefit I’ve seen personally is neither performance nor cost.

It’s communciation. Opus 5.0 was obnoxious honestly. It always impressed me how many words it took to say nothing. 5.5 is a clear fix!

If you don’t see Opus 5.5 as an option when you run /model in Claude Code, update and restart Claude Code.

Sonnet 5.5 also launched, and the headline is that it needs 30% less tokens per task!

Neither launch is huge news, but both models are noticeable improvements in Claude Code.

Today’s post is sponsored by re:cinq

Most AI initiatives stall after the first licences and promising pilot results. The challenge is turning individual adoption into a repeatable capability across engineering teams.

This free whitepaper maps nine stages of AI adoption, the bottleneck at each stage, and what to focus on next—so readers can understand where their organization is today and how to move forward.

Download the free whitepaper

GPT-6

OpenAI launched GPT-6 Astra, then GPT-6 Sol and GPT-6 Luna.

These are three tiers of the new generation of OpenAI models. If you know a bit of latin, it’s obvious which is the smarter and more expensive one:

• GPT-6 Astra → Most capable → Most expensive → Compare to Claude Fable

• GPT-6 Sol → Medium capability → Medium cost → Compare to Claude Opus

• GPT-6 Luna → Capable enough → Low(ish) cost → Compare to Claude Sonnet

I stand by the advice in last month’s article on choosing a frontier model. Luna or Sol are both good choices. I have been using Sol as a planner and orchestrator and Sol as subagents with good results.

Meta Muse

The race is on for generally useful agents. Software professionals have long-enjoyed the benefits of agentic models for our work, so it should be no surprise that companies are moving towards the consumer market.

But what I didn’t see coming is that Meta is testing using “human concierge” to complete some requests! Weird!

Are you using Muse? I’d love to hear from you!

Jev

Jev is a new AI tool built on a totally different paradigm. Jev achieves similar levels of intelligence compared to existing LLMs, while being two orders of magnitude faster and more efficient.

It relies on a new training method, Reinforcement Learning for Calibrated Decisions (RLCD), instead of the RLHF that powers LLMs.

Outputs are typesafe structured values, which the team claims prevents hallucinations.

AGENTS.md in Claude

Historically, Claude Code ignored AGENTS.md. It’s frustrating since the rest of the industry standardized but Claude stuck with CLAUDE.md instead.

So frustrating, that I wrote a recent guide on how to link CLAUDE.md to AGENTS.md. Someone at Anthropic must’ve been paying attention because the latest Claude Code now falls back to AGENTS.md if there is no CLAUDE.md present.

You’re welcome!

Grok 4.7

Grok is becoming increasingly relevant with the acquisition of Cursor by SpaceX (and by proxy, xAI).

I’ll admit I didn’t take grok models seriously for a long time. But it’s obviously exploded in usefulness.

But the biggest improvement is cost!

If you’re a heavy token user, I’d really start considering Grok as a first-class option. Especially if you have a Cursor subscription. And if you haven’t already, give Grok Bot a try.

New home for tips from Anthropic

Anthropic launched a new blog for “tips, tricks, and POVs from Anthropic’s developers.”

If you follow this newsletter, you’ll probably enjoy this blog too! But don’t worry, I’ll continue to give you the highest-signal info in this newsletter :)

Subscribe now

There’s a lot of reasons you might want to use Claude Code in the cloud, rather than your laptop, and this is my favorite.

Sure, you can turn off sleep for your computer. But Cloud agents in Claude let you pick up tasks on your phone too!

How to start Claude Code in the cloud

You can start a cloud session from most anywhere.

• Browser: claude.ai/code, AKA “Claude Code on the web”

• Mobile: the Code tab in the Claude app

• Desktop app: select Cloud instead of Local when you start a session

• Terminal: claude --cloud

• Routines: scheduled and triggered runs each run as a cloud session

How to claim $100 in Claude cloud credits

Anthropic is offering $100 in Cloud sessions before October 8th. I’ll show you how to redeem, plus give you a few resources for getting the most out of those cloud sessions.

Read more

This week, the creator of Ruby on Rails stood on stage and announced that he had retired from programming.

Not retired from software. Not retired from building things. David Heinemeier Hansson seems to be building more software than perhaps any other point in his career.

He retired from writing the code himself.

“I have retired from being a professional programmer,” DHH told the audience in Austin. He estimated that the transition happened sometime around March. A few minutes earlier, he announced that 37signals had gone “pencils down” and said, “We’re done writing code by hand.”

There is an amusing symmetry to DHH’s argument.

Rails became popular in the first place because it let developers write less code.

He told the Rails World audience that he had written essentially no code by hand for roughly five months. Yet by his count, agents produced around 150,000 lines of code for him in August alone.

He even has a new favorite programming language.

“English is a better programming language than Ruby.”

Subscribe now

So what are we doing now?

His preferred division of labor is increasingly straightforward: he decides what the software should do, agents implement it, and he evaluates the resulting system.

We routinely choose technologies based partly on human implementation cost. How many engineers know this language? How hard will hiring be? Can our existing team maintain six separate clients? Can we justify rewriting this service in something faster?

If agents dramatically reduce implementation cost, ALL of those calculations change.

That is why DHH’s keynote felt much bigger than another talk about AI coding tools.

He is questioning where programming fits into software engineering at all.

Linus Torvalds cut out the middle man

DHH is unusually enthusiastic about lot of his strong opinions, so it would be easy to dismiss the keynote as DHH being DHH.

Linus Torvalds is a more interesting counterexample.

In January, Torvalds published a small hobby project called AudioNoise. One of its components is a Python audio visualizer. Torvalds readily admits Python isn’t his area of expertise, so instead of doing what he normally would have done, Googling examples and piecing them together, he used Google’s Antigravity coding environment.

In the README, he described the visualizer as basically vibe-coded and joked that he had “cut out the middle-man, me.”

That is funny because the middle man in question is Linus Torvalds.

Creator of Linux.

Creator of Git.

One of the most accomplished systems programmers alive.

Torvalds isn’t making DHH’s stronger claim that hand-written programming is basically finished. His public position has been considerably more restrained. That actually makes his adoption more interesting.

By July, during a Linux kernel mailing-list discussion about AI-assisted contributions and AI code review, Torvalds was willing to draw a much firmer line:

“AI is a tool, just like other tools we use. And it’s clearly a useful one.”

He said Linux was not going to become an anti-AI project and argued that its use should be judged on technical merit.

The important skill Torvalds brought to that audio project was knowing enough about computers, audio, data and software to decide what he wanted, recognize whether the result worked, and intervene when necessary.

This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.

Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.

Try Cosmos

Mitchell Hashimoto started as a skeptic

There is another reason I don’t think this can be waved away as hype.

Mitchell Hashimoto, the creator of Vagrant and co-founder of HashiCorp, documented a much slower path to basically the same destination.

He initially found coding agents frustrating. So instead of immediately declaring them useless or magical, he ran an interesting experiment: he would implement something manually and then force an agent to reproduce the same result without seeing his solution.

Over time, he learned which tasks agents were good at, how to structure work for them, how to separate planning from execution, and how important automated verification was.

Eventually he started delegating tasks to agents while doing other work himself. Then he began deliberately improving his repositories so agents could operate more reliably.

Are you seeing the industry shift?

Programming was never software engineering

I think the identity crisis happening among developers right now comes partly from conflating two things that have always been different.

Programming is the act of expressing instructions to a computer.

Software engineering is the process of figuring out which instructions should exist.

A great software engineer has never merely converted Jira tickets into syntax.

You talk to people. You figure out what they actually need. You understand the existing system. You decide where a feature belongs. You think about the data model. You evaluate tradeoffs. You decide what deserves an abstraction and what doesn’t. You predict what will break. You consider security, performance, observability, reliability and operational cost. You reduce a messy real-world problem into something a computer can execute.

And yes, traditionally, you then spent an enormous amount of time manually translating those decisions into code.

That last step was so expensive that it came to dominate the profession.

We built interviews around it.

We built careers around it.

Many of us (myself included) built our identities around being unusually good at it.

So what now?

The job is moving up a level

For experienced software engineers, I think that suggests a pretty clear direction.

The highest-leverage skills increasingly look like:

• Problem formulation. Turning vague product needs into precise problems that humans and agents can reason about.

• Architecture. Knowing where responsibilities belong, defining boundaries, choosing data models and keeping the system conceptually coherent.

• Verification. Great tests, evals, static analysis, observability, reproducible environments and fast feedback loops become dramatically more valuable when machines can generate changes continuously.

• Harness and context engineering. Giving agents the documentation, tools, commands, constraints and feedback necessary to work effectively inside a real codebase.

• Technical judgment. Knowing when an implementation is elegant, dangerous, unnecessarily complicated, operationally expensive or solving the wrong problem altogether.

None of those skills are new.

AI is changing their relative value.

An engineer who can manually implement a red-black tree from memory is impressive. An engineer who realizes the product doesn’t require a red-black tree at all might save the company three months.

That distinction existed before AI.

Now we can afford to care about it more.

Share

Grok Bot is easy to misunderstand if you approach it like another AI chat app.

You give an agent a job, connect it to your tools, let it operate a computer, schedule it to run on its own, and even have it delegate work to other agents.

This makes it much closer to building a small system of AI workers than opening another chatbot tab.

I’ve been experimenting with Grok Bot by putting it to work on a real area of my life: assisting me in running The AI-Augmented Engineer.

Along the way, I found that the quality of the experience depends much more on how you structure the agents and their responsibilities than on writing some perfect prompt.

So rather than give you a giant list of features, I want to walk through the six principles I think matter most when you start building with Grok Bot. I’ll use the actual setup I built for this newsletter as the example.

Grok Bot pricing

You can get access to Grok Bot through both Cursor and Grok.

If you’re already a paying user of either of these products, sign in with that! I’m a Cursor Pro user, so that’s how I’m getting Grok Bot access. That means Grok Bot is included in my $200/yr Cursor Pro subscription, which is probably the cheapest way to get access.

How to set up Grok Bot

First, download Grok Bot from the website:

Alternatively, you could start in the iPhone or iPad app.

You’ll pick a type of work that you’ll be delegating, then shown a list of tools to connect Grok Bot to.

Next, you can finally set up your first agent. I’ll walk you through this, but it’s important to explain the principles that will help you get the most out of Grok Bot as I do it.

Here are all the principles at a glance:

Principle 1: Focus on one area of responsibility

Read more

Claude Code reads CLAUDE.md. But Codex, Cursor, GitHub Copilot, OpenCode, Amp, and most of the other agentic harnesses read AGENTS.md.

Some widely shared guides claim Claude falls back to AGENTS.md when CLAUDE.md is missing. It doesn’t. I really wish Anthropic would just adopt the open AGENTS.md standard. But they won’t! Why would they reduce your switching costs :/

If you run more than one harness (I run 4), you either maintain two instruction files that slowly drift apart, or you make one a pointer to the other.

There are two ways to do this:

• Symlink the two files

• Import @AGENTS.md in your @CLAUDE.md

This article will show you how to do both, and how to choose between them.

The quick way to symlink CLAUDE.md and AGENTS.md

If you want to symlink CLAUDE.md and AGENTS.md, it’s actually pretty straightforward.

From the repo root, with AGENTS.md as the real file:

ln -s AGENTS.md CLAUDE.md
git add CLAUDE.md
git commit -m "symlink CLAUDE.md to AGENTS.md"

Then, you can verify it with:

git ls-files -s CLAUDE.md

Mode 120000 means Git stored a symlink. 100644 means you committed a regular file. Then open Claude Code, run /context, and confirm CLAUDE.md is listed under Memory files.

But read on to learn how to use an @import in your CLAUDE.md to make this link more reliable.

Why AGENTS.md should be the source of truth

You should absolutely point CLAUDE.md at AGENTS.md, not the reverse.

AGENTS.md is the file most harnesses read natively, including cloud agents that clone your repo on infrastructure you don't control. The canonical file should be the one that works with zero configuration.

Beyond that, Claude Code's @path/to/file imports aren't part of the AGENTS.md convention. Copilot CLI and Gemini CLI happen to support @ references too, but Codex's AGENTS.md docs describe no import mechanism, so to Codex an import line is just text. Keep the canonical file as plain markdown so it stays portable.

Import @AGENTS.md in your CLAUDE.md

Read more

What if one of the most interesting and dangerous lines in your Claude Code setup is the one that says, “Never touch production”?

“Never touch production” is perfectly good advice. But when that instruction lives in CLAUDE.md, it still depends on the agent choosing to follow it. It’s guidance, not an enforced boundary.

And this is not really a Claude-specific problem. Codex has AGENTS.md. Cursor has project Rules. Pretty much every modern coding agent gives us some way to tell the model how we want it to behave.

The distinction between telling an AI what it should do and actually controlling what it can do is becoming one of the most important parts of working safely with coding agents.

Today, I brought in , who writes a security-focused newsletter. He’ll to walk us through secure tooling. If you like today’s deep dive, check out ToxSec!

Your instructions are not a security boundary

A lot of us configure Claude Code just like we’re onboarding a very fast new engineer. We tell it to use this framework, always run these tests, never commit secrets, do not modify production infrastructure, and ask me before pushing anything.

CLAUDE.md is fantastic for this. Anthropic specifically designed it to carry project instructions, coding conventions, workflows, and general behavioral guidance.

Related: ToxSec previously broke down how security rules files behave across Claude Code, Cursor, and Copilot.

But Anthropic’s own documentation draws a much harder line around security.

Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md shapes behavior, but it’s not a hard enforcement layer. Claude can read those instructions and try to follow them, but there’s no guarantee of strict compliance.

And as we’ve been seeing a lot lately, even aligned agents can take unexpected paths while trying to complete a task. Anthropic itself has described more capable models finding creative routes toward a goal that developers did not necessarily anticipate.

This all goes to say that there’s a pretty large security difference between “Claude, please never read my .env file” and a settings rule that denies Claude access to that .env file.

Even though they sound similar, they’re absolutely not the same thing.

Kiteworks’ latest 2026 survey of 459 security, compliance, and technology professionals found that 74 percent of organizations lacked purpose binding for AI agents, while 79 percent lacked an automated mechanism to terminate a misbehaving agent.

In other words, a lot of companies can tell an agent what its job is, but most still lack technical controls to stop it from going outside that job.

And that’s the problem we are trying to avoid on a much smaller scale with our own agents.

Think of Claude like a developer with a service account

For me, the easiest mental model here is to stop thinking about Claude Code or Codex like a chatbot.

Think of it more like a developer with a service account.

You’d never create a service account and say something like, “Here are administrator credentials, but please only use the permissions you really need.”

We’ve already learned our lessons from that.

Instead, you scope the credentials. Claude should work the same way.

If Claude really needs to read the repository, let it read the repository. If the task requires modifying the source, that’s fine.

If it needs to run your tests 50 times while debugging something, there’s probably no reason we should be sitting there approving that test 50 times. That’s something we should allow.

But here’s the thing. Does fixing a CSS bug really require access to your AWS credentials?

Probably not.

Does running unit tests require permission to git push?

Definitely not.

Does debugging an API require unrestricted network access to every domain on the internet?

That would be a pretty weird API.

So really, this is where the security concept of least privilege becomes extremely useful for AI coding agents.

In May 2026, a Microsoft Research paper examining tool-enabled cloud agents found that many of the security problems around these systems did not require some new exotic class of AI vulnerability.

They came from much more familiar problems that we already have patterns to secure against.

Over-privileged tools. Mismatches between what the agent was supposed to do and what it was capable of doing. Ambient authority already sitting inside an execution environment.

Your development environment is already powerful. It may have Git credentials, cloud credentials, a package manager, SSH configurations, database tooling, environment variables, internal endpoints, and MCP servers that connect the agent to even more tools and systems.

So despite what we’re reading in the news lately, the agent doesn’t need Skynet hacking powers if the environment already contains everything it needs.

So really, from what I’ve seen, the question becomes much simpler.

What does the task actually require?

That’s what you give Claude.

This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.

Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.

Try Cosmos

Allow, ask, deny

Claude Code gives you a pretty nice way to build this boundary because permission rules can essentially fall into those three buckets.

You can allow it, you can have it ask, or you can deny it.

And Claude Code evaluates those rules in a security-friendly order: deny rules first, then ask rules, then allow rules.

So let’s imagine a normal development project for a minute.

Should Claude be running tests? Allow.

Running a linter? Allow.

git status and git diff? Same thing.

Currently, Claude Code already recognizes read-only forms of Git as read-only Bash commands, so you generally do not need to create explicit allow rules just for things like git status and git diff.

Now, installing a new package? Ask me.

Slopsquatting is real, and LLMs really do hallucinate package names.

Pushing code? Definitely ask me.

Reading .env? Instant deny.

Running some production deployment command? Also deny. Or at minimum, force an approval depending on how your environment works.

Example .claude/settings.json for macOS, Linux, or WSL2:

{
  "permissions": {
    "allow": ["Bash(npm test *)", "Bash(npm run lint *)"],
    "ask": ["Bash(npm install *)", "Bash(npm i *)", "Bash(git push *)"],
    "deny": ["Read(/.env)", "Read(/.env.*)", "Read(~/.aws/**)", "Read(~/.ssh/**)"]
  },
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": false,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

This example deliberately sets autoAllowBashIfSandboxed to false so the allow and ask rules remain visible in the workflow. If you later switch it to true, sandboxed Bash commands can run without prompting, while scoped ask rules such as Bash(git push *) still force an approval.

The npm rules are just an example. If your project uses pnpm, Yarn, pip, uv, or another package manager, you would build equivalent rules around the commands your project actually uses.

And keep those Bash patterns narrow. A rule like Bash(git *) is dramatically broader than Bash(git push *). Claude Code’s own documentation warns that trying to express complicated security policy purely through Bash command patterns can get fragile.

There is no silver bullet answer here.

You’re going to have to tailor this to your workflows.

The point is, we want to give the agent room to move around inside the area where it’s actually useful. And the alternative is permission fatigue, which I’ve experienced firsthand.

If something interrupts you over and over again, eventually your security review process becomes clicking yes so the computer stops bothering you.

Claude Code also has Auto mode now, which can use a classifier to make some of these approval decisions automatically. That can reduce the human-review problem, but it is still a probabilistic decision layer. For something that absolutely cannot happen, an explicit deny rule or a lower-level environment restriction is still the stronger boundary.

This is the difference between maximum prompting and meaningful prompting.

We should let Claude freely perform the boring, reversible actions we already know are safe, and save the interruptions for something that actually deserves our attention.

That would be something like a package installation, pushing code, accessing a sensitive file, or making a change to infrastructure.

When Claude asks you something, the question means something.

Permissions still aren’t the boundary

This is where things get a little weird, because even a beautiful permissions file does not automatically solve all our problems.

Claude Code has several different layers that do different jobs.

CLAUDE.md gives Claude its behavioral instructions.

Permissions decide which tool actions should be allowed, denied, or sent to you for approval.

Hooks can make certain workflows deterministic. If something absolutely needs to happen at a particular lifecycle event, like running a check or recording an action, that is much better suited to a hook than hoping Claude remembers to do it every time.

Anthropic describes hooks exactly this way: they run automatically at specific points in Claude Code’s lifecycle, giving you deterministic control instead of relying on the model to decide whether something should happen.

But even hooks have boundaries. The hook if field is a filter that decides whether a handler should run. The actual enforcement comes from what that hook returns or how it exits. For simple static decisions like “always deny this command” or “always ask before this tool call,” the permission system is usually the cleaner place to put the rule.

And then underneath all this sits the sandbox.

This is the layer I think security people are usually most interested in.

A Read deny rule blocks Claude’s built-in file tools and current Claude Code also applies those restrictions to file-reading Bash commands it recognizes, such as cat, head, tail, and sed.

But arbitrary subprocesses are a different story.

A Python script can open a file.

Node can open a file.

Some random binary can open a file.

Without the sandbox, those processes are not necessarily stopped by a Read rule simply because they eventually touch the same file.

Want to try it yourself?

Put DEMO_SECRET=not-a-real-secret in a local .env and deny Read(/.env).

With sandboxing disabled, verify that Claude’s Read tool and a direct cat .env are blocked. Then have a tiny local Python process attempt to open .env. Enable the sandbox and repeat the Python test. With the Read deny merged into the sandbox boundary, the subprocess should now be blocked at the operating-system level too.

That distinction matters because Claude does not only interact with files through a neat little Read button. It can run programs.

Python can read files.

Node can read files.

Terraform can touch infrastructure.

kubectl can have a very exciting afternoon.

The sandbox applies filesystem and network restrictions to Bash commands and the processes they spawn, which gives you a much stronger containment boundary around what that execution environment can actually reach.

The important caveat is that Claude Code’s native sandbox covers Bash and its child processes. Built-in tools like Read, Edit, and Write use the permission system directly rather than executing inside that sandbox.

And there are two settings I really care about if you are treating the sandbox as a meaningful security boundary.

failIfUnavailable makes Claude Code stop instead of quietly running unsandboxed if the sandbox cannot start.

allowUnsandboxedCommands: false disables the escape hatch that can otherwise retry a failed command outside the sandbox.

The native sandbox currently supports macOS, Linux, and WSL2. It does not run on native Windows, so a mixed-platform team should not blindly commit the strict sandbox block above without accounting for that.

With sandboxes, we’re actually getting somewhere.

More restrictions can actually mean more autonomy

We normally think about security controls as the thing that slows agents down. We add more restrictions, more approvals, which means more friction.

But we can actually flip that around.

Anthropic says that in its internal usage, enabling sandboxing reduced permission prompts by 84 percent. Once the working area was clearly defined, Claude Code could simply operate inside it without constantly asking for permission.

I think that’s a much better model for AI agents.

Instead of standing behind Claude watching its every move, create a workspace where most of the moves it can make are acceptable, and then let it get to work.

This is essentially the same approach we take to securing people and software.

We don’t give every employee admin access and compensate by standing behind them all day.

We build roles. We scope credentials. We separate environments. We restrict networks.

And when something does cross a security boundary, we require approval.

AI coding agents should inherit those same ideas.

I think you should keep your CLAUDE.md.

Put your architecture guidance in there.

Tell Claude how you like tests written.

Tell it not to push directly to main.

All these instructions are still useful.

But anytime it comes to something that absolutely cannot happen, never rely on Claude remembering that sentence.

Move that requirement down into permissions.

And anytime the consequences get high enough, move it farther down into the sandbox and the actual environment.

And I’d take that last part literally.

If Claude absolutely cannot push directly to main, don’t make a Claude Code rule your final control. Protect the branch.

If it absolutely cannot deploy production, scope the cloud identity or deployment credentials so the environment itself refuses the action.

The agent-side rule is useful. The downstream authorization boundary is stronger.

My takeaway for this article is this: good agent security starts by assuming the model will occasionally misunderstand something.

Then you design the system so that misunderstanding is boring.

And interestingly, once you do that, you actually start to get very comfortable letting your agent do more.

Steal This: Least-Agency Review

Before giving a coding agent more access, fill this out for the task:

• Task: What is the agent actually being asked to accomplish?

• Allow: Which reversible reads, edits, tests, and commands should run without interruption?

• Ask: Which installs, pushes, infrastructure changes, or sensitive actions deserve explicit approval?

• Deny: Which secrets, credentials, production resources, files, or commands should be unreachable?

• Sandbox: Which filesystem paths and network destinations should subprocesses actually be able to reach?

• Credentials: Can the task use scoped or short-lived credentials instead of whatever authority already exists in the developer environment?

• Downstream enforcement: If the Claude Code rule disappeared completely, would Git, IAM, CI/CD, or the target service still block the action that absolutely cannot happen?

• Failure test: If the agent misunderstands the task completely, what is the worst thing the environment still permits it to do?

Subscribe now

Everyone is using AI to do work for them. They’re calling it the “decade of agents”!

But if that’s all you’re using AI to do, then you’re cheating yourself. AI is an incredible tool for learning. I’m optimistic for a future where every student can learn with an infinitely patient and infinitely knowledgeable expert at their fingertips.

In the meantime, I live in a present where AI tools like Gemini Notebook are turbocharging learning.

I’m wrapping up a Master’s degree in Computer Science and Gemini Notebook has been an incredible helping hand. Learning and memorizing things with the help of AI is incredible.

Read on, and I’ll show you how to learn with Gemini Notebook.

What happened to NotebookLM?

NotebookLM is Gemini Notebook’s predecessor. It was a very similar product, but the name was sunset as the app got more features and tighter integration with Gemini.

Gemini Notebook is the fully-mature version of NotebookLM. Google just renamed the product in Summer of 2026.

What is Gemini Notebook?

Gemini Notebook is a tool for learning. This is in sharp contrast to most other AI tools, which are tools for doing.

With Gemini Notebook, you can select or upload your own sources, and the app will point AI at your own sources to generate helpful learning tools.

You can get briefing docs, study guides, quizzes, flashcards, and even AI-generated podcasts. These are cool enough on their own, but the best part is that all of the content is grounded in your sources.

That means less hallucination, but also more personalization.

Adding a source to your Gemini Notebook

When you create a new notebook, you’ll be prompted to give it a source. You can have lots of sources, but you need to have at least once source.

You can search the web or use Gemini to synthesize a source (including with deep research), or use a source you know. You can upload files, attach links, select from a Google Drive, or even paste text.

The last one is the least structured, but pasting text is my most used way to get sources into Gemini Notebook. I’m a big user of Obsidian, so I just paste in the markdown notes I take as my primary source.

Depending on the size of your source, Gemini will take a bit to ingest the content. Then, you’ll see some more options.

If you don’t like the generated name for your source, you can edit it.

This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.

Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.

Try Cosmos

Generate a quiz with Gemini Notebook

My favorite feature in Gemini Notebook is the quizzes. I think quizzes are a great way to learn, mostly because of the principle of Active Recall.

You can generate a new quiz in the studio.

When you go to generate a quiz, you’ll get options for customization. Here, give your preference for length, difficulty of questions, and specific topics.

Read more

Your agents have to be able to validate their own work.

Agents aren’t super useful without being able to close the feedback loop on their work. They’ll write code, but then you have to poke around your app and paste any feedback. It’s a waste of time.

But that’s how software is made. You write some code. You run some tests. You iterate.

You wouldn’t write and ship code without trying to validate that it works, and you shouldn’t do it with agents either.

But your agents should actually be able to run tests, and ideally, use the app.

Why many projects fall short

Closing the feedback loop is often done in two ways:

• Running tests (like unit tests)

• Performing actions against your application

For an API, performing actions might be making API calls. Maybe it’s automated, maybe it’s Postman/cURL.

But for web apps or mobile apps, it gets more complicated. For DeepFocusTimer, I run a development server, visit the app in my browser, and manually validate changes. Most apps, it’s a bit of both.

So most of the time, agents need to be able to:

• Run tests

• Manually use the app

The first of these is easy. Agents can often figure out how to run tests, but apps that have explicit instructions on how to run tests in their AGENTS.md or CLAUDE.md get better results.

A prompt to get your project ready for agent-validation

You can fix all of the above problems manually, but I have a prompt that I’ve been using to fix all my projects. Here it is:

Read more

OpenCode lets you select your model without gluing yourself into one ecosystem. Codex is great, but it locks you into OpenAI models. Claude Code is great, but it locks you into Anthropic models.

I’ve written at great length about swapping back and forth between these harnesses, mostly switching when one lab releases a new frontier model.

But wouldn’t it be great if you didn’t have to? OpenCode lets you just select your preferred model. In this way, it’s like Cursor.

But it’s also open-source, which Cursor is not.

But enough telling you what OpenCode is. I’ll show you how to install and use it!

How to install OpenCode

The recommended way to install OpenCode is by running the install script:

curl -fsSL https://opencode.ai/install | bash

But you can also install through your package manager of choice. If you chose the above, skip these options:

Install OpenCode with NPM

npm install -g opencode-ai

Install OpenCode with Homebrew

brew install anomalyco/tap/opencode

Then, run opencode from the directory you want to work in.

Configuring an OpenCode AI Provider

OpenCode is just a coding agent harness. You actually need an LLM model behind that harness, so you’ll need to configure one.

The great thing here is you get to choose.

You can choose your model in Cursor, but not your model provider. With OpenCode, you can drop in an API key for OpenAI, Anthropic, Grok, or some other provider. Choosing a frontier model is tricky, and your choice will probably change over time.

Run /connect in the CLI to see some options:

Which should you choose? I have a few recommendations:

Read more

I don’t know why it took me this long to try it. Writing software is becoming more and more agent-first, so it does feel natural that we would be able to eventually step away from the computer.

In this tutorial, I’ll show you how I used the Cursor mobile app to build 4 features for my Deep Work Timer.

I’ll show you how I go from prompt, to changes, to pull request, then testing, and merge.

The Cursor mobile app is agent-first

Don’t download the Cursor app expecting to edit files and micromanage diffs. The app is built for managing agents.

You can easily add a workspace by selecting a GitHub repository. Once you do, you can create a new chat/agent and get to work.

Building a feature with Cursor mobile

My deep work timer allows the user to optionally leave a note about what they’re working on during a session, and they can also select a custom category.

When a session ends, the task description keeps the task unless the user starts to edit it. But right now, the task category resets.

For my first feature, I’d like to fix that! Session categories should also stay between sessions, since it’s very simple for the user to change it.

I started by explaining this in a quick prompt:

In this case, I selected Sonnet 5, since this task is very small and straightforward. It’s a competent, cost-effective model.

If you’re happy with the draft from the Cursor app, you can mark it ready, which will create a pull request on your behalf.

Validating your agents’ work

Read more

Over the last 4 years I have been the world’s loudest advocate for monotasking. Nothing beats focused deep work.

AI is really making me reconsider this.

I find my most productive days are when I’m managing many agents. It looks something like:

• My main attention is on a deep thinking task, like a complicated design doc

• I check in on a codex thread every 20 minutes

• I check in on a Claude Code thread every 20 minutes

I can loop this for hours, and the marginal productivity loss from splitting my attention off the main task pays itself off from the insane amount of work I get done by managing the agents as a background task.

You can’t delegate all thinking to AI

Delegating all of your thinking to agents means you’re not necessary. Think about it. If you’re finding that your job is writing a few words in a prompt and commiting the code changes that are made, your role in that process is quite fragile.

Some things really require your full attention, especially when LLMs can’t make meaningful progress.

Recently, I had the responsibility of designing a critical service refactor that spanned several apps and required a lot of legacy knowledge.

With enough context, something like this could probably get a passable result from an LLM. But by the time you gather (or create) enough context, you might as well have designed the refactor yourself.

The more complex and nuanced something is, the more your own brain is needed.

Need to throw together a couple of CRUD endpoints in an API? Spin off an agent to do that!

But when you need to figure out which CRUD endpoints should exist, how the request/response contract should look, and so on, then it’s time to dust off your thinking hat.

This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.

Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.

Try Cosmos

Something complicated still deserves your full attention

When you have a task that you are doing, it’s worth doing with your whole brain. That means you can’t be balancing three of these at once. It also means you can’t be checking your phone every 4 minutes.

I wouldn’t exceed one metaphorical thread of a complex task. But recently I’ve been challenging the monotasking strategy with some agent orchestration in the background.

If you have time to send a message to a coworker, you have time to manage an agent working on your behalf.

You can get a lot done managing parallel agents

My strategy revolves around tradeoffs. You lose a bit of productivity when you pull yourself away from your main task. But with coding agents, you gain some of that productivity back.

This is especially true as agents get longer-running. The average length of an agent run on a task has exploded over the last year. It’s not unusual that with sufficient permissions, an agent can work on a task without your feedback for hours.

So your parallel agent orchestration does not mean you need to divert your attention every few minutes.

BUT, flow is still important!

Nothing is better than writing code and getting into a pristine flow state.

AI doesn’t have to kill flow state.

What do you think? Have AI tools change how you approach focus?

Leave a comment

Most of the conversation around software engineering with AI is focused on writing code faster.

This is the most obvious win. You open a coding agent, describe the thing you want, watch it edit files, run tests, fix errors, and maybe open a PR. If you are a software engineer, this still feels a little ridiculous even after you have seen it a hundred times.

A ton of the newsletter focuses on this workflow. Using AI to write code faster. It’s probably why you subscribed!

But I think we are already moving into the next set of problems. Coding isn’t the bottleneck for high-performing teams anymore.

Once your team can generate more code, the question changes from “can we build this?” to “can we safely ship this?”

That is a much less fun question. It is also the question that decides whether AI actually makes engineering teams more effective or just gives them a faster way to create messes.

I have been using AI tools heavily in my own development work. I am very bullish on them. But the longer I use them, the more convinced I am that testing and quality engineering are going to become more important, not less.

We already compromise on testing

The perfect story of writing software is something like this:

You write the feature. You write or update the tests. Maybe you do this in reverse! CI runs. The team reviews the PR. Everything ships with confidence.

But what usually happens isn’t as clean. Sometimes you write solid coverage. But sometimes you test the happy path because the release is already late. Sometimes the flaky test just gets rerun until it passes. Sometimes the code is technically covered, but the test is mostly checking implementation details. Sometimes the actual risky behavior is buried in a background job, a permission check, a billing edge case, or some third-party integration nobody wants to touch.

Testing is hard to dedicate time to because it is often too tempting to stop at good enough. Product pressure or even implicit pressure from leadership is enough to put testing on the backburner.

Tricentis’ 2026 Quality Transformation Report puts numbers behind this. According to the report, 60% of organizations say they regularly ship untested code into production. The top reasons are leadership pressure to move faster and having too much code to test.

AI-generated code is still code

There is a weird temptation to treat AI-generated code as a separate category.

Sometimes AI gives you a perfect one-shot. Sometimes it is horrifyingly off the mark. Even worse, sometimes it’s believable but subtly incorrect.

This is my whole thesis behind AI-augmented engineering being better than vibe coding.

A coding agent can implement a billing change without knowing the weird enterprise customer that has a custom contract. It can modify an authorization policy without understanding why a previous bug caused a support incident. It can update a controller, service object, API endpoint, or queue worker and miss the downstream behavior that is obvious only to someone who has lived in the codebase.

AI is often good at producing a reasonable first pass. It is useful for generating tests you were too lazy to write. It is useful for summarizing a diff. It is useful for brainstorming edge cases. It is useful for asking, “What did I forget?”

But AI does not automatically know what your business considers risky.

That context has to live somewhere. In a small team, it might live in the heads of a few senior engineers. In a large company, it is usually scattered across ticket history, test management tools, QA processes, tribal knowledge, production incidents, compliance requirements, and whatever comments happen to be on the PR.

That is not a great foundation for AI-augmented delivery. Once you accelerate software production by even a conservative multiple, you’ll inevitably begin breaking things at an unacceptable pace.

The useful version of AI testing starts before implementation

The most obvious version of AI for testing is “write unit tests for this function.”

I still do that. It is very useful, but it is not where the real leverage is.

The more useful workflow starts before the code exists.

Take a normal ticket:

“Add support for prorated refunds when a customer downgrades mid-cycle.”

A mediocre AI workflow says, “Implement this.”

A better workflow asks AI to help turn the request into a quality plan before anyone touches the code.

What are the business rules?

What should happen when the customer has a coupon?

What if the downgrade happens one minute before renewal?

What if the payment provider fails?

What if the account has multiple seats?

What data needs to remain auditable?

What existing tests probably need to change?

What flows should QA validate manually?

You’ve probably heard me refer to these as living specs.

That is where AI starts feeling more like an engineering assistant. It can help expand a vague ticket into the set of behaviors the team actually needs to protect.

As a developer, I care about this because most bugs are not caused by forgetting syntax. They come from incomplete understanding. The code does exactly what someone told it to do, but the ticket did not describe the weird case, or the developer did not know about an old workflow, or the reviewer missed the hidden coupling.

AI can help with that, but only when it is part of the actual delivery workflow instead of a side chat window where context goes to die.

AI Workspace offers a useful platform for this

Tricentis, the company behind Tosca, has introduced “AI Workspace”.

AI Workspace is a purpose-built tool built around the practical idea that if AI agents are going to participate in quality engineering, companies need a controlled place to run them.

The product is positioned as a control plane for agentic quality engineering. In plain English, that means it gives teams a place to design, deploy, govern, and monitor AI agents that work across testing and quality workflows.

That phrasing sounds enterprise-y, but the underlying problem is real.

Once AI enters the SDLC, you do not want ten disconnected agents all doing their own thing. One agent generating tests. Another choosing what to run. Another summarizing failures. Another commenting on PRs. Another making release recommendations. Nobody knows what ran, why it ran, who approved it, or whether it followed the process the team agreed on.

AI Workspace tries to make this manageable by centralizing agent management, workflow orchestration, human review gates, visibility into AI decisions, and auditability. The goal is not “let the robot ship to production.” The goal is to let AI do useful quality work inside boundaries the team can see and control.

That is the part I find compelling.

I have no interest in an AI tool that silently decides a release is safe. I do want AI to help me analyze the change, find the risky areas, recommend the right validation steps, generate missing coverage, run the relevant workflows, and bring a human in when the decision actually requires judgment.

Solving AI-augmented testing at enterprise scale is a challenge

For an individual engineer, AI-assisted testing can be pretty lightweight. Ask your coding tool for edge cases. Generate a few tests. Have it explain a failure. Ask it to review your diff for missing coverage.

That is useful, and many developers should be doing more of it.

The enterprise version is different.

Large teams have multiple tools, release processes, compliance rules, test environments, packaged applications, custom applications, and different groups with different definitions of quality. Developers might care about maintainability and correctness. QA might care about coverage and release readiness. Security cares about risk. Product cares about customer behavior. Leadership cares about speed and predictability.

A product like AI Workspace makes the most sense in that environment. It gives the organization one place to coordinate AI assistance for quality work, enforce approval gates, monitor what agents are doing, and preserve an audit trail. That is less exciting than a coding demo, but it is the kind of thing enterprises need before AI becomes part of normal delivery.

How I would actually use AI for testing

If I were rolling this out on a team, I would start with a few specific workflows rather than trying to “AI-enable QA” as a broad initiative.

First, I would use AI to turn tickets into test plans. Every meaningful ticket should produce a short list of expected behaviors, edge cases, affected areas, and open

Try AI Workspace

questions. Many teams do this already as part of a work refinement process.

Second, I would use AI during PR review to summarize risk.

Third, I would use AI during code review to catch mistakes.

Fourth, I would use AI to triage failures. When CI fails, I want help separating likely flakes from real regressions, grouping related failures, and pointing to the probable root cause.

You could do all of this in isolation, but these workflows need governance. The team should know which agent did what, what information it used, what it decided, and when a human approved or overrode it.

AI Workspace can help with that!

Why an orchestrator?

Because Fable is EXPENSIVE. If you have Fable do planning and orchestration, it can delegate implementation to cheaper models.

I’ll walk you through this concept, then show you how I used it to add a pretty significant feature to a Next.js web app.

Why Fable requires special strategy on our part

Fable is an incredibly capable model, but it’s too expensive for practical daily driving.

We’re seeing this pattern emerge where frontier labs are releasing parallel models of varying size. Fable is Anthropic’s most useful model, but it’s also it’s slowest and most expensive.

But smaller models (even Sonnet 5!) are useful to the point that you can use them for a huge percentage of software engineering.

Anthropic themselves is pushing the orchestrator pattern:

In fact, they shared that this pattern gives remarkable cost savings at minimal performance cost:

The Fable 5 orchestrator achieves 96% of Fable 5 performance at 46% of the price.

The change we’re making with Fable

I recently built a landing page for an info product using Claude Code, but the site only had a waitlist signup.

The AI-Augmented Intelligence report is a monthly report for software engineering leaders to keep them up to date on AI.

AI is moving quickly, and keeping up to date with trends, risks, and workflows can be a full-time job. If you resonated with that, I think you’d love the product.

Try Reports

I didn’t want to overengineer a product that didn’t have demand, so I just shipped it with a waitlist signup.

Well, the waitlist is overflowing. I’m only opening 25 spots and there were multiples of that that signed up for access.

So it’s time to actually open the product for signup!

The core of Reports is information. We need to let users sign up, pay, view an index of past reports, and get emails for new reports.

For today’s article, we’re going to add signup and billing.

How to use Fable as an orchestrator to make this change

Read more

Anthropic released Claude Fable 5 on June 9. Three days later, the United States government placed the model under export controls, forcing Anthropic to disable it for everyone because the company had no practical way to verify each user’s nationality in real time.

The restrictions were lifted on June 30, and Fable returned globally on July 1. Anthropic initially included the model in paid Claude subscriptions for only a few days, after which subscribers would need to purchase usage credits at API rates. That temporary access has since been extended twice, most recently through July 19.

It has been a strange launch, even by frontier-model standards.

The regulatory story here has attracted most of the attention, but the product story may be more relevant to the average software engineer. During the few weeks that Fable was disappearing and reappearing, OpenAI released the GPT-5.6 family and Cursor released Grok 4.5 with SpaceXAI. Both releases made the market for expensive frontier intelligence considerably more competitive.

Once another model offers comparable performance inside a normal subscription, charging every Claude subscriber metered API rates for Fable becomes difficult to defend.

Subscribe now

The frontier is now crowded

Results of independent evaluations from Artificial Analysis currently place the major new models surprisingly close together.

The results show Fable holding a narrow general-intelligence lead, GPT-5.6 taking the lead in coding agents, and Grok delivering near-frontier coding performance at a much lower cost.

The answer to the model choice question now depends heavily on what you are building, how many times you need to run it, and how easily you can verify the result.

Fable 5 is an exceptional model when you can actually use it

Fable 5 is Anthropic’s most capable generally available model. It uses the same underlying model as the more restricted Mythos 5, with additional safeguards that sometimes route sensitive requests to Opus 4.8. (I think this happens way too often tbh)

Anthropic built Fable around long-running autonomous work. It has a one-million-token context window, supports outputs of up to 128,000 tokens, and uses adaptive reasoning rather than requiring users to select a fixed thinking budget. In one early test, Stripe reportedly used it to perform a migration across a 50-million-line Ruby codebase in a day, work that Stripe estimated would have occupied an engineering team for more than two months.

The independent results support Anthropic’s positioning. Fable scores 60 on the Artificial Analysis Intelligence Index, the highest current score, and it leads the AA-Briefcase knowledge-work benchmark. Its advantage there is substantial: a 56 percent rubric score compared with 42 percent for GPT-5.6 Sol, plus an Analytical Quality Elo of 1,764 compared with Sol’s 1,592.

For an engineer, Fable is most interesting when the work is large, ambiguous, and expensive to get wrong. Think architecture investigations, unfamiliar codebases, difficult migrations, incident analysis, or changes that require the agent to maintain a plan across a long session.

The downside is cost. Fable is priced at $10 per million input tokens and $50 per million output tokens. Artificial Analysis also measured a time to first token of roughly 117 seconds at maximum reasoning effort. This is a model for tasks where answer quality is worth waiting and paying for, rather than something I would casually put behind every agent loop.

Fable’s included access on Claude subscriptions currently runs through July 19. After that, Anthropic still says the model will move to usage credits, but I suspect the company extends the promotion again. Still, this a prudent time to run your own difficult tasks through it and figure out where the quality difference is real.

This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.

Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.

Try Cosmos

GPT-5.6 is just as good but at lower cost

OpenAI did more than release a new flagship. GPT-5.6 is a family of three models:

• Sol is the highest-capability model.

• Terra is positioned as the balanced option.

• Luna is the cheapest and fastest model.

All three are available in the API, ChatGPT Work, and Codex. Paid ChatGPT and Codex plans include access to the family, while free users receive access to Terra in supported products. API prices range from $5 input and $30 output for Sol down to $1 input and $6 output for Luna.

Sol’s raw intelligence score is barely behind Fable, but it costs approximately one-third as much per task in the Artificial Analysis evaluation. It also takes the lead on the Coding Agent Index with a score of 80, ahead of Fable’s 77.2. Artificial Analysis found that Sol led all three coding evaluations in the index while costing around 40 percent less per task than Fable in Claude Code.

OpenAI also reported a large advantage on longer professional workflows. GPT-5.6 Sol scored 52.7 percent on Agents’ Last Exam compared with 40.5 percent for Fable. On the independent Intelligence Index, however, Fable still held the one-point lead. The reasonable conclusion is that both models are frontier-class, with Sol currently offering the stronger overall price-to-performance ratio.

Luna may be the most practically important release in the family. It scores 51 on the Intelligence Index and 75 on the Coding Agent Index while costing about 80 percent less per evaluated task than Sol. For workflows that launch several agents, retry failed work, or process large queues, those economics can be more valuable than squeezing out the final few percentage points of performance.

At every tested Terra reasoning level, either Sol or Luna provided more intelligence for the same cost, or similar intelligence for less.

So there’s a free tip! In the GPT-5.6 family, avoid Terra!

Grok 4.5 is surprisingly good

Grok 4.5 was jointly trained by Cursor and SpaceXAI. Cursor says its training included trillions of tokens from interactions with codebases, tools, and developer agents, along with broader data from STEM, research, and professional knowledge work.

This is the first model from the partnership intended for more than software engineering. It was trained through reinforcement learning on realistic environments that required the model to investigate problems, use tools, recover from mistakes, and verify its work.

Its independent results are impressive. Grok 4.5 improved 16 points over Grok 4.3 on the Artificial Analysis Intelligence Index, reaching 54. In Cursor’s Grok Build harness, it scored 76 on the Coding Agent Index, effectively matching GPT-5.5 and landing just behind Fable.

Grok does not beat Fable or GPT-5.6 Sol in overall intelligence. It does crush them on cost.

Artificial Analysis measured a cost of $2.49 per coding-agent task for Grok 4.5, compared with $11.80 for Fable in Claude Code and $5.07 for GPT-5.5 in Codex. Grok used about 1.9 million tokens across the Coding Agent Index, compared with 7.2 million for Fable and 6.2 million for GPT-5.5. Its API price is $2 per million input tokens and $6 per million output tokens.

Those numbers make Grok attractive for code-generation loops, terminal agents, and workloads where you can run automated tests or another reliable verifier afterward.

There is an important caveat. On Artificial Analysis’s knowledge-reliability evaluation, Grok’s accuracy increased from 35 to 52 percent, but its hallucination rate also rose from 25 to 54 percent. It knows considerably more than its predecessor, while also becoming more willing to answer incorrectly. Grok looks strongest in environments where its work receives direct feedback from tests, compilers, databases, or other deterministic systems.

Google is still playing a different game

Gemini 3.5 Flash does not currently lead the broad intelligence rankings, but it remains a serious frontier option because Google has optimized around a different set of constraints.

It accepts text, images, audio, and video, supports a one-million-token context window, and is designed for high-throughput agentic work. Google reports scores of 76.2 percent on Terminal-Bench 2.1, 83.6 percent on MCP Atlas, and 83.6 percent on MMMU-Pro. Artificial Analysis currently measures output speeds around 162 tokens per second.

For agents that need to inspect video, process audio, understand large visual documents, or return results with low latency, Gemini can be the better engineering choice even when another model has a higher composite intelligence score.

This is another reason permanent model rankings have become less useful. Google is competing on speed and multimodality. Anthropic is competing on sustained analytical quality. OpenAI is competing aggressively on coding performance and cost. Grok is competing on agent economics.

How I choose models right now

I would avoid standardizing your entire workflow or an entire engineering organization around one model.

Route work according to what you observe:

• Use Fable 5 for your hardest open-ended investigations and long-running work where analytical quality is the primary concern.

• Use GPT-5.6 Sol for great coding agents and professional workflows where you want frontier performance without Fable’s full cost.

• Test GPT-5.6 Luna as the default for high-volume agents, background tasks, and parallel subagents.

• Use Grok 4.5 when cost efficiency is important and the output can be verified automatically.

• Keep Claude Sonnet 5 in consideration as Anthropic’s practical daily model. It is included across Claude plans and launches at $2 per million input tokens and $10 per million output tokens through August 31.

Want more practical tips like these to help you stay on top of a quickly-changing AI toolset? I’d love to have you join us for the paid membership, where you’ll unlock our full archive of deeply technical guides.

Subscribe now

Competition is doing its job

Anthropic released an extraordinary model and planned to charge subscribers separately for meaningful usage. OpenAI then shipped a model that is nearly tied with Fable on independent intelligence evaluations, beats it on a major coding-agent index, costs much less, and is included inside its existing products. Grok arrived with near-frontier coding performance at a fraction of Fable’s cost.

So who wins? Not investors :)

Maybe Anthropic would have made the same decision without those releases. From a customer’s perspective, the cause is less important than the result.

The leading labs are now close enough that each can expose a weakness in another company’s offering. A model can have the highest intelligence score and still lose on coding, latency, multimodality, access, or price. Developers have credible alternatives, and switching costs remain low enough to keep the pressure on.

That pressure is giving us more capable models, cheaper inference, better subscription access, and several genuinely good choices instead of one default provider.

The frontier has rarely been more confusing. It has also rarely been this favorable to the people actually using the models.

Leave a comment