AI Subscription plans are more generous than API pricing

2026-06-12T21:10:19.104437+12:00

SemiAnalysis did a test on Anthropic/Claude subscription plans, running long horizon tasks until they maxed out.

The subscriptions are far more generous than API pricing.

When I first started using these tools I went the API route as my personal usage fluctuated a lot. But after a couple of months it was clear this worked out a lot more expensive and so switched to the paid plans even if not using all the quota.

Go with the paid plan.

Designing a Feature with Claude Design — Then Handing It to Claude Code

2026-05-31T17:48:59.372831+12:00

I've been wanting to give Claude Design a try. In this post I'll walk through my first use of it for designing some new functionality I wanted for my blog CMS. My use here is probably very basic, but it was an interesting exercise, and in particular I wanted to see how I could hand the design off for building.

Just a small disclaimer: I'm not a UX designer, or a creative person in general. But that's exactly why this exercise was interesting — it did a far better job than I ever could.

Getting into it...

I've recently built this blog site where this article is being read (I will write about this separately). It's very new and the feature/capability set is minimal, just enough functionality to manage, publish and serve blog content.

It has a custom-built CMS for managing the content, and supports slug-like tags that I can selectively apply to any of the content. These tags are visible to the right side of this article (or at the bottom on mobile).

When writing or editing content, it has a section where I can add new tags or use existing ones. Below shows editing an article in the CMS I wrote recently about human reviews being a bottleneck.

The behaviour of the tags input field is: On post creation, any never-before-seen tags will be created in the tags table in the database, existing tags will be referenced.

At first sight it looks ok, but:

It has no option to select existing tags.
It doesn't indicate if a tag being added was one that already existed or would be created.
It doesn't help me avoid creating near-duplicate tags with a similar name or even typos.

One wouldn't want different blog articles using tags that mean the same thing but with slightly different names. For example ai-engineering and engineering-with-ai, or even a typo in the tag like ai-eginering. So without any kind of tag selection, and the behaviour of the existing tag selection and creation, this made the UX painful (I had to open the tag management section in a different tab to remember what tags were available) and susceptible to tags becoming a mess across all the content.

Using Claude Design

Claude Design was introduced on 17 April. I had had a bit of a poke around in it before to see what it was about, but this was the first chance I had to try it out on something real.

I started by pasting four screenshots of the CMS and giving it this prompt. (I used the term "upsert" for tags, which wasn't quite correct, but Claude got it).

Attached are four screenshots of my blog CMS. One is where tags are managed, show when two tags existed; ai and harness-engineering. The second one is showing where I can add a post and enter tags. How it currently works is I can enter any tag value and when the post is created/published then the app(or probably the backend for the CMS) will upsert tags.

So you can see in the third image I enter two tags, one existing and the second one (new-tag) is new, so when the blog post got created is used the existing tag and then created a the new-tag, as shown in the fourth image, where I then have a total of three tags. (Two were existing one new one got created on that new post).

I like this functionality. However, right now when I enter tags on the create post page I don't get offered to select from existing tags, so if my new post should use an existing tag I have to carefully remember or go back and look in the tags section to remember the exact name of the tag so I don't end up with near duplicated for what should be the same tag.

Ideally when I start typing for a new tag, it should show existing tags that match (like contain) the text I have entered, with the option of selecting one of those. If none match it should allow me to add a new tag.

Come up with three options for the post create screen for selecting existing or adding tags. Should be simple and seamless and easy to use.

The prompt is relatively verbose (easy to do with voice dictation), but I wanted Claude to really understand how it currently works and what I am looking for.

Importantly at the end I asked for three design options.

After a fair bit of time it presented me with a fully functional interactive prototype, with three separate design concepts which I could toggle between with a selector at the bottom. And the generated designs looked very close to my actual CMS.

Concept A: auto-complete (shows matching tags as you type, with option to create)

Concept B: command-popover (shows all tags, filtering as you type, with option to create)

Concept C: A tag shelf

To be honest, I was really impressed with this. All these options look really slick. How long would it have taken a designer to come up with this before these kinds of AI-assisted design tools existed, especially with a fully functional interactive prototype? I am not a creative person and for personal things like my blog CMS these kinds of designs would never have seen the light of day.

Stretching a bit further with related functionality

I had already also been thinking about adding additional AI-generated tag suggestions functionality as a separate piece of work. I spend a ton of time trying to think about tag names for content. So I thought I would see how Claude Design would go with extending what it had already proposed while also incorporating this new AI tag suggestion functionality.

Here's the prompt I gave it:

These look really great. And actually now while looking at it, it has made me think a bit further about this. I would like you to perhaps create another version of this (leaving the existing on in place so I can still refer back to it), where another killer piece of functionality would be tag suggestions. The suggestions here would be based on the content in the post being written, and would use a combination of matching to existing tags, but also potential new tags. I'm not sure if this is different from the selection of tags that you have already designed for, but I would imagine there would be an endpoint in the server that could get tag suggestions based on the blog content. Not sure if it would be automatic as typing the post (seems heavy on the server, especially as it may be doing outbound AI calls to get suggestions), or just a button to get suggestions, or perhaps something a little smarter like suggestions after a certain about of text, or based on the title + blog text, maybe some initial suggestion and then a small refresh button or AI type button to suggest tags. Would exclude suggestions that are already added to the post. Also need to consider when editing a draft, should also work. What nice clean simple design options would you propose with this, fitting into the design we have already designed for the tag selection.

I tried to give it my thinking but also leaving it open-ended for Claude Design to be creative with. It gave me another interactive prototype with three modes to choose from, and incorporated one of the tag selection design options from the first round.

Mode A: A button with the name "Suggest Tags", or as shown below "Refresh" which would generate new suggestions to choose from.

Mode B: Smart auto, which generated suggestions after enough post content existed, and a small refresh button.

Mode C: Assistant panel. This felt super chaotic.

I decided I liked "Concept A: Auto-complete" for tag selection and "Mode B: Smart auto" for tag suggestions. These two seemed to complement each other.

I got it to create a final version of the working prototype with those two options. And this time I also gave it my existing style guide for the CMS (I probably should have done that at the start).

Ok, I like the tag selection Concept A, along with Mode B (smart auto) with tag suggestions. Can you do one more round showing a functional version with these two options baked in. I have also attached the style-guide for the existing application as it's currently implemented, so if we could align as much as possible to that.

This image below shows the two separate pieces of functionality working together. Selection as a slick fly-over style drop down when typing, and option to select tags from the tag suggestion box.

Moving From Design to Implementation

So now I had a flash new design that I was pretty excited about. But now how to feed this to Claude Code so it can build it as accurately as possible to the designs?

The conversation I had with Claude during this design process contained a lot of critical context that the design artefacts alone wouldn't hold. So, not knowing what Claude Design would be able to do here, I just asked it to write up a requirement doc based on the conversation and final design options chosen.

Ok, can you write up a set of requirements and acceptance criteria for this new functionality. Note that the develoers are never have going to have seen the other options, they just need to see the final solution and spec. The exact endpoint name for example is not that important, but what is important is how it's expected to behave and return so the UI functionality can work as expected. How the UX and interface behaves does need to be quite specific. Write this as a markdown document.

And lo and behold, it gave me a detailed requirements document! This is what it produced.

There are some options to hand off to Claude Code. I just downloaded the zip file.

I added the functional design prototype and the requirements document to an in-progress folder in my already created git worktree, ready for the next phase of planning and building.

The prototype has a lot of boilerplate code as it was a fully functional web site. However, for Claude to reference this, along with the requirements document it generated during the planning and implementation phases meant it would greatly increase the probability of getting it as close as possible to the design. And it did.

My code base for the blog application is already very well primed with context, structure and tooling that allows streamlining real engineering with AI. And I have templates and agent skills that help me create design specs and implementation plans for Claude to execute on.

This design exercise above happened the day after Opus 4.8 was released, so I was super keen to do some building with it, and also try out their new Dynamic Workflows.

The design and build was all fully completed on the same day (well to be more accurate, about two-thirds of the build was done while I was sleeping).

I will follow this article with another one running through how I did the build. I was quite happy with how that went.

Higher usage limits for Claude and a compute deal with SpaceX

2026-05-08T09:51:27.357827+12:00

Higher usage limits for Claude and a compute deal with SpaceX

Anthropic partnering with SpaceX to lease their Colossus 1 data center (over 220,000 NVIDIA GPUs).

While that on it's own is interesting, the astonishing side effect of that is a sharp increase in usage limits in paid Claude plans and their APIs.

The following three changes—all effective today—are aimed at improving the experience of using Claude for our most dedicated customers.

First, we’re doubling Claude Code’s five-hour rate limits for Pro, Max, Team, and seat-based Enterprise plans.

Second, we’re removing the peak hours limit reduction on Claude Code for Pro and Max accounts.

Third, we’re raising our API rate limits considerably for Claude Opus models.

I think people will generally appreciate this too:

Finally, we recently made a commitment to cover any consumer electricity price increases caused by our data centers in the US. As part of our international expansion, we’re exploring ways to extend that commitment to new jurisdictions, as well as partnering with local leaders to invest back into the communities that host our facilities.

Mozilla Used Anthropic's Mythos to Fix 271 Bugs In Firefox

2026-04-22T21:13:32.816976+12:00

Mozilla Used Anthropic's Mythos to Fix 271 Bugs In Firefox (via Simon Willison)

Mozilla has been one of the companies to get access to Anthropic's new Mythos Preview model. And have put it to good use.

As part of our continued collaboration with Anthropic, we had the opportunity to apply an early version of Claude Mythos Preview to Firefox. This week's release of Firefox 150 includes fixes for 271 vulnerabilities identified during this initial evaluation.

Our experience is a hopeful one for teams who shake off the vertigo and get to work. You may need to reprioritize everything else to bring relentless and single-minded focus to the task, but there is light at the end of the tunnel. We are extremely proud of how our team rose to meet this challenge, and others will too. Our work isn't finished, but we've turned the corner and can glimpse a future much better than just keeping up. Defenders finally have a chance to win, decisively.

This seems to validate a lot of Anthropic's claims about the new model's capabilities. And it's encouraging to know that this will likely soon be available to the general public, at some point, where they can be used to strengthen the security postures of existing and new systems.

When that eventually happens, people are going to need to act fast to find and resolve security vulnerabilities before bad actors get a chance to exploit them.

There will be casualties.

Loosely Coupled Thoughts — tagged claude

AI Subscription plans are more generous than API pricing

Designing a Feature with Claude Design — Then Handing It to Claude Code

Using Claude Design

Stretching a bit further with related functionality

Moving From Design to Implementation

Higher usage limits for Claude and a compute deal with SpaceX

Mozilla Used Anthropic's Mythos to Fix 271 Bugs In Firefox