Introducing Claude Opus 5
Anthropic's everyday model for developers and knowledge work, at half the price of Fable 5.

The thing it turned out to be good at was not writing code. It was reading a codebase and telling me what was a miss with it.

I pointed it at this portfolio, and the findings were not the ones I expected. It showed the intelligence similar to that of Fable 5, but less token hungry than it!

Next.js 16.3: Instant Navigations
Partial Prefetching, Instant Insights, and a reusable loading shell per route.

The fix borrows the one genuinely good idea from single-page apps. Instead of prefetching per link, Next.js now prefetches a reusable shell per route and caches it on the client for the session. A sidebar with twenty chat links used to mean twenty requests; now it means one, for the /chat/[id] route, reused across all of them. It is the same mental model as per-route code splitting, applied to data fetching.

The other half is a diagnostic rather than an optimization, and I suspect it will change more codebases than the prefetching does. Slow navigations become an actual error in development. When a route awaits data, you are pushed to pick one of three options: Stream it with <Suspense>, Cache it with 'use cache', or explicitly opt out with export const instant = false. That last one matters, because "this route should block" is a legitimate choice for a blog post, and being made to state it out loud is better than having it happen by accident. There is also an instant() Playwright helper so you can assert what must be visible before the network resolves, which is the first time I have seen a framework ship a test primitive for perceived performance.

This is the 16.3 preview, not a stable release. You install it with npm install next@preview, and both features are behind cacheComponents: true and partialPrefetching: true flags. There are known issues, including some Instant Insights tooling that misbehaves in Safari.

I am staying on stable 16.2 here for now, partly because this site is almost entirely static and gets very little out of smarter prefetching. But the direction is right, and the honesty about the old behaviour is refreshing. The framework spent a couple of years insisting the prefetch flurry was fine, and it is genuinely good to see that walked back rather than defended.

Gap decorations: Now available in Chromium
row-rule, column-rule for grid and flex, and insets for controlling how far a line runs.

The design is the part I like: rather than invent a new syntax, it extends column-rule (which has existed for multi-column layout for years) to work in grid and flexbox, then adds row-rule as its counterpart. The shorthand takes width, style, and color, exactly like border, so there is nothing new to learn.

.row-list {
  display: grid;
  gap: 1.5rem;
  row-rule: 1px solid var(--color-hairline);
}

That draws a line in each gap, which means N items produce N-1 dividers. No last-child override, no off-by-one, no pseudo-element. There are also row-rule-inset and column-rule-inset properties for pulling the line back from the edges of the gap, which is how you get the inset dividers that most design systems actually want. Critically, the decorations are purely visual: they do not participate in layout or change spacing, so you can add them to an existing grid without anything shifting.

The caveat is the obvious one. This is Chromium 149 only right now, not Baseline, so Firefox and Safari users see no line at all. That makes it a progressive enhancement rather than a migration: keep the borders you have, or accept that the divider is decorative and let it be absent. I am holding off on ripping out my own hairlines until Firefox lands it, but this is the first time in a while that a new CSS property has replaced a hack I actively resented.