This message was just sent to Team XBOX employees globally.

Team,

I’m writing to share several updates as part of the XBOX reset outlined earlier this year.

First, we are eliminating 268 roles across Halo Studios, other first-party studios, and the XGS management and central functions layer. The actions completed since July, inclusive of the studio divestitures, bring us roughly three-quarters of the way through previously announced restructuring. I am deeply grateful for what our colleagues have built, and I know how difficult today will be for those leaving and the teams around them.

Second, we are reorganizing our studios. The goal is to strengthen our franchises and games by operating fewer business units, aligning groups that already work closely together, and focusing our publishing expertise.

• Activision will expand its remit to World’s Edge, as well as Rare. Activision will also be developing the next Halo title, led by a new, purpose-built team that is separate from ongoing development and plans for Call of Duty. A small team at Halo Studios will continue supporting the Halo community and games in-market.
• Bethesda will expand its remit to include Obsidian, which will continue its current projects, including Grounded, as well as the new Fallout project made in collaboration with Bethesda Game Studios.
• King will expand its remit to include Microsoft Casual Games, uniting our two global leaders in casual game design and live operations.
• Playground and Turn 10 will come together as one studio focused on the Forza and Fable franchises. These two studios have been creative and franchise partners for over a decade, and today’s changes will formally move their work into one team.

Third, an update on our studio divestitures: In August, Compulsion and Double Fine returned to management with their IP, back catalogs, and runway funding. Undead Labs has now successfully transitioned on similar terms and, with a new publisher, will release State of Decay 3 day one on Game Pass. Unfortunately, two separate agreements for Ninja Theory fell through. We will now begin consultation with employees on a proposed closure while continuing to explore other paths forward. Consultation with Arkane remains underway and is expected to continue through the end of the year.

Today, our focus should be on supporting those affected and treating one another with care and respect. I will spend time with our studios over the next week. At our October 6 town hall, we will come together as an ALL-XBOX team to reflect on our progress and look ahead to one of the strongest game lineups in our history.

Matt

The post Continuing Our Reset appeared first on XBOX Wire.

It was a pretty insane day for frontier models. OpenAI shipped GPT-6 Sol and Luna at very competitive pricing, while Anthropic dropped Claude Opus 5.5 with similar performance to Fable but 40% cheaper. Model-as-a-service stays very interesting when it’s priced competitively to run-it-yourself models.

[blog] Analyzing Jev, a new AI model. Great down-to-earth description of what this model does, and how it probably works.

[blog] Bring Jev to BigQuery with Cloud Run. Extensible systems, for the win. Jeff uses BigQuery’s remote functions capability to invoke the Jev model for fast scoring.

[blog] JetBrains Air: Building a System of Products for Agentic Software Development. Maybe it’s just me, but I still haven’t noticed a ton of good options for teams working with AI. Lots of products and experiences targeting individual users. This seems like a step forward.

[blog] Trying the Software factory pattern. I liked the callouts to the moving bottleneck, and some of the things that must be true for this pattern to work.

[article] 1 in 4 agents run unmonitored, giving way to operational risk. Goodness, you all use a LOT of observability tools. Up to twelve at 75% of IT orgs.

[article] Meta’s Muse is outpacing ChatGPT’s early mobile launch. They’re doing everything right at the moment. Great messaging, solid experience, wide appeal. I’m sure there will be snafus (permissions, etc), but the personal agent moment is now.

[article] Instagram Writing and the Decline of Reading. I’m guilty of this, or maybe as Steve says, just adapting to the times. That said, embrace nuance and long-form reading, not just punchy definitive statements.

[blog] 6 Ways Traditional API Design Has Changed Forever. Most of these relate to the new types of consumers and access patterns.

[blog] Your Adaptive UI Has No Screenshot. Test the inputs, not the outputs. As we have more generative interfaces that don’t look the same for each person, you’ll want to learn more about how the user got there.

[blog] Colab is now part of your Google AI plan. There’s a heck of a lot of value in these plans. Now you get premium access to better hardware for data science work.

[blog] 10 tips to improve your coding agent game. These are some surprisingly dense tips. Good ones that made me stop and think.

[article] Fixing agent memory. We’re probably hold agents to a higher standard than we hold ourselves. I forget or misremember things all the time. Matt says we need a way continuously validate agent memories.

[blog] Shopify returns to native, and what that says about rewrites in the agentic era. It’s a signal, just like a few high profile companies switching to private clouds a decade ago. But don’t over-index until there’s proof it’s a trend.

Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:

AI is great for making teams faster. But is it sustainable? What about maintainability, and burnout, and lock-in?

This is part 3 of my series on quantifying AI’s impact on software development. In part 1, we looked at why assessing impact is important, and what not to do. In part 2, we looked at how to measure AI’s impact on delivery speed. In this part, we’re looking at how to measure and model the unintended consequences of using AI. Then we’ll wrap up in part 4 (coming September 29th) with an examination of business outcomes. Finally, an epilogue puts it all together with notes you can share with your CFO.

To be notified when next week’s update comes out, add my feed to your RSS reader or subscribe to my free mailing list. Details here.

Does Maintainability Even Matter?

I can hear it now: “Who cares about namby-pamby issues like maintainability and burnout? It’s a job. If jobs were supposed to be fun, they wouldn’t be called ‘work!’ Suck it up!”

So let me be clear: we care about AI’s unintended consequences because they have real economic impact. If code isn’t maintainable, features take longer to write and bugs take longer to fix, taking time away from more valuable work. If people are burned out, they don’t put forth their full effort, and they eventually quit, taking institutional knowledge with them and leading to time-consuming hiring cycles. If you’re locked in, and AI token costs increase, you could be stuck with a choice between a big bill and cutting back on development.

Among the people I’ve talked to, there’s widespread agreement that heavy use of AI produces code that humans have trouble understanding. But there’s disagreement about how much that matters. If AI is doing the maintenance, do we care if a human can understand the code?

There are strong opinions on this topic on all sides, but not a lot of actual evidence. What’s clear is that the costs of maintenance and other unintended consequences do matter... but only if there are any costs. This is what we need to measure. Is there an impact? If there is, is it enough to matter?

Unfortunately, unlike the rigorous speed trial we discussed in part 2, unintended consequences are gradual and fuzzy. Your measurements are going to be noisy and lagging. You’ll have to create models and explore scenarios. Ultimately, your decisions will come down to judgment: informed by your measurements and models, but not driven by them.

One Ring to Rule Them All

There is one idea that, while not perfect, does a good job of capturing the majority of unintended consequences. It’s cost of change.

Put simply, cost of change is like a tax on the changes you make to your software. When cost of change is low, complicated changes still take time, but they’re achievable. When cost of change is high, even simple changes can take weeks, and complicated changes seem completely out of reach.

Cost of change isn’t easy to measure, but there are several indicators you can use to inform your judgment.

Value-Add Percentage

Value-add percentage is the percentage of your software development effort that’s spent on things that bring value to your business, such as new features, versus the percentage of effort that’s spent on non-value-add work, such as fixing bugs, resolving incidents, and manual test and release cycles.

Non-value-add work is called “muda.”¹ Some muda is necessary, even valuable, but that doesn’t make it value-add. Imagine a demanding and crotchety customer that always asks, “Why didn’t you just do it right the first time?” If that customer won’t pay for something, it’s muda.

¹“Muda” is a Japanese word that comes to us from the Toyota Production System, the inspiration for the Lean Software Development movement.

That’s why bug fixes are muda: “I’m not paying you to fix a bug that shouldn’t be there in the first place!” And performing releases: “Why don’t you just ship it already! How hard can it be?” Sure, bug fixes can be valuable, and releases are necessary, but they’re still muda.

I find it useful to distinguish muda further into discretionary and non-discretionary muda. Discretionary muda is work that you choose, such as investing in code changes that decrease development costs. Non-discretionary muda is work that’s chosen for you, such as bug fixes, incidents, and dependency upgrades.

You’ll always have a baseline amount of non-discretionary muda. It’s a constant tax that takes time away from other work. But if it’s rising, something has gone wrong. It means the time you spend on value-add work is going down. You have less time to work on things that matter. Your costs are increasing.

When I was VP of Engineering, value-add percentage was one of my key metrics. I made decreasing muda a priority, and it paid off. We doubled our value-add percentage over the course of my three years there, which allowed me to free up people for substantial new initiatives without increasing headcount.

DORA metrics

Your organization is likely already tracking the DORA metrics of change lead time, deployment frequency, change fail rate, and so forth. If not, they’re worth considering. As with value-add percentage, changes in these numbers are something to keep an eye on.

Token Usage

Tokens are a literal cost, and the more tokens it takes to make a change, the higher your costs. By definition! Unfortunately, token usage can fluctuate for many reasons, not just cost of change. Still, it’s worth keeping an eye on. Anecdotally, better-constructed software is easier for AI to work with and costs fewer tokens.

One of the biggest variances in token usage is people’s level of adoption. Rather than just tracking overall usage, keep an eye on individual usage changes. In the charts I’ve seen, usage has formed a Pareto curve. Increases in usage by people on the low end of the curve may just represent increasing familiarity. Increases by people on the high end of the curve are worth investigating further.

Changes in models, harnesses, prompts, and more will all affect token usage. This metric is only advisory. It’s meant to trigger further investigation, not to be used on its own.

One Ring to Find Them

Of these metrics, value-add percentage is the one I trust the most. It operates at the level we care about: where is the time going?

Tracking value-add percentage doesn’t have to be a big burden. You don’t need time sheets or detailed task tracking. The trick is to not care overly much about precision. Tracking work within a day or two is good enough.

When I did this tracking, I piggy-backed on our valuable increment (VI) tracking. Each one was several days to several weeks of work, and could be cleanly categorized as either value-add or muda. But you don’t have to use VIs; any tracking approach will work.

Don’t get too fine-grained with your tracking. When I was VP, managers checked in with each team twice a week and recorded which VI the team had worked on and how many people had worked on it. Each VI was categorized as “muda” or “value-add,” and we had a bunch of subcategories that helped us understand where time was going, such as “bug,” “capacity investment,” “major initiative,” and so forth. It was lightweight and very useful.

Review your value-add percentage monthly. If it’s going down, you don’t necessarily have a problem, but it’s worth investigating further.

The biggest problem with value-add percentage is that it’s noisy. My experience was that trends took 3-6 months to show up. It took a year before I was confident stating that my cost-of-change reduction efforts had led to lasting results.

That’s a long lag time, but it’s still worth tracking. My Product partners and I found value-add percentage incredibly valuable as a tool for communicating what was happening in product development. And, sadly, improving cost of change is a lot harder than making it worse. If AI is causing serious problems, it’ll probably show up more quickly.

One Ring to Bring Them All

Because your cost of change indicators will be noisy and uncertain, supplement them with models and scenario planning. Your models won’t tell you what the future will hold, but they will tell you what it could hold, which will help you manage risks.

Here are some of the models I’ve found useful:

Maintainability

Model maintenance as a mandatory “tax” on development. For each month of value-add development, estimate a certain amount of maintenance in the following year, and then a lower amount of ongoing maintenance in every year after that. (Wisdom of the crowd estimation may help.) Then build a model that shows how many engineering-days are available each month. Subtract the time spent on maintenance. The rest is available for value-add.

To model AI’s impact, apply your measured development speed improvements. Estimate how AI will change maintenance costs and estimate effects on headcount. Then explore scenarios based on varying costs of AI maintenance.

If you only create one model, make it this one. I have a more detailed explanation here. It includes a spreadsheet you can use as a starting point for your model.

For example, using that model, if AI increases our speed by 50%, but token costs reduce headcount by 25% and maintenance costs are estimated to double, I can see that I’m only breaking even, despite the big performance improvement:

Excess Lines of Code

Lines of code aren’t a good productivity measure, but they are a reasonable cost measure. Generally speaking, more lines of code result in more maintenance costs.

This model works similarly to the previous one, but uses lines of code instead of engineering-days. Use traceability data to categorize commits as “value add” or “maintenance.” For each commit, measure gross code churn: the number of lines of code that were either changed, added, or deleted.

For each line of value-add change, estimate a certain amount of maintenance code churn in the following year, and then a lower amount in every year after that. Model how much maintenance code churn will be needed each month based on the value-add churn of previous months. (See the “tmux” tab of this spreadsheet for an example.)

To model AI’s impact, measure how AI affects code churn during your speed improvement trial. Then project value-add churn into the future and model how maintenance churn could change.

The advantage of this model is that you can use (part of) your actual commit data to refine your estimates. For example, the following graph uses real commit data from the open-source tmux project.² Prior to running the model, I guessed one line of maintenance for every line of value-add in the first year, and 0.1 lines every year after that, which turned out to be a surprisingly close match to the actual data.

²Many thanks to Christophe Stjernlöf for providing the raw data from the tmux project. He used an LLM to classify commits as “value-add” or “maintenance.” The stairsteps are an artifact of the way the data was collected.

Lock-In

If token costs increase, how will you respond? Will you cut headcount? Reduce your use of AI? Switch to a less capable model?

To model these effects, update the “maintainability” model. Reduce your monthly engineering capacity according to headcount, and estimate reductions to your speed improvements based on AI reductions. You may want to add a separate set of estimates and calculations for humans maintaining AI-written code.

Burnout

AI Disclaimer: This image was created with OpenAI’s GPT-5.6 Sol model operating in “High” thinking mode.

Productivity is likely to go down as mental exhaustion goes up, and turnover is likely to increase. I don’t think you can model these effects with any accuracy, but you can still keep an eye on them.

Include mental exhaustion as part of your development speed study to see if there’s a significant difference in mental exhaustion between the two approaches. Follow up with periodic one-question surveys about people's mental energy levels. Pay attention to actual turnover, relative to historical numbers, and look for complaints about AI in exit interviews.

And in the Darkness Bind Them

There’s a dark side to value-add percentage. It’s incredibly easy to game. As soon as managers think their teams are being judged based on how they categorize their work, the temptation to tweak the categorization in their favor will be exquisite.

It doesn’t even have to be fraudulent. A leader with prioritization authority and something to prove can simply decide to defer maintenance in favor of value-add work. The pressure to do so is already immense, and it takes unusually strong character to resist.

(If you really hate your company, consider this: You can get away with deferring maintenance for a couple of years. Just enough time to line up a bigger title at a different company! Then your successor is left holding the bag, and your old company wonders why product development can’t get anything done any more.)

I don’t have an easy answer to these problems, other than to remind you to use these metrics to evaluate your approach, not your people. There is no metric that can’t be gamed, and this one is more gameable than most. But it’s also critical for understanding AI’s possible downsides. Use it, but use it with caution.

Development speed and unintended consequences are two sides of the same coin. They help us understand how AI changes how much we deliver, both now and in the future. But just delivering more software isn’t enough. We need to produce the right software. We’ll look at business outcomes next week, in part 4.

To be notified when next week’s update comes out, add my feed to your RSS reader or subscribe to my free mailing list. Details here.

The quantum countdown: Why post-quantum cryptography is a strategic imperative

As part of my fellowship at Harvard, I’ve been thinking hard about artificial intelligence (AI). Start with the physics of the problem: AI is what lawyers call an unavoidably unsafe product. No matter how carefully we build it, it is going to cause harm, and some of those harms will be unforeseeable. That is not a bug we can engineer away. It is an intrinsic property of the thing, the same way it is a property of pharmaceuticals, vaccines, knives, and power tools.

We already have plenty of laws and legal mechanisms for dealing with unsafe products and the harms they cause. The problem is what those mechanisms are built to see. A courtroom is very good at looking at one specific case and measuring the actual loss to one specific person. It is a terrible instrument for weighing that loss against the enormous benefits the same product produced for everyone else.

Tort law is a microscope for a problem that needs a scale.

But we have stepped on this rake before. 

In the 1970s and 1980s a number of plaintiffs sued vaccine manufacturers and won huge awards (Reyes v. Wyeth Laboratories & Givens v. Lederle Laboratories). The manufacturers looked at the math and said, “We’re out.”
They were going to stop making vaccines.

Congress recognized this as a public health infrastructure crisis and built a special solution: National Childhood Vaccine Injury Act, aka the Vaccine Court. If you suffer a covered injury, you bypass civil court and petition a specialized federal claims court in an adversarial proceeding against the government. If your condition matches an established injury table—or if you medically prove causation for off-table harm—you receive compensation from a consumer-tax-funded trust fund. That resolved the core dilemma: manufacturers secured statutory protection from ruinous tort liability to keep producing vaccines, while injured individuals gained a dedicated, no-fault avenue for funded relief without having to prove manufacturer negligence.

So I wondered: could we do the same thing for AI?

My original proposal was simple. AI companies that follow best safety practices would get limited liability for harms, adjudicated through an AI Harms Court. Instead of shopping it around to friends who would be polite to me, I ran it through my AI Rosetta Stone debate tool to see how the different camps would attack it.

My original proposal folded like a cheap lawn chair.

The first problem it found was that we don’t actually know how to do AI safety, and “safety” for a toy chatbot is completely different than safety for a medical dosing system. So I revised: the proposal would define a tiered set of safety practices, and a research institute funded by the participants in the program would establish and maintain those practices.

I ran it again and then it went after auditing and funding. Who pays, and who checks? So I revised again: the AI companies fund the program through an excise tax, and independent third-party auditors, not the companies themselves, verify that a firm actually followed the practices before it qualifies for coverage.

Round after round, it kept going. It pointed out that a cryptographic receipt proves a process ran, not that it was the right process. It pointed out that a deployer-only tax lets the developer who made the design choice off the hook. It pointed out that a population-scale telemetry archive is itself a surveillance asset that someone will eventually want to repurpose. Each time, the proposal got harder to knock over. The current version is at the end of this post.

But the specifics are not really the point, even though I find them interesting. The point is that the debate tool did for my thinking what a good adversarial review does for code or a red team does for a deployed system. It showed me the issues I had not seen. It showed me how people who don’t share my priors would look at those issues. And it let me strengthen the argument one step at a time, with each round building on the last, instead of presenting a finished product and hoping nobody found the cracks.

If you work in AI policy, I encourage you to use the tool the same way. Take the idea you are most attached to, put it in the ring, and see what survives. Then let me know what you think.

I recently ran the debate using Claude Fable and it brought up even more interesting points. Check it that debate HERE.

If you really want to roll up your sleeves and go into learning mode, change the mode from “Text” to “Analysis” and watch the details of how the arguments are being made and being grounded in a rich documented taxonomy of Beliefs, Desires, and Intentions.

Here is an example of what that will give you:

The current proposal for an AI Harms Court, in brief

Congress establishes a National AI Injury Compensation Program, modeled on the vaccine program but with one critical change: immunity is earned by measured deployed behavior, not by paperwork.

• A no-fault compensation board with subpoena power pays injured claimants from a dedicated trust fund, without requiring proof of but-for causation.
• Tiered safety standards, with tier definitions and metrics written by independent researchers through public rulemaking, never by the firms being tiered.
• Immunity as a continuing condition. Systems must stay within pre-registered thresholds for error rates, subgroup disparity, and human escalation, verified by continuous telemetry. Breach a threshold and immunity suspends until the fix is verified in production.
• A split excise levy: a certification charge on developers keyed to model capability, plus an execution charge on deployers, with graduated duties and rebates so the program does not become an incumbent moat.
• Independent auditors, funded by the levy, employed by the board, barred from certified firms, with multiple audit shops using different methods.
• High-stakes tiers carry insurance and capitalization floors, pooled liability for correlated failure, a 90-day pre-deployment safety case, and no immunity at all for irreversible harms.
• A design-defect track, because some defects never trip a behavioral flag.
• Recourse for individuals: when a system is flagged, every affected person gets notice, a docket number, and the logs.
• Surveillance safeguards written into the enabling statute: purpose limitation, separate cryptographic doors for auditors and the state, a flat bar on law-enforcement repurposing, and retention limits.
• Firms that skip the standards get nothing: no fund coverage and full tort exposure.

Yesterday was Grok 4.7 (pelicans) and MiMo v2.6 Flash/Pro (more pelicans). Today Anthropic released Claude Opus 5.5, and around an hour later OpenAI released GPT-6 Sol and GPT-6 Luna. It's going to take a while to get a good read on all of these new models, but here are my impressions so far.

GPT-6 Sol and Luna are half the price of their GPT-5.6 equivalents

GPT-5.6 Luna was already my favorite model for building applications against, because it combined excellent performance with being really cheap. Somehow GPT-6 Luna is half the price of that again - and GPT-6 Sol had a similar reduction compared to GPT-5.6 Sol.

Here's what the pricing landscape looks like today:

Note that GPT-5.6 has a scheduled 25% price increase for November, so GPT-6 is half the price of the promotional pricing for those models.

(With GPT-5.6 Terra priced the same as GPT-6 Sol, any remaining reasons to use Terra just evaporated.)

It's hard to overstate how competitive this pricing is. Grok 4.7 priced itself at $2/$6, less than half the price of GPT-5.6 Sol, but is now equally priced to GPT-6 Sol on input and closer on output.

At $0.10/$0.50 GPT-6 Luna is one of the cheapest models OpenAI have ever released, beaten only by the far weaker GPT-4.1 Nano ($0.10/$0.40, April 2025) and GPT-5 Nano ($0.05/$0.40, August 2025).

I rendered pelicans for GPT-6 Luna and for GPT-6 Sol, then I combined them all together in this comparison grid along with the GPT-5.6 pelicans. I like how you can instantly see that the 5.6 family chose bolder, brighter colors, while the 6 family is a lot more muted. I still think GPT-6 Astra on max produced the best pelican.

Claude Opus 5.5 got a price cut too

Opus 5.5 looks like it addresses the biggest complaints people had about Opus in terms of its communication style. Thariq Shihipar:

Opus 5.5 is the result of your feedback.

It communicates clearly, it's cheaper per token than Opus 5.0 with the intelligence of Fable 5.1 it's very token efficient and works across every effort level.

It's also meant to be better at Blender. I'm looking forward to putting it through its paces there.

Opus 4.5, 4.6, 4.7, 4.8, and 5 all shared the same price: $5/million tokens for input and $25/million for output. 5.5 is a 20% reduction - $4/million and $20/million.

The price for cache reads fell 60%. That's significant for longer agentic conversations, where 90%+ of input tokens are processed at cached token prices.

The new price for Opus 5.5 is the same as the price for GPT-5.6 Sol, but that was before OpenAI dropped their Sol prices by half.

GPT-6 Astra and Claude Fable 5.1 are both priced at $10/million input and $50/million output. The price war currently affects the next tier of models below that.

Anthropic say that Sonnet 5.5 and Haiku 5.5 are coming soon. It's going to be interesting to see if Haiku can regain its price competitiveness at the lower end, given current Haiku 4.5 is $1/$5 while the latest GPT-6 Luna is one tenth of that price at $0.10/$0.50.

Claude Opus 5.5 max over-thinks to the point of breaking

In a first for my "Generate an SVG of a pelican riding a bicycle" test, Claude Opus 5.5 at "max" thinking level failed to return a response!

It started by calling this "a classic test request", and then thought really, really hard about what it was doing:

This is a classic test request, so I want to plan out a well-composed pelican with its distinctive beak and pouch riding a bicycle with proper wheels, frame, and pedals, set against a simple sky and ground backdrop. [...]

Verifying the shin length checks out at roughly 95.2, close enough. Now I'm working out the near leg path from hip to knee to ankle, then sketching the foot shape resting on the pedal — outlining the heel, toe tips, and sole contour with a path using lines and curves to sit naturally on the pedal surface around y=478-494. [...]

I like the fish sticking prominently out of the basket with the pelican eyeing it as a fun detail worth keeping. I'm also confirming the eye placement near the bill base matches typical pelican anatomy, and considering giving it a slightly happier expression. [...]

The far leg reads correctly as passing behind the frame, so I'm moving on to check the chainring teeth and confirm layer ordering—the far crank arm should be mostly hidden by the seat tube and chainring. I'm settling on the final SVG's width and height attributes alongside the viewBox to ensure proper scaling, noting there's no text so no font-family is needed. [...]

I was so excited to see this pelican... but then it stopped. Opus 5.5 has a 128,000 maximum output token limit (as do the other Claude models), and it hit that while it was still reasoning about the SVG!

I tried a second time and got the same result. This makes me suspect that "max" is effectively useless - if it over-thinks to breaking point on a stupid SVG prompt I don't trust it not to do the same for more interesting work.

(Those two failures each cost me $2.56 and took nearly 20 minutes.)

Fable 5.1 on "max" didn't over-think and did give me the best pelican I've seen from any Anthropic model.

Here are the Opus 5.5 pelicans, excluding 5.5 max.

I also built this comparison grid comparing them with pelicans by Opus 5, Fable 5.1, and Sonnet 5:

Comparing different model vendors by how well they draw a pelican riding a bicycle may not make much sense now (if it ever did), but I'm still finding value in using them for comparisons of the same model families at different reasoning levels.

I'm now using GPT-6 Sol and Claude Opus 5.5 as my default models in Codex and Claude Code. I've upgraded the Datasette Agent demo at agent.datasette.io to use GPT-6 Luna, and it seems to be fast and competent at both SQL queries and building HTML and JavaScript for Datasette Apps.

Tags: ai, openai, generative-ai, llms, anthropic, claude, llm-pricing, pelican-riding-a-bicycle, gpt