DEV Community: RAXXO Studios

Claude Design vs Figma: What It Means for Designers

RAXXO Studios — Sat, 18 Apr 2026 12:46:51 +0000

Claude Design is a draft generator, Figma is a production tool, they cover different parts of the same design workflow
Figma wins on precision, collaboration, plugins, and the muscle memory five million designers already built over a decade
Claude Design wins on time to first draft, automatic brand application, non-designer accessibility, and the Canva handoff
Real impact hits PMs, founders, and solo marketers who never opened Figma, the designer base stays safe for now
The Canva tie-up is the strategic play that positions Claude Design as Canva's AI front door, not Figma's replacement

Every time Anthropic ships something new, a headline writer somewhere composes the "is this the end of X" story. Claude Design is getting the Figma treatment. I want to push back on that framing and talk about what Claude Design actually means for designers, product teams, and the design tools already on your screen.

I have used Figma daily for four years. I have used Claude Design since yesterday. Here is how the two actually compare, and where Claude Design genuinely changes something worth paying attention to.

Where Figma Still Wins

Figma has 5 million active users and a decade of muscle memory built up in those hands. That is not going anywhere.

Precision. Figma's vector tools, constraint systems, auto layout, and component variants are still ahead of any AI design tool I have used. When I need pixel-exact control, Figma is the tool. Claude Design is generating layouts, not letting me nudge a bezier handle by 0.5 pixels to get the curve exactly right.

Collaboration. Multiplayer Figma is core to how design teams work. Real-time cursors, in-file comments, branching, Dev Mode for engineers, library publishing, version history. Claude Design has conversation-based iteration but it is not a real-time multiplayer product.

The plugin ecosystem. Figma has thousands of plugins for icon libraries, component generators, chart tools, and accessibility checks. Claude Design has zero plugins on day one. This will change, but Figma is years ahead on third-party extensibility.

Design system infrastructure. Figma libraries, tokens, and variables are the source of truth for most design systems running in production today. Claude Design can read a design system but it is not where I would maintain one long-term.

If you are a designer shipping production UI, Figma stays on your dock. No question about that.

Where Claude Design Wins

Time to first draft. A pitch deck from scratch in Figma takes me 30 to 45 minutes if I am not copying from a template. Claude Design got me to an editable 10-slide deck in under 15 minutes. That is a 3x speedup on the part of the design process I hate most: the blank canvas problem.

Brand auto-application. Once Claude has my design system, every output is on-brand. No picking colors manually. No typography choices. No spacing decisions. Claude handles all of it automatically. Figma requires me to pull from a library and apply components myself to get the same result, which is faster than starting from scratch but slower than Claude's zero-click approach.

Non-designer accessibility. This is the one Figma will not solve without becoming a different product. My cofounder does not use Figma. The marketing manager at a 20-person startup does not use Figma. A founder prepping their seed deck at 11pm does not use Figma. Claude Design's text interface lowers the skill floor for design production to "can you write a sentence about what you want."

The Canva handoff. Claude Design exports to Canva as a fully editable file. Canva has 170 million users. Figma has 5 million. The audience sizes are not comparable, and Anthropic picked its distribution partner accordingly.

Who Actually Uses Claude Design

The people losing sleep over Claude Design are not designers. They are workflows that never touched Figma in the first place.

Founders prepping pitch decks. These decks used to come from a designer friend at 2am or a Google Slides template that looked like homework. Now there is a third option that gets to 80 percent polish in under 20 minutes.

Product managers mocking up flows. PMs have spent years sketching in Whimsical, FigJam, or on actual napkins, then handing those sketches to a designer to make real. Claude Design cuts that handoff step. The PM prompts, Claude produces, the designer reviews rather than creates from zero.

Marketers shipping campaign one-pagers. One-page campaign landing pages, email headers, social carousels used to be Canva territory or a designer bottleneck nobody wanted to be. Claude Design plus the Canva export covers this workflow end to end.

Solo makers. If you are the founder, PM, designer, and marketer all at once (which is most of indie SaaS), Claude Design is probably the biggest productivity unlock in this category since ChatGPT itself.

Notice what is missing from that list. Designers at design agencies. Brand teams at large consumer companies. Anyone whose output gets printed on billboards or ships in high-volume production. Those workflows still live in Figma and Adobe, and they will keep living there.

The Canva Play

This is the part of the launch I think most takes are missing.

Anthropic did not build Claude Design in a silo. It is built on Canva's Design Engine and Visual Suite. When I export to Canva, I am handing off to the 170-million-user platform that owns the "non-designer makes a design" market. Figma owns "designer makes a design." Canva owns everything else.

Claude Design is the AI front door to the Canva market. A prompt generates a draft that lands in Canva, where the user keeps editing with their existing Canva Pro subscription if they have one. The monetization is already figured out. The distribution is already figured out. Anthropic did not have to build a design tool from scratch and acquire users one at a time.

For Canva, this is a moat against Figma's recent push into the non-designer market. Figma Slides, Figma Sites, FigJam for brainstorming, all aimed at the audience Canva owns today. Partnering with Anthropic on an AI front door is a smart defensive play. For Anthropic, it is distribution into a 170-million-user audience without building a design tool from zero. Both sides got something they needed.

Figma's response will matter. Figma has its own AI tool (Make Designs), and more AI features are shipping in their roadmap. But Figma does not have a Canva-scale distribution partner, and building one takes years even if the product is strong.

Bottom Line

Claude Design is not the Figma killer the headlines want it to be. It is something more interesting. A new category of tool that unlocks design production for people who never used a design tool before in their working lives.

Designers keep their jobs. The work of turning a draft into a shipped product still requires human judgment, and Claude's output in 2026 is still drafts that need finishing. What changes is what lands on a designer's desk. Fewer "design this from scratch" briefs. More "polish this and ship it" requests. That is a different job, but it is still a job, and the designers who adapt to reviewing AI output will come out more productive, not less employed.

Non-designers get a real design tool for the first time in their careers. That is the bigger story nobody is telling. The 165 million Canva users who were already doing design work without the designer title now have an AI drafting layer in front of their existing workflow. That is a market expansion, not a replacement fight.

If you are a designer on Pro or Max, open Claude tonight and run your next three design tasks through Claude Design. See which ones hold up without Figma polish and which ones still need to go back to your main tool. Now you have your own answer, based on your own work. Ignore the headlines.

One more thing I want to call out for the designers reading this. The career anxiety around AI tools is real, but Claude Design is a terrible threat vector for the work most designers actually do. Figma is not going away in 2026. The production work, the pixel-exact polish, the cross-team systems thinking, none of that is what Claude Design targets. What Claude Design does is give non-designers a way to make the thing before the thing designers ship. That means more design work entering the pipeline, not less. Designers who learn to shepherd AI drafts through their production systems will come out on top of this shift. Designers who refuse to touch the tool on principle will ship slower than the ones who embraced it early, and the productivity gap compounds over time. Pick a side intentionally, based on what you saw in your own testing, not what the discourse tells you.

How to Use Claude Design: From Prompt to Production

RAXXO Studios — Sat, 18 Apr 2026 12:44:56 +0000

Setup takes five minutes: open Claude, find Claude Design in the sidebar, optionally grant design system access
Specific prompts beat buzzwords, name fonts, name colors, name counts, and state exclusions so Claude does not guess
Use sliders for nuance, inline comments for element-specific fixes, direct edits for anything numeric or textual
Export to Canva for polish, PDF for delivery, URL for feedback rounds, PPTX only when corporate demands it
My first real test: 15 minutes prompt to production for a 10-slide deck, roughly half that on the second try

I spent the last few hours running Claude Design through real work, not demo scenarios. A pitch deck for a client, a landing page hero, an onboarding flow mockup for a side project. Here is exactly how I used Claude Design, which prompts actually worked, and where I got stuck along the way.

If you want the launch explainer, I wrote that separately. This post is the hands-on workflow guide.

Step 1: Getting Set Up

Access first. Log into claude.ai on a paid plan (Pro, Max, Team, or Enterprise). Claude Design appears in the left sidebar under the main chat. If you do not see it yet, rollout is gradual. Check again in a few hours.

First launch drops me into a welcome screen with three options.

Start from scratch. Fastest way to play. It opens a blank canvas and a prompt box. Type my request, hit enter, Claude builds.

Build from a design system. Where teams get the real value. Claude asks for access to a codebase, a Figma file, or a design tokens file. I pointed it at my raxxo-brand repo. Onboarding took under two minutes. Claude pulled out my lime green (#e3fc02), my Outfit typography, my spacing scale (2/4/6/8/12/16/20/24/32/48/64), and my rounded corner conventions. Then it rendered a test card showing all the tokens applied correctly. No manual configuration required.

Starter template. Common formats like pitch decks, landing pages, mobile app flows, marketing one-pagers. Good if you are not sure what you want and need a prompt scaffold to work against.

My advice: do the design system onboarding once, even if it takes ten minutes. Everything you generate afterwards starts on-brand automatically, and that is worth the up-front cost on day one.

Step 2: Writing Prompts That Work

The thing nobody tells you about AI design tools: how you prompt matters more than the underlying model. Claude Design is powered by Opus 4.7, which is strong, but it still wants specifics.

Prompts that flop in my testing:

"Make me a modern landing page"
"A nice pitch deck for my startup"
"Something minimal and clean"

Prompts that actually work:

"Landing page for a Shopify app that saves store owners 10 hours per week on inventory. Hero with the 10-hour claim, three testimonial logos below, feature grid with 6 items, dark background, warm yellow accent, no stock photos."
"10-slide pitch deck for a B2B SaaS called Glasswing. Cover slide with logo placeholder, problem, solution, market size (40B), product screens, traction (20 percent MoM), team, financials, roadmap, ask. Dark theme, editorial typography, no gradients."
"Mobile app mockup for a daily journaling app. Lock screen widget view, home feed with three sample entries, writing screen with keyboard visible, settings screen. Warm neutral palette, serif typography, plenty of breathing room."

What actually lands: specific numbers, specific counts, visual vocabulary (dark, warm, editorial), and explicit exclusions (no gradients, no stock photos). Claude handles a brief like that directly.

Skip the adjectives. "Modern, clean, minimal" means nothing to the model. "Outfit sans-serif at 14px base, black background, four-column grid" means everything. Treat the prompt like a design brief you would give a freelancer who bills 150€ per hour. Specific beats vibes every time.

Step 3: Iterating With Sliders and Comments

First draft is never right. Revision is where Claude Design earns its price.

Conversation revision works like a regular Claude chat. "Make the hero headline bigger. Swap the accent color to lime green. Remove the second testimonial row." All handled in one reply. Useful for sweeping directional changes.

Inline comments are where I spent most of my time. Click an element, type a note like "this padding is too tight" or "this button should be secondary style." Claude fixes that one element without rewriting the rest of the design. Think of it as giving a designer a feedback round without scheduling a meeting.

Direct edits skip Claude entirely. Change a text value, move a box, tweak a color in the picker. Instant. Use this for anything numeric or textual that I already know the exact answer to.

Sliders are the feature I did not expect to love. When I ask Claude about a specific property, it spins up a custom slider for that property with a live preview. Ask "what if the headline was heavier?" and a font-weight slider appears. Ask about "tighter layout" and a density slider appears. The slider only exists because I asked about it. Then it disappears when the conversation moves on.

My rule after two days of use: sliders for nuance, comments for element-specific fixes, conversation for sweeping direction changes, direct edits for anything I already know the exact answer to. Switching between these four modes is what makes the iteration feel fast instead of clunky.

Step 4: Exporting and Handing Off

Four export options ship today, and picking the right one matters more than the launch materials make it sound.

Send to Canva. The best option if I plan to keep editing. Claude Design runs on Canva's Design Engine, so the export opens as a fully editable Canva file. All layers, text, and components remain editable. Plus I get access to the full 200M-asset Canva library to extend the design further. I use this for about 80 percent of outputs.

PDF. For finished work that does not need more editing. Email, Notion embeds, print-ready. The export preserves typography at vector quality, so nothing pixelates when someone zooms in.

URL. Hosted link to the live prototype. Great for stakeholder review rounds where I want comments on the design itself. No login required for whoever I send the link to.

PPTX. PowerPoint file. I use this only when a client explicitly requests it. Corporate workflows that refuse to die.

One gotcha I hit. PPTX export flattens some of the more advanced layout behavior. Responsive grid bits become static layouts on export. If the final home for the design is PowerPoint, let Claude know up front. It will prefer layouts that translate cleanly across formats instead of assuming a web target.

Bottom Line

My first real test: 15 minutes from prompt to a 10-slide pitch deck I would actually send to a client. Second try, roughly half that time. The speed is real.

But speed is not the whole story. Claude Design is strongest as a drafting tool. Start in Claude, polish in Canva, ship the final version from whichever tool fits the delivery format best. Do not treat the first Claude output as final. Treat it as a smart first pass that skips the blank canvas problem that eats so much of my day.

If you have been on the fence about AI design tools because they all produce generic output, Claude Design's design system integration changes that objection specifically. Once Claude knows my brand, everything it generates stays on-brand. That alone is worth opening Claude tonight if you are on a paid plan.

One tip before you start. Have the design system ready. A Figma file, a tokens.json, or a CSS variable set. Feeding Claude garbage gives me garbage back. Feeding it a clean brand system gives me on-brand output from the first prompt. Worth an hour of prep before the first real session.

A second tip I learned the hard way. Treat Claude Design sessions like a conversation with a new hire who is fast but needs context. Paste the project goal at the top. State the target audience. Name the platform (web, iOS, PowerPoint) so Claude picks a layout that survives the export format. When I skipped that and fired off prompts blind, the first draft was always weaker and I spent longer fixing it than I would have spent writing a proper brief. Three extra sentences of setup saves ten minutes of cleanup.

Last thing. Keep a scratchpad of prompts that worked. My best outputs came from prompts I refined over multiple sessions, not first attempts. Paste them into a notes file with the output thumbnails. Next time a similar design job comes through, start from a proven prompt and tweak from there. Claude Design rewards the same prompt library discipline that makes any LLM workflow faster over time.

Claude Design Launches: Everything You Need to Know

RAXXO Studios — Sat, 18 Apr 2026 12:42:57 +0000

Anthropic launched Claude Design on April 17, powered by Opus 4.7, turning prompts into prototypes, slides, mockups, and decks
Design system integration reads your codebase and design files, extracting tokens like colors, fonts, spacing, not logic
Four export formats ship: PDF, URL, PPTX, or push to Canva fully editable with the Canva Design Engine underneath
Research preview is live for Claude Pro, Max, Team, Enterprise, no separate price, consumes your plan's usage limits
My take: not a Figma killer, it is a draft generator you hand off to Canva or Figma to finish

Anthropic shipped Claude Design yesterday. Not a waitlist. Not a research paper. A real product that turns text prompts into prototypes, slides, pitch decks, and landing page mockups, then lets me refine them through conversation, inline comments, direct edits, and custom adjustment sliders Claude generates on the fly.

I have been poking at it for a few hours. Here is everything Claude Design does, what is happening under the hood, and who actually gets access today.

What Claude Design Actually Does

The pitch is simple. I describe what I want. Claude builds it. I refine it.

The example from the launch demo was "prototype a serene mobile meditation app, calming typography, subtle nature-inspired colors, clean layout." Claude returned a full mobile app mockup in seconds. Multiple screens with typography that was not random and a color palette that felt deliberate. From there I asked for a dark mode toggle, a different accent color, tighter spacing. Claude adjusted without starting over.

The revision model is the interesting part. I get four ways to refine a draft.

Conversation works like any Claude chat. Type what to change. "Make the headline bigger, swap the accent to warm orange, drop the testimonials row."

Inline comments let me drop a note on a specific element, the same way I would review a Google Doc. Click the button, write "this padding is too tight," Claude fixes that one element without touching the rest.

Direct edits let me change a value, move a block, or replace text without waiting for a round trip to the model. Instant.

Adjustment sliders are the part that feels new. Claude generates custom sliders for whatever I am editing in the moment. Font weights, hue shifts, corner radius, layout density. The slider only exists because I asked about that specific property. Most AI design tools give me a textbox. Claude Design gives me knobs that only appear when relevant, then disappear when the conversation moves on.

All of this runs on Opus 4.7, which shipped earlier this week with 3x the image resolution of previous Claude models. That matters here. Claude can see its own output in high fidelity, which means revision quality holds up as I iterate deeper into a design instead of collapsing into mush by iteration five.

How It Uses Your Design System

If you are a solo maker, the default output is fine. If you are a team with a brand, this is where Claude Design earns its keep.

I can hand Claude my codebase and my design files during onboarding. It reads them. It extracts design tokens: colors, fonts, spacing values, visual components. It does not read my application logic, and code beyond the token extraction is not exposed. The tokens become a system Claude applies to every future project I generate in that workspace.

That means I can ask for "a landing page for my new onboarding flow" and get a draft that already matches my brand. Colors correct. Type scale correct. Button shapes correct. Spacing grid correct. No fiddling to put the accent color back to my lime green after Claude picks purple on its own.

Onboarding is live and interactive. Claude pings me with a quick question when the extracted tokens look ambiguous. Which of these three grays is your background versus your surface color? Is this border radius intentional, or a coincidence across three components? Answering those questions once tightens every future output. I probably spent 15 minutes total on the initial setup and saved hours of correction on every draft after.

Teams can maintain multiple design systems, which matters if you work across brands or run an agency. You can refine individual components, override specific tokens, and keep governance rules (minimum font sizes, accessible contrast ratios) consistent across everything Claude builds.

This is the enterprise hook. Figma gave teams shared libraries. Claude Design gives teams shared libraries that auto-apply to AI-generated work. Different layer of the stack, same problem solved differently.

Export Options and the Canva Angle

The output ships in four formats, and this is where Anthropic got clever.

PDF covers email, Notion embeds, and anything that needs to render without software. URL gives me a hosted link to the live prototype, ideal for async feedback from stakeholders who hate installing things. PPTX is PowerPoint, because corporate workflows refuse to die. And "send to Canva" is the format that changes the strategic picture.

Claude Design is built on Canva's Design Engine and Visual Suite. When I send a file to Canva, it opens as a fully editable, collaborative design. All layers stay intact, text stays editable, and the full Canva asset library is available to extend the output. That library runs about 200 million items across stock photos, icons, fonts, and video, so the extension surface is huge.

The pattern Anthropic is betting on looks like this. Claude generates the draft. I polish in Canva. Neither product tries to own both sides of the workflow. That is why Canva's VP of AI showed up in the launch materials calling the partnership complementary rather than competitive. The deal has real mechanics behind it, not just a logo on a slide.

If you already pay for Canva Pro, this is basically a free upgrade. You get an AI drafting layer in front of tools you already know, with no extra subscription.

Who Gets Access and What It Costs

Here is the part everyone asks first.

Claude Design is rolling out as a research preview. Some features still feel rough, and Anthropic may change how they work based on what breaks in production.

Paid Claude plans get access. Pro for individuals at 20€ per month, Max for heavier individuals, Team for small orgs, Enterprise for the big checks. Free tier users do not see it. API-only customers do not see it either. This is a consumer product, not a developer endpoint.

Price is zero on top of your plan. Claude Design consumes your existing usage limits. On Pro, Claude Design shares the same message budget as regular chat. A complex design request chews through your allowance faster than a casual conversation, which is worth knowing before you burn a day prototyping.

For Team and Enterprise plans there is no per-seat upcharge. Design system onboarding, where Claude reads your codebase and files, is a one-time setup per system. Generating designs against it afterwards is normal usage.

Rollout is gradual. If you are on a paid plan and do not see Claude Design yet, Anthropic is trickling access throughout the day. Refresh claude.ai, check the sidebar, wait a few hours. It will show up.

One more detail worth flagging. The research preview label is not cosmetic. I hit a few rough edges during my testing sessions, mostly around very long prompts or designs with more than 20 elements. Claude occasionally lost track of specific tokens halfway through a revision. It recovered fine when I pointed the mistake out, but expect to proofread more carefully on longer projects until the preview flag comes off.

Bottom Line

Claude Design is not a Figma killer. I do not think Anthropic wants it to be.

What it is: a drafting tool that skips the blank canvas problem. Founders without a designer get pitch decks that do not look like homework. PMs waiting on the design team get clickable prototypes to share with stakeholders the next morning. Solo marketers can ship campaign one-pagers without ever opening Figma.

Designers still win on the finishing work. Claude spits out a draft in 30 seconds. Taking that draft from "fine" to "shipped" still requires taste and edge case judgment that humans do better.

The Canva integration is the underrated piece. It means Claude Design's output lands in a tool 170 million people already use, with collaborators they already invited. Zero context switch. That alone is why I think this product sticks while a dozen AI design tools before it did not.

Worth opening Claude tonight if you are on Pro or Max. Start with a pitch deck. See how close the first pass gets. Adjust your expectations based on real output, not launch day hype.

Claude Opus 4.6 vs 4.7: Every Difference Side by Side

RAXXO Studios — Fri, 17 Apr 2026 19:07:37 +0000

Pricing stays identical at 5 USD per million input and 25 USD per million output, 1 million token context stays, model ID changes from claude-opus-4-6 to claude-opus-4-7
Vision jumped 3x in resolution, from 1.15 megapixels to 3.75 megapixels, with 1 to 1 pixel coordinate mapping for computer use
Effort got a new xhigh slot between high and max, extended thinking budgets are gone, adaptive thinking is off by default
Sampling parameters temperature, top_p, and top_k are completely removed, the new tokenizer uses up to 35 percent more tokens on the same text
Behavior shifts are real, more literal prompts, fewer tool calls, fewer subagents, responses now scale to task complexity
Migrate today, 3 breaking changes will crash 4.6 code the moment you flip the model ID, retirement clock is already running

Anthropic shipped Claude Opus 4.7 yesterday. I have been running it against Opus 4.6 on real workloads for 24 hours, and there is enough changing under the hood that anyone still on 4.6 needs to read the migration carefully. This is the full Opus 4.6 vs 4.7 comparison, every breaking change, every behavior shift, every parameter that got renamed or deleted, and the pricing math that actually matters.

The short version. 4.7 is smarter, sees more, and calls tools less. 4.6 is being retired. If you are running production code on 4.6 today, you have maybe a quarter before you need to migrate anyway, and three of the changes will crash your app the moment you flip the model ID.

Pricing, Context, and Model Family

Start with the thing that did not change, because it sets the tone. Pricing is identical. 5 USD per million input tokens, 25 USD per million output tokens, same 1 million token context window, same availability on the Messages API, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry.

The model ID changes from claude-opus-4-6 to claude-opus-4-7. Both run under the same Opus 4 family branding. There is no long context pricing premium on either model (which matters because Gemini and GPT still charge more past certain thresholds).

On Claude Code and the Claude apps, 4.7 is now the default. 4.6 is still selectable for now, but anyone reading memory notes should also note that Anthropic already retired Opus 4 and Sonnet 4 effective June 15 this year. The cadence on model retirements is tightening. Two quarters of production life per model is the new planning horizon.

Vision: 3x Resolution and Clean Coordinates

The biggest underrated upgrade in 4.7 is what the model can actually see. Opus 4.6 accepted images up to 1,568 pixels on the long edge, roughly 1.15 megapixels. Opus 4.7 takes images up to 2,576 pixels on the long edge, roughly 3.75 megapixels. That is 3x more visual data on the same image slot.

For computer use, screenshot analysis, and document understanding, this changes what the model can actually detect. In 4.6 you had to downsample screenshots and lose small UI text. In 4.7 that text is still legible. I tested the same full resolution screenshot of a dense admin dashboard on both models. 4.6 missed three buttons and got one menu label wrong. 4.7 read every element correctly and identified the active tab from a 2 pixel indicator.

The second vision change is coordinate mapping. 4.6 returned image coordinates based on its internal downsampled view, which meant your agent code had to multiply by a scale factor to map back to the original pixel grid. 4.7 returns coordinates that match the input image directly. The math is gone. If you are building computer use agents or screen reading tools, delete the scaling logic.

The tradeoff is token cost. Higher resolution images use more tokens at the same quality setting. If you are sending images where 1.15 megapixels was already enough detail, downsample before upload or you will feel it on the bill.

Effort, Thinking, and the xhigh Slot

The effort parameter changed shape. 4.6 had four effort levels (low, medium, high, max). 4.7 has five (low, medium, high, xhigh, max). The new xhigh slot sits between high and max, giving finer control over the intelligence versus latency tradeoff.

Anthropic's own recommendation is that coding and agentic workloads should start at xhigh instead of high. In my testing on a 15 step code refactor, xhigh produced the same quality output as max but ran about 20 percent faster. High was noticeably faster but missed two edge cases that xhigh caught. The new slot is worth rewriting default configs for.

Extended thinking budgets are gone. This is the biggest breaking change. On 4.6, you could pass thinking: {"type": "enabled", "budget_tokens": 32000} to give the model a reasoning budget. That parameter shape returns a 400 error on 4.7. Only adaptive thinking is supported now, and it is off by default.


# Opus 4.6
thinking = {"type": "enabled", "budget_tokens": 32000}

# Opus 4.7
thinking = {"type": "adaptive"}
output_config = {"effort": "high"}

Adaptive thinking means the model decides how much to think based on the task. You influence the ceiling through the effort parameter instead of a token count. For most use cases this is an improvement because you stop guessing at budgets. For anyone who relied on precise control over thinking tokens, it is a real change in mental model.

Thinking content is also hidden by default on 4.7. Thinking blocks still exist in the response stream, but their content is empty unless you opt in. If your product shows reasoning to users, you need to add "display": "summarized" to the thinking config or users will see a long pause before output starts.

Sampling Parameters: Completely Removed

This one will bite anyone who copy pasted older code. Temperature, top_p, and top_k are not deprecated on 4.7. They are removed. Setting any of them to a non default value returns a 400 error.


# Opus 4.6 (works)
response = client.messages.create(
    model="claude-opus-4-6",
    temperature=0.7,
    top_p=0.9,
    messages=[...]
)

# Opus 4.7 (400 error)
response = client.messages.create(
    model="claude-opus-4-7",
    temperature=0.7,  # error
    top_p=0.9,        # error
    messages=[...]
)

The fix is to delete these parameters entirely. Anthropic's position is that sampling parameters were never a reliable tool for controlling output on Claude (unlike some other model families). If you were using temperature=0 for determinism, that never guaranteed byte identical responses anyway. Use prompting to control style, tone, and verbosity.

The tokenizer also changed. 4.7 uses a new tokenizer that produces 1.0x to 1.35x more tokens on the same text. Code heavy prompts hit the high end of that range, plain English stays near the low end. Two concrete consequences. First, your existing max_tokens values may now cut off responses earlier than they used to, so add headroom. Second, your compaction triggers (if you use them) fire earlier than expected. Use the /v1/messages/count_tokens endpoint to get accurate 4.7 counts before shipping.

Behavior Shifts You Will Notice

Not breaking, but real. 4.7 behaves differently from 4.6 even on prompts that stay identical.

More literal instruction following. 4.7 does exactly what the prompt asks and does not generalize beyond it. 4.6 would often infer requests you did not make (helpful sometimes, annoying others). If your prompts leaned on the model filling in obvious gaps, you need to be more explicit on 4.7.

Responses scale to complexity. 4.6 had a fairly fixed verbosity. 4.7 matches response length to how complex the task actually is. Simple questions get shorter answers, complex analysis gets longer responses. Net effect on my workloads is about 15 percent fewer output tokens on identical prompts, which offsets some of the tokenizer increase on input.

Fewer tool calls. 4.7 reasons more and calls tools less by default. If your agent depends on heavy tool use, raise the effort level. On 4.6 at high effort, my test agent made 11 tool calls to complete a research task. On 4.7 at high effort, it made 7 and finished with the same output.

Fewer subagents. Multi agent systems that relied on 4.6 spawning helper agents see fewer by default on 4.7. You can steer this through prompting if you want parallelism back.

Tone is more direct. 4.7 uses less validation language, fewer emojis, more opinions. If your prompt scaffolding was built to counteract 4.6's warmth, you can probably strip that.

Cybersecurity safeguards. 4.7 actively screens for prohibited security requests. Legitimate security researchers can apply to Anthropic's Cyber Verification Program for expanded access.

Task budgets are also new in 4.7 (beta). You can set a total token count for an entire agentic loop and the model sees a running countdown as it works. Minimum 20,000 tokens, advisory not hard cap, only available through the beta header task-budgets-2026-03-13. 4.6 never had this.

Bottom Line

Opus 4.7 is not a drop in replacement for 4.6. Three parameter shapes (temperature, top_p, extended thinking budgets) return errors the moment you change the model ID without updating the config. The tokenizer counts differently. The effort parameter grew a new slot. Vision grew 3x. Thinking content hides by default.

On the upside, pricing is identical, context stays at 1 million tokens, availability is the same across all four major clouds, and the model is smarter in almost every dimension that matters for production work. My migration from 4.6 to 4.7 on the raxxo.shop stack took about 40 minutes, most of which was chasing stale temperature=0 calls in old utility scripts.

If you are running any production code on claude-opus-4-6, do the migration now. Read the three breaking changes, update your configs, run your prompt regression suite, switch the model ID. The longer you wait, the more stale code accumulates that references parameters that no longer exist. And the retirement clock is already running on 4.6 whether you like it or not.

Shopify Metaobjects Killed My Headless CMS in One Saturday

RAXXO Studios — Fri, 17 Apr 2026 19:05:07 +0000

Metaobjects are native Shopify content types, free on every plan, addressable from Liquid without extra API calls
Moved 120 entries out of Contentful in 4 hours using CSV bulk import and a 40 line transform script
Three Liquid patterns handle 90 percent of use cases, loops, handle lookups, and reference field filters
Four real limits to know, custom rich text blocks, localization, drafts, and revision history
Killed a 300 EUR a month subscription and cut one service from my deploy pipeline in one Saturday

I ran a headless CMS on top of my Shopify store for almost a year. Contentful on the content side, Shopify for commerce, a thin Next.js layer pulling both together. It worked. It also cost 300 EUR a month, added two services to monitor, and meant anyone editing a testimonial had to learn a second admin. Last month I migrated everything to Shopify Metaobjects and killed the subscription. Here is exactly what I did, what broke, and why I should have done this a year ago.

What Metaobjects Actually Are

Shopify Metaobjects are custom content types that live inside the store admin. Think of them as Airtable tables, except they are native to Shopify, free on every plan, and can reference products, variants, collections, and files directly.

You define a type once (Testimonial, Team Member, FAQ, Press Mention, Case Study, whatever), set the fields (single line text, rich text, file, reference, number, date, list), and suddenly the store admin has a new section where you can create and manage entries like any other Shopify resource.

The piece most tutorials skip is that Metaobjects are addressable from Liquid directly. No GraphQL, no storefront API tokens, no separate fetch layer. You write {% for testimonial in shop.metaobjects.testimonial.values %} and loop through them in a theme template the same way you would loop through products in a collection.

For anyone who has built a headless setup, that sentence is the whole argument. A content type that behaves like a first class Shopify object, renders inside the theme, and does not require a second service. Four months ago I would have told you this was impossible without a third party app. Now it is just a dropdown in settings.

The Migration: 120 Entries, 4 Hours

My old stack had five content types in Contentful. Testimonials (34 entries), case studies (12), team members (3), press mentions (41), and FAQ entries (30). 120 rows total, all structured, all with relationships to products or collections.

Migration took four hours end to end. Most of it was the export and field mapping, not the actual work.

Step 1. Define the types in Shopify admin. Settings, Custom data, Metaobjects, Add definition. I set up each type with the same fields as Contentful, plus a few Shopify specific ones (reference to Product for case studies, reference to Collection for testimonials grouped by product line).

Step 2. Export from Contentful as JSON. Standard export, nothing fancy. I wrote a 40 line Node script to transform the JSON into Shopify's bulk import format, which is CSV for Metaobjects.

Step 3. Import via the Shopify Bulk Data Editor. You can upload CSVs of Metaobject entries the same way you upload product CSVs. One caveat. References (like linking a testimonial to a product) need the product handle or GID, not a Contentful ID, so the transform script needed a lookup step against my Shopify product export.

Step 4. Rebuild the theme blocks. Every section that previously fetched from Contentful got rewritten to use Liquid Metaobject loops. The FAQ section went from 80 lines of JS to 20 lines of Liquid. The case studies section actually got shorter because I no longer needed error handling for a third party API that could rate limit me.

Step 5. Kill the Next.js CMS layer and redirect the content routes back to Shopify pages. Three lines in the _redirects file, and the switchover was live.

Net result. One admin instead of two. One service to pay for instead of three. Editors can update testimonials in the same place where they update product descriptions, which means the last friction point for the non technical side of my team disappeared.

The Liquid Patterns That Actually Ship

There are three patterns I now use constantly. They look simple in hindsight but took me a few hours of trial and error to get right.

Pattern 1. List all entries of a type.


{% for entry in shop.metaobjects.testimonial.values %}
  > 
>     
> {{ entry.quote }}
> 
>     {{ entry.author }}, {{ entry.role }}
>   
{% endfor %}

That is the whole pattern. No fetch, no await, no error state. It runs at page render time with zero extra cost and ships whatever I put in the admin.

Pattern 2. Reference a specific entry by handle.

Useful for features like a homepage hero that pulls a single featured testimonial. I set a handle on each entry (testimonial with handle hero-quote), then reference it directly.


{% assign hero = shop.metaobjects.testimonial['hero-quote'] %}
{{ hero.quote }}

Pattern 3. Filter by a reference field.

The one that replaced the most Contentful code. Show only testimonials linked to the current product.


{% for entry in shop.metaobjects.testimonial.values %}
  {% if entry.linked_product == product %}
    > {{ entry.quote }}
  {% endif %}
{% endfor %}

That used to be a GraphQL query with variables. Now it is a Liquid if statement. For most small to mid sized stores, that is the whole gap between "needs a headless CMS" and "fine with native Shopify."

Where Metaobjects Do Not Fit (Yet)

I am not going to pretend this replaces every CMS. Four real limits caught me during migration.

Rich text with custom blocks. Shopify's rich text field is solid for paragraphs, headings, links, and basic formatting. It does not support custom embed blocks (like callouts, tables, or custom components). For long form blog posts with varied layouts I still use the Shopify blog engine, which has its own editor. For structured content with light formatting, Metaobjects cover it.

Localization. Metaobjects support translations through the Translate & Adapt app, but the setup is heavier than what Contentful offers out of the box. If you are running a multilingual store with constant content changes in six languages, this will annoy you. For English plus one or two secondary languages, it is fine.

Preview and draft states. Metaobjects do not have a draft versus published workflow the way a content platform would. You can use a visibility boolean field as a workaround, but editorial teams used to "save as draft, request review, then publish" will feel the gap.

Revision history. No built in version history on Metaobject entries. Shopify tracks the last edit but does not let you roll back to a previous version. For anything business critical, I export the JSON once a week into the same backup process I use for products. A ten line Shopify CLI script dumps all Metaobject entries to a dated file in my repo. If a junior teammate wipes a row, I can restore from yesterday's copy in under two minutes.

Bulk editing at scale. The Shopify Bulk Editor is fine for 100 entries. It becomes painful around 1,000 and unusable around 5,000. If your use case is a product catalog with 20,000 rows of structured metadata, this is not the tool. For the kind of content most stores actually store (testimonials, team, FAQs, case studies, press), you will never hit that wall.

If any of those four matter to the business, stick with a real headless CMS. If none of them are dealbreakers, the math strongly favors moving the content back inside Shopify.

Bottom Line

Headless CMS stacks made sense when Shopify's native content tools were weak. In 2026 they are not weak anymore. Metaobjects plus Metafields plus the Bulk Editor cover most of what small and mid sized stores actually need, they ship inside the theme without extra services, and they are free on every plan.

I killed a 300 EUR a month subscription, cut a Next.js service out of my deploy pipeline, gave my editors one login instead of two, and moved from "always fetching" to "rendered at build time" for 90 percent of structured content. Four hours of migration work. Lower monthly cost forever.

The headless CMS is not dead, but for Shopify stores under a few hundred products and a handful of content types, it is very hard to justify the stack tax anymore. Run the math on your current CMS bill. If it is more than 50 EUR a month and less than 500 entries of structured content, this is the migration worth spending a Saturday on.

I Tested 5 AI Image Generators Head to Head (Only 2 Shipped)

RAXXO Studios — Fri, 17 Apr 2026 19:03:12 +0000

Midjourney still wins on mood and lighting but lies about text, logos, and hand counts on packaging work
Flux 1.1 Pro on fal.ai is the typography winner at 0.04 EUR per image, 12 out of 15 tests rendered copy cleanly
Ideogram owns poster and magazine layouts, Recraft owns brand systems with native vector output
Freepik bundles 8 models in one 12 EUR a month subscription, the cheapest way to test before committing to one
Only 2 of the 5 made my production shortlist after 75 test images, beautiful is not the same as useful

I run a one person studio, which means I ship more images per week than most small agencies. After four months of swapping subscriptions and burning generation credits, I ran a head to head test on five AI image generators using the same prompts, the same product shots, and the same brand references. The goal was simple. Find out which AI image generators actually produce output I can hand to a client without spending two hours in Photoshop fixing text and hands.

Spoiler. Only two of them passed.

My test setup. I picked five contenders based on what creative directors and product teams are actually paying for in 2026. Midjourney V7, Flux 1.1 Pro on fal.ai, Ideogram 3, Freepik AI Suite (which bundles multiple models), and Recraft V3. I skipped DALL-E 3 because OpenAI quietly pushed it into the background for GPT Image, and I skipped Stable Diffusion forks because nobody is paying me to babysit a ComfyUI workflow.

Every model got the same five prompts. A moody editorial product shot for a candle. A flat lay with legible brand typography. A character portrait with readable signage in the background. A packaging mockup with three lines of copy on the label. A lifestyle scene with two people and their full hands visible.

I ran each prompt three times per model, so 15 outputs per model, 75 images total. I scored each one on four things. Visual quality, prompt adherence, text rendering, and production readiness. I did not grade on aesthetic preference. A gorgeous image with the wrong brand name on it is worthless to me.

Midjourney V7: Beautiful Liar

Midjourney still has the best taste. Lighting, composition, color grading, texture. Nothing else matches the atmosphere it produces on the first try. For a moody candle shot or an abstract brand visual where text does not matter, it is still the fastest path to something worth saving.

Then you ask it to write a word.

Out of 15 Midjourney outputs, zero had fully correct text. The packaging mockup rendered the brand name as something that looked plausible from three meters away but became abstract glyphs up close. One output put five lines of copy where I asked for three. Another decided the product name needed an extra letter that does not exist in any language.

Hands were slightly better than last year but still a liability. Two of the three lifestyle scenes had six fingered hands on at least one person. One had a hand growing out of the wrong shoulder.

I still use Midjourney, but only for mood boards, backgrounds, and texture references. The moment text, logos, or hands enter the brief, I switch tools. Paying 28€ a month for a model that cannot spell the client's name on the product I am selling is not a workflow.

Flux 1.1 Pro: The Text Winner

Flux 1.1 Pro was the surprise of the test. Running it through fal.ai at roughly 0.04 EUR per image, it produced the cleanest typography of any general purpose model. On the packaging mockup test, 12 out of 15 outputs had fully correct copy, including a three line label with proper kerning and hierarchy.

It is not as atmospheric as Midjourney. The lighting feels more even, the compositions more literal. But for commercial work where the product has to look like the actual product, Flux is the one I reach for first now.

A few practical notes from using it on real jobs. Flux renders small text reliably down to about 6 percent of the canvas height. Smaller than that and it starts hallucinating letters. Prompting the exact copy in quotes works better than describing it ("the label reads CALM TIMES" beats "a label for a candle called Calm Times"). And it responds well to technical camera language (85mm lens, shallow depth of field, soft window light) where Midjourney treats those terms more as vibes than instructions.

The weakness is character work. Faces are fine. Full body human interactions still look slightly stiff, like stock photography from 2019. For products, packaging, and flat lays it is the best tool I have tested this year.

Ideogram 3 and Recraft V3: The Specialists

Ideogram 3 has one superpower. Typography layouts. If you need a poster, a magazine cover, or a social graphic with heavy text composition, Ideogram arranges type like it has actually seen a design system. It understands grids. It understands hierarchy. It can render a three deck headline with subtle weight variation that would take me 20 minutes to set up in Figma.

Where it loses me is photography. Product shots through Ideogram look like illustrations pretending to be photos. Fine for some projects, wrong for most of mine. I keep a subscription open for typography emergencies and nothing else.

Recraft V3 is the other one that actually ships. It is built for brand work, and it shows. Vector output is native, which means I can export logos and marks as clean SVG without tracing anything. Typography is nearly as good as Flux. And the style locking feature lets me define a brand look once and generate 30 variations that all feel like the same visual system.

The cost is the limit on fine art style images. Recraft's outputs feel slightly commercial in a way that makes sense for packaging and identity work but rarely for editorial. I use it for brand systems and Flux for product photography. Together they cover most of what I actually ship.

Freepik AI Suite: The Value Play

Freepik bundled all of the above into a single subscription and priced it at 12 EUR a month for the basic plan. That includes access to Flux, Ideogram, Mystic, Google Imagen, and a handful of others through one interface, plus their existing stock library of roughly 200 million assets.

Image quality depends entirely on which underlying model you pick, so think of this less as a separate AI model and more as a buffet. The value is not the AI, it is the fact that you can test five models, download the stock photo backup, and cancel after one month if you do not like it. Compared to paying 28€ for Midjourney plus 18€ for Ideogram plus pay per image on fal.ai, the math stops being a rounding error pretty quickly.

A few honest limitations. Generation credits are capped per plan, so if you are generating 500 images a week you will blow through the starter tier by day four. The editor inside Freepik is fine for quick touch ups but not a Photoshop replacement. And image ownership rules vary slightly between the models inside the suite, so read the terms before using outputs in a commercial project.

For anyone just starting to integrate AI image generation into real work, this is the fastest way to find out which underlying model fits your workflow without spending 140€ across five subscriptions.

Bottom Line

Two tools actually made the shortlist after four months of testing. Flux 1.1 Pro for product photography and packaging. Recraft V3 for brand systems and vector work. Midjourney stays on the bench for moods and textures. Ideogram is the emergency typography tool. Freepik AI is the cheapest way to test everything before committing.

If I had to pick one tool for a full year with zero other options, it would be Flux 1.1 Pro on fal.ai. Text rendering that works, 0.04 EUR per image, and good enough general quality to cover 70 percent of commercial briefs. The other four fill the gaps, but none of them replace it on price, reliability, and output I can actually ship.

If I was starting fresh tomorrow, I would skip the individual subscriptions for the first month and run every test through Freepik to figure out what I actually need. Then buy the one or two tools that fit my work and stop paying for the rest.

The rule I landed on after 75 test images is simple. If the AI cannot spell a word, render a hand, or count fingers, it does not belong in my production stack. Beautiful is not the same as useful.

Claude Opus 4.7 Is Here: Everything That Changed

RAXXO Studios — Thu, 16 Apr 2026 15:08:48 +0000

Opus 4.7 is live now with 3x image resolution (3.75MP), new xhigh effort level, and task budgets for agentic loops
Extended thinking budgets are gone, adaptive thinking is the only option, and it is off by default
Temperature, top_p, and top_k parameters removed entirely, setting any non-default value returns a 400 error
New tokenizer uses up to 35% more tokens on the same content, update your max_tokens and compaction triggers
Pricing stays at 5 USD per million input, 25 USD per million output, available on API, Bedrock, Vertex AI, and Foundry

Anthropic just shipped Claude Opus 4.7. Not a preview or a waitlist. It's live in the Claude app right now and rolling out across the API, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry.

I've been running it for the last hour. Here's everything that changed, what breaks, and what you need to do about it today.

3x Vision Resolution

The vision upgrade is the one you'll feel immediately. Opus 4.7 accepts images up to 2,576 pixels on the long edge (roughly 3.75 megapixels). Previous Claude models maxed out at 1,568 pixels and 1.15 megapixels. That's a 3x jump.

If you're building with computer use, screenshot analysis, or document understanding, this changes what the model can actually see. Small text in UI screenshots, fine details in charts, dense tables in scanned documents. All of that was lossy before. Now the model gets the full picture.

There's also a solid quality-of-life fix: coordinate mapping is now 1:1 with actual pixels. No more scale-factor math when mapping bounding boxes or click targets. The model's coordinates match the image directly.

The tradeoff is token cost. Higher resolution images eat more tokens. If you're sending images where the extra detail doesn't matter, downsample before sending to keep costs flat.

New xhigh Effort Level

The effort parameter now has five levels instead of four. The new xhigh sits between high and max, giving you finer control over the intelligence-vs-speed tradeoff.

Anthropic recommends starting with xhigh for coding and agentic workloads. For anything where accuracy matters more than speed, use at least high. Lower effort levels make the model more literal and less exploratory, which works for structured tasks but gets risky on open-ended problems.

This only applies to the Messages API. If you're using Claude Managed Agents, effort is handled automatically.

Task Budgets (Beta)

If you're building agents, pay attention here. Task budgets give Claude an advisory token ceiling for an entire agentic loop, not just a single response.

You set a total token count. The model sees a running countdown as it works and uses it to prioritize tasks, skip low-value work, and wrap up gracefully before the budget runs out.


response = client.beta.messages.create(
    model="claude-opus-4-7",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 128000},
    },
    messages=[...],
    betas=["task-budgets-2026-03-13"],
)

Key details: minimum budget is 20,000 tokens. This is advisory, not a hard cap. The model is aware of task budgets (unlike max_tokens, which it can't see). For open-ended tasks where quality matters more than cost, skip the budget entirely. For production pipelines where you need predictable token spend, this fills a real gap.

Breaking Changes (Read This First)

Three things will break existing Opus 4.6 code if you switch to 4.7 without updating.

Extended thinking budgets are gone. If your code sets thinking: {"type": "enabled", "budget_tokens": N}, you'll get a 400 error. Adaptive thinking is now the only supported thinking mode. And here's the critical detail: adaptive thinking is OFF by default. If you were relying on extended thinking and switch to 4.7 without updating your config, the model won't think at all.

Migration:


# Before (Opus 4.6)
thinking = {"type": "enabled", "budget_tokens": 32000}

# After (Opus 4.7)
thinking = {"type": "adaptive"}
output_config = {"effort": "high"}

Sampling parameters removed. Setting temperature, top_p, or top_k to any non-default value returns a 400 error. Not deprecated. Removed. The safest fix is to delete these parameters entirely and use prompting to control output style. If you were using temperature=0 for deterministic output, it never actually guaranteed identical responses anyway.

Thinking content hidden by default. Thinking blocks still exist in the response stream, but their content is empty unless you opt in. If your product streams reasoning to users, this shows up as a long pause before output starts. One-line fix:


thinking = {
    "type": "adaptive",
    "display": "summarized",
}

The Tokenizer Change

Opus 4.7 uses a new tokenizer. Same text, more tokens. Roughly 1x to 1.35x increase depending on content type. That means the same prompt can cost up to 35% more tokens through the new model.

Update your max_tokens parameters to add headroom. Update compaction triggers if you have them. The 1M context window stays and there's no long-context pricing premium, but your existing token math is wrong if you don't account for this.

Use the /v1/messages/count_tokens endpoint to get accurate counts for 4.7.

Behavior Changes (Not Breaking, But Noticeable)

These won't crash your code but will change how the model responds:

More literal instruction following. Opus 4.7 does exactly what you ask and nothing more, especially at lower effort levels. It won't silently generalize from one example to another, and it won't infer requests you didn't make. If your prompts relied on the model reading between the lines, you'll need to be more explicit.

Responses scale to task complexity. Instead of defaulting to a fixed verbosity, the model matches its response length to how complex the task actually is. Simple question, short answer. Complex analysis, detailed response.

Fewer tool calls. The model reasons more and calls tools less by default. If your workflow depends on heavy tool use, raise the effort level.

More direct tone. Less validation language, fewer emojis, more opinionated responses. If you built prompts to counteract Opus 4.6's warmth, you can probably strip that scaffolding.

Fewer subagents. If you're building multi-agent systems, Opus 4.7 spawns fewer helper agents by default. You can steer this through prompting if you want more parallelism.

Cybersecurity safeguards. The model now actively screens for prohibited security requests. Legitimate security researchers can apply to Anthropic's Cyber Verification Program for expanded access.

Better Memory, Better Knowledge Work

Two improvements that are hard to benchmark but easy to notice in practice.

Opus 4.7 is noticeably better at maintaining and using file-system-based memory. If you have agents that write scratchpads, keep notes, or track state across turns, they should get smarter about what they write down and how they use it later. I run a file-based memory system in Claude Code daily, so this one matters to me personally.

For knowledge work, the model handles .docx redlining and .pptx editing more reliably, and it's better at programmatic chart analysis, including pixel-level data extraction from images. If your existing prompts included workarounds for these limitations ("double-check the layout before returning"), try removing them and re-testing.

Pricing and Availability

No price change. Still 5 USD per million input tokens, 25 USD per million output tokens. Available through the Claude app, the API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry. Model ID: claude-opus-4-7.

Migration Checklist

If you're moving from Opus 4.6 to 4.7, here's the short list:

Replace thinking: {"type": "enabled", "budget_tokens": N} with thinking: {"type": "adaptive"} and pair it with output_config: {"effort": "high"}.
Remove all temperature, top_p, and top_k parameters from your API calls.
Add "display": "summarized" to your thinking config if you stream reasoning to users.
Increase max_tokens by at least 35% to account for the new tokenizer.
Update compaction triggers and any token-counting logic.
Test prompts for literal interpretation. Add explicit instructions where you previously relied on the model inferring intent.
Remove any scaffolding you added to force progress updates or workaround vision limitations.
If you use computer use or screenshot workflows, test with the new 1:1 coordinate mapping and remove any scale-factor corrections.

Anthropic published a full migration guide in their docs. If you use Claude Code or the Agent SDK, the built-in Claude API skill can apply these migration steps to your codebase automatically.

What I Am Watching

Opus 4.7 is the incremental update. The leaked source code from last month revealed Mythos, a next-generation model that Anthropic called "the most capable model we have built to date." That model is currently restricted to security research partners. Opus 4.7's cybersecurity safeguards are explicitly described as "testing ground" for Mythos capabilities. The runway to broader Mythos access just got shorter.

There's also an AI design tool that generates websites and presentations from prompts, plus a Figma partnership for converting AI-generated code into editable design files. Whether those ship alongside 4.7 or in a separate launch isn't clear yet.

The model that leaked is now the model that shipped. And the model that hasn't shipped yet is the one worth watching.

Claude Code Desktop Is Now a Full Coding IDE

RAXXO Studios — Thu, 16 Apr 2026 09:01:17 +0000

Anthropic rebuilt Claude Code desktop from scratch with parallel sessions, integrated terminal, and file editor
Side chat (Cmd+;) branches questions off a running task without polluting the main session
Three view modes (Verbose, Normal, Summary) let you control exactly how much of Claude's work you see
Claude Code on the web and iOS means your coding agent travels with you
The preview pane runs local servers in-app, eliminating the tab-switching development loop

On April 14, 2026, Anthropic shipped the biggest update to Claude Code since the tool launched. Not a feature addition. Not a UI tweak. A complete architectural rebuild of the desktop application. The new Claude Code desktop is built around parallel sessions, an integrated development environment, and a workflow design that treats the AI agent as a first-class citizen rather than a chat window bolted onto a terminal.

I have been using Claude Code daily since the CLI launched. The desktop rebuild changes how I work with it.

Parallel Sessions Change the Game

The old Claude Code desktop ran one session at a time. You could have multiple windows open, but each was an isolated conversation with no unified management. The redesign replaces this with a sidebar that manages all active sessions from a single window.

This sounds like a minor UI improvement. It is not. Parallel sessions mean you can have Claude working on a frontend component in one session, debugging an API endpoint in another, and writing tests in a third. All visible at once. All running concurrently. All managed from the same interface.

The sidebar supports filtering by status, project, and environment. When you are juggling five sessions across two repos, this filtering is the difference between organized workflow and chaos. I typically run two to three sessions in parallel during a development sprint: one for the main implementation, one for edge case testing, and one as a research thread where I ask Claude questions about the codebase without contaminating the implementation context.

The drag-and-drop layout lets you arrange sessions however you want. Side by side. Stacked. One maximized with the others minimized. The layout persists between restarts, so your workspace configuration survives closing your laptop at the end of the day.

The Integrated Terminal Is Not Optional

Previous versions of Claude Code desktop relied on your external terminal. The AI would suggest commands, and you would run them in a separate window. The rebuild embeds a full terminal directly into the application.

This changes the feedback loop dramatically. When Claude suggests running a test suite, you see the output in the same window without alt-tabbing. When a build fails, the error output appears right next to Claude's analysis of what went wrong. The context switching that used to fragment every debugging session is gone.

The terminal is not just a display pane. It is a fully functional terminal emulator. You can run arbitrary commands, manage git operations, start development servers, and monitor logs. Everything that previously required a separate iTerm or Terminal window now lives inside Claude Code.

For my workflow, this collapsed three application windows (Claude Code, terminal, editor) into one. I still use VS Code for complex refactoring sessions, but for the majority of Claude-assisted development, the integrated terminal covers everything.

Side Chat Solves the Context Problem

This is the feature I did not know I needed. Side chat, triggered with Cmd+; on Mac, opens a secondary conversation that branches off the current session. The branch shares the same project context but does not feed its conversation back into the main session.

The use case is immediate. You are in the middle of a complex implementation session. Claude has built up significant context about what you are building and why. You want to ask a quick question: "What is the return type of this function?" or "Does this package support ESM?" In the old model, asking that question polluted the main session with tangential context. The AI would factor that question into its subsequent responses, sometimes drifting off course.

Side chat isolates these tangential questions. Ask whatever you need. Get the answer. Close the side chat. The main session never sees it. Claude's understanding of your implementation task remains clean and focused.

I use side chat constantly now. Quick API lookups. Package compatibility questions. "How does this existing function work?" queries that inform my next instruction to the main session. It is like having a reference desk next to your workbench.

Three View Modes for Different Contexts

The redesign introduces three view modes: Verbose, Normal, and Summary.

Verbose shows everything. Every tool call, every file read, every command execution, every reasoning step. This is useful when you need to understand exactly what Claude is doing, either for debugging or for learning from its approach.

Normal is the default. It shows key actions and results without the granular detail. You see that Claude edited a file and what changed, but not the intermediate steps it took to decide what to change.

Summary is the mode I use most. It shows only the outcomes: what files were created or modified, what commands were run and whether they succeeded, and any questions Claude has for you. Everything else is collapsed. When Claude is working on a task you have already aligned on, Summary mode lets you monitor progress without drowning in detail.

The ability to switch modes mid-session is what makes this useful. I typically start a new task in Normal mode while I am actively collaborating with Claude, then switch to Summary once the plan is clear and Claude is executing. If something goes wrong, I switch to Verbose to diagnose.

SSH Support on Mac (Finally)

Remote development sessions now work natively on Mac. You can connect Claude Code to a remote server via SSH and work on a remote codebase with the same capabilities as local development.

This was possible before through terminal workarounds, but native support means Claude Code handles connection management, reconnection on network interruptions, and file synchronization. For anyone working with remote development environments (staging servers, cloud VMs, GPU instances), this removes a significant friction point.

Claude Code on the Web and iOS

The desktop rebuild coincides with Claude Code becoming available in a browser at claude.ai/code. Connect a GitHub repo, describe a task, and Claude works in an isolated cloud environment. Multiple tasks run in parallel across different repos, each producing its own pull request.

The web version is not a watered-down experience. It has real-time progress indicators, file browsing, diff views, and the same model powering the desktop app. The limitation is that it runs in Anthropic's cloud rather than your local machine, so tasks that require local dependencies or private infrastructure still need the desktop app.

The iOS experience is the unexpected entry. You can start a coding task from your phone, let Claude work on it while you are away from your desk, and review the results later. I have used this exactly once (fixing a typo in production while on the U-Bahn) and it worked. Not a daily driver, but knowing the option exists changes how I think about response time for urgent fixes.

What This Actually Means for Daily Work

The desktop rebuild is not about any single feature. It is about the interaction model.

Before this update, Claude Code was a very capable tool that you used through a chat interface. You told it what to do. It did it. You reviewed the result. The new desktop app treats Claude Code as an environment rather than a tool. You do not launch it to accomplish a specific task and then close it. You open it at the start of your workday and it stays open, managing multiple workstreams, surfacing progress, and waiting for the next instruction.

The parallel sessions, integrated terminal, file editor, and preview pane combine to create something that looks a lot like an IDE. But unlike a traditional IDE where the developer writes every line, this IDE has a collaborator built in. One that reads the whole codebase, remembers the conversation history, and executes multi-file changes autonomously.

For the solo developer running a one-person studio, this changes the math on what is achievable in a day. I used to cap my active projects at two or three because context switching between codebases took real time. With parallel sessions, each maintaining its own project context, I can move between projects without losing state. Claude remembers where each project left off. I just need to decide which one to push forward next.

The rebuild is available now for Pro, Max, Team, and Enterprise plans. If you have been using the CLI exclusively, try the desktop app this week. The parallel session management alone is worth the switch. The integrated terminal and side chat make it hard to go back.

Vibe Coding Just Graduated From Joke to Job Title

RAXXO Studios — Thu, 16 Apr 2026 08:59:13 +0000

Vibe coding went from Karpathy's joke tweet to a legitimate development methodology in 14 months
Claude Code built Anthropic's own Cowork app from scratch in under two weeks
Anthropic's new AI design tool generates full websites and presentations from a single prompt
Claude Builder combines templates, live previews, and deployment in one full-stack interface
The barrier between "I have an idea" and "it's live" has never been thinner

In February 2025, Andrej Karpathy posted a half-serious tweet about "vibe coding," describing an approach where you give in completely to the AI, accept every suggestion, and let the vibes carry the project. Fourteen months later, Anthropic has turned that joke into a product strategy worth billions. The company that builds Claude is not just embracing vibe coding. It is defining what the next version of it looks like.

This is the story of how a meme became a methodology.

From Tweet to Product Philosophy

Karpathy's original description was intentionally provocative. He talked about writing code by describing what he wanted, accepting all AI suggestions without reading them carefully, and running the result to see what happens. It was a thought experiment about trust and delegation. The AI community treated it as either a terrifying glimpse of the future or the funniest thing they had read all week.

Then Claude Code shipped. And suddenly vibe coding was not a joke anymore.

Claude Code changed the dynamic by giving the AI full access to the filesystem, terminal, and git history. Instead of autocompleting lines inside an editor, Claude Code operates at the project level. You describe what you want built. It reads your codebase, plans the changes, writes the code, runs the tests, debugs the failures, and commits the result. The entire loop happens without you touching a keyboard.

I started using this workflow for prototyping about six months ago. The first time I described a feature in plain English and watched Claude Code implement it across four files, run the tests, and push a clean commit, I understood why Karpathy's tweet resonated. It was not about being lazy. It was about operating at a higher level of abstraction.

Claude Code Wrote Its Own Companion App

The proof that vibe coding works at production scale came from inside Anthropic. In January 2026, the company launched Cowork, a collaborative workspace feature built on top of Claude Code. The remarkable part: Claude Code wrote all of it.

According to Anthropic's own team, the entire Cowork application was designed, implemented, and tested by Claude Code in under two weeks. Not a prototype. Not a demo. A shipping product used by thousands of people daily.

This matters because it answers the loudest criticism of vibe coding: that it only works for toy projects. Cowork is a real application with real users, real authentication, real-time collaboration, and real production infrastructure. Claude Code built it from a set of natural language descriptions, iterating through feedback loops until the implementation matched the spec.

The speed is the other headline. Two weeks from concept to shipped product. Not because corners were cut, but because the iteration cycle collapsed. Describe a feature. Watch it get built. Test it. Give feedback. Watch the fix land. That loop, which traditionally takes days of human development time per cycle, now takes minutes.

The Design Tool That Changes Everything

On April 14, 2026, Anthropic revealed something that extends vibe coding beyond code. A new AI design tool that generates complete websites and presentation decks from natural language prompts. You describe what you want. It builds the page with layout, content, styling, and responsive behavior included.

This is not another "AI website builder" that spits out generic templates. The tool combines content creation, visual design, and technical implementation in a single workflow. It understands design principles like hierarchy, spacing, and contrast. It generates production-ready code, not wireframes or mockups.

For someone who has spent 20 years in visual design, I have strong opinions about AI design tools. Most of them produce output that looks like it was designed by a committee that has never shipped a real product. The early reports on Anthropic's tool suggest it is different. It draws on Claude's understanding of design patterns, accessibility standards, and responsive behavior to produce output that actually works.

The strategic move here is clear. Anthropic is not competing with Figma on design fidelity. It is competing with the entire workflow. Why design in one tool, prototype in another, implement in a third, and deploy through a fourth when a single conversation can handle all of it?

Claude Builder: Full-Stack in One Interface

Alongside the design tool, Anthropic introduced Claude Builder, an interface for creating full-stack applications with templates, real-time previews, and integrated security measures.

This puts Anthropic in direct competition with tools like Lovable, Bolt, and Vercel's v0. The difference is that Claude Builder is backed by the same model powering Claude Code, which means it inherits all the reasoning capability and codebase awareness that makes Claude Code effective.

The template system provides starting points for common application types. E-commerce storefronts. SaaS dashboards. Marketing sites. Portfolio pages. But the templates are starting points, not ceilings. You can describe modifications in natural language and watch the preview update in real time.

Security is baked in rather than bolted on. The builder scans generated code for common vulnerabilities, validates input handling, and enforces secure defaults. This addresses one of the legitimate concerns about vibe coding: when you are not reading every line of code, who is checking for SQL injection or XSS? Claude Builder answers that by making security review part of the generation process.

The preview pane deserves its own mention. It runs a local development server directly in the interface, so you see exactly what users will see. No context switching. No deploy-and-check cycles. The feedback loop between "I want this to look different" and "it now looks different" is measured in seconds.

What This Means for Solo Creators

I run a one-person studio. Every hour spent on implementation is an hour not spent on creative direction, marketing, or product strategy. The vibe coding evolution hits differently when you are the entire team.

Before Claude Code, launching a new product meant days of development work even for simple projects. Now my workflow looks like this: describe the product, let Claude Code build the first version, review and refine through conversation, deploy. A product that used to take a week ships in an afternoon.

The design tool accelerates this further. Landing pages that used to require jumping between Figma, VS Code, and a browser can now happen in a single session. Describe the page. Review the output. Adjust. Ship. The overhead is not zero, but it is close to zero.

This is not about replacing skill. I still make design decisions, write copy, and define the product vision. The difference is that execution no longer bottlenecks the creative process. The gap between "I have an idea" and "it's live on the internet" went from days to hours.

The Part Nobody Is Talking About

Vibe coding's real disruption is not speed. It is accessibility.

A marketing manager who can describe a landing page in plain English can now ship it without filing a Jira ticket. A designer who can articulate interaction patterns can now build the prototype without learning React. A product manager who can write a spec can now see it implemented before the standup ends.

The skills that matter are shifting. Knowing how to write a for loop matters less. Knowing what to build and why matters more. Taste, judgment, product sense. These are the skills that vibe coding amplifies rather than replaces.

Anthropic understands this. The design tool, Claude Builder, and Claude Code are not three separate products. They are one continuous workflow that takes you from idea to implementation to deployment without requiring you to switch contexts or learn new tools.

Karpathy posted that tweet 14 months ago. Today, Anthropic is shipping the infrastructure that makes it real. Vibe coding graduated from meme to methodology. And the class of 2026 is already building with it.

512,000 Lines of Leaked Code Exposed Anthropic's Secret Models

RAXXO Studios — Thu, 16 Apr 2026 08:57:11 +0000

A missing .npmignore exposed 512,000 lines of Claude Code's internal TypeScript source
Leaked codenames include Mythos (next-gen model), Capybara (new tier above Opus), and KAIROS (always-on background agent)
Opus 4.7 and Sonnet 4.8 are incremental updates, Mythos is the real generational leap
Anthropic confirmed Mythos exists and called it "the most capable model we've built to date"
An AI design tool and Claude Builder for full-stack app creation could drop alongside Opus 4.7 this week

Someone at Anthropic forgot to add two characters to a config file. Those two characters were *.map in a .npmignore. The result was the largest accidental source code exposure in AI history. On March 31, 2026, version 2.1.88 of the Claude Code npm package shipped with full source maps intact, dumping 512,000 lines of internal TypeScript across 1,906 files into the public registry. Within hours, the entire codebase was archived on GitHub and dissected by thousands of developers.

This is the story of what they found, why it matters, and what it tells us about where Anthropic is headed.

The Leak Nobody Saw Coming

The root cause was almost comically simple. Bun, the JavaScript runtime Anthropic uses to build Claude Code, generates source maps by default during compilation. Source maps are debug files that map compiled code back to original source. They are useful in development and catastrophic in production when they contain your entire proprietary codebase.

Standard practice is to exclude these files from published packages using .npmignore. Someone on the Claude Code team missed that step. The .map file went out with the package, and suddenly every npm install @anthropic-ai/claude-code came bundled with the full source tree.

The timing made it worse. Just five days earlier, on March 26, roughly 3,000 internal documents had leaked through what appeared to be a CMS misconfiguration. Those files referenced an unreleased model codenamed Mythos and described it as a restricted security research tool. Then the npm leak dropped and confirmed everything the CMS files hinted at, plus a lot more.

What the Source Code Revealed

The 512,000 lines contained version strings, feature flags, internal architecture, and codenames that paint a clear picture of Anthropic's roadmap.

44 hidden feature flags. These control unreleased capabilities that are already built but not yet exposed to users. The flags suggest features ranging from enhanced memory systems to new collaboration modes.

Model codenames. The source referenced several internal model names: Fennec (the current Opus 4.6), Numbat (an unreleased model), and most notably, Capybara. Capybara appears to be a new model family sitting above the current Opus tier. Cross-referencing with the earlier CMS leak, Capybara is almost certainly the model Anthropic internally calls Mythos.

KAIROS. This was the most surprising find. KAIROS is an always-on background agent embedded directly into Claude Code. According to the source, it runs persistent monitoring tasks, tracks context across sessions, and performs maintenance operations without explicit user commands. The name suggests it handles time-sensitive operations (kairos is Greek for "the opportune moment"). Whether KAIROS is active in current builds or gated behind a feature flag remains unclear.

Stealth mode. The source included a mechanism designed to hide Anthropic employee contributions to open-source projects. The feature masks authorship metadata so that commits from Anthropic engineers appear to come from generic accounts. This raised eyebrows in the open-source community, though Anthropic has not commented on its purpose.

Mythos vs. Opus 4.7: Two Very Different Things

The most common misunderstanding in coverage of these leaks is conflating Opus 4.7 with Mythos. They are not the same thing.

Opus 4.7 is the next incremental update within the existing Claude 4.x model family. Anthropic has been shipping these roughly every three to four months. Opus 4.5 arrived last November, Opus 4.6 in early February 2026, and Opus 4.7 is expected this week. These are version bumps. Better benchmarks, improved reasoning, faster inference. Important, but evolutionary.

Mythos is something else entirely. Anthropic's own description, confirmed through the leaked documents and a preview page on their security research portal, calls it "a step change and the most capable model we have built to date." Mythos is not a point release. It is a generational leap, the kind of model that redefines what the system can do.

The leaked source also references Sonnet 4.8, which follows the same incremental pattern as the Opus line. So the picture looks like this: the 4.x family continues to evolve with regular updates (Opus 4.7, Sonnet 4.8), while Mythos represents a parallel track, a next-generation architecture being developed and tested separately.

Currently, Mythos access is restricted to select security research partners. Anthropic is using it for vulnerability research, including zero-day discovery. Twelve founding partners reportedly have access. This limited rollout suggests the model is powerful enough that Anthropic wants to understand its risk profile before wider release.

The Design Tool Nobody Expected

Alongside Opus 4.7, Anthropic is preparing an AI design tool that generates complete websites and presentation decks from natural language prompts. This is not a minor feature addition. It signals Anthropic's move beyond chat and code into full-stack creative production.

The tool reportedly combines content creation, visual design, and technical implementation in a single workflow. You describe what you want. It builds the page, writes the copy, handles the styling, and outputs production-ready code.

A separate feature called Claude Builder takes this further. It provides a template-based interface for creating full-stack applications with real-time previews, integrated security measures, and deployment tooling. Think of it as Lovable or Bolt, but backed by the same model that powers Claude Code.

Anthropic has also partnered with Figma to convert AI-generated code back into editable design files and integrated Claude into Microsoft Word and PowerPoint. The strategy is clear: Anthropic is not just building a chatbot or a coding assistant. It is building an end-to-end creative and technical production platform.

What This Means for Developers

The practical takeaway splits into short-term and long-term.

Short-term: Opus 4.7 drops this week. If you are on Claude Code, expect better reasoning, faster responses, and likely some of those 44 feature flags getting switched on. The model upgrade will be automatic for API users and Claude Code subscribers. Watch for the design tool launch alongside it.

Long-term: Mythos changes the calculus. A model that Anthropic describes as a step change, powerful enough to discover zero-day vulnerabilities, is going to reshape expectations for what AI systems can do autonomously. When Mythos eventually gets broader access, the gap between "AI assistant" and "AI colleague" gets a lot smaller.

The KAIROS revelation is equally significant. An always-on background agent means Claude Code is not just responding to your commands. It is actively monitoring, maintaining, and optimizing your workflow in the background. If this feature ships publicly (and the source code suggests it will), the interaction model for AI coding tools changes fundamentally. You stop telling it what to do and start collaborating with something that already knows what needs doing.

The Irony

The biggest AI coding company in the world got caught by a missing line in a config file. The same tool that helps thousands of developers catch exactly this kind of mistake shipped with the mistake itself. Anthropic's response was swift: they pulled the affected package version within hours and issued a security advisory. But the code was already archived, forked, and analyzed.

There is a lesson here that goes beyond Anthropic. Source maps, build artifacts, debug logs. These are the things that slip through when shipping velocity outpaces operational hygiene. It happens to everyone. It just happened to happen to the company whose product is literally designed to prevent it.

The leak was embarrassing. What it revealed was fascinating. And what comes next, Opus 4.7 this week, Mythos on the horizon, a design tool that turns prompts into products, that is the part worth paying attention to.

Claude Opus 4 and Sonnet 4 Retire June 15

RAXXO Studios — Wed, 15 Apr 2026 18:34:26 +0000

Anthropic deprecated claude-opus-4 and claude-sonnet-4 on April 14 with retirement set for June 15
Both models get replaced by their 4.6 versions with 1M context, adaptive thinking, and higher output limits
Opus 4.6 supports 128K max output tokens versus Opus 4's 32K, and 1M context is included at standard pricing
Sonnet 4.6 scores 79.6% on SWE-bench Verified, nearly matching Opus at 80.8% for most coding tasks
The biggest API change is adaptive thinking replacing manual budget_tokens, which requires code updates

On April 14, Anthropic officially deprecated Claude Opus 4 and Claude Sonnet 4. Both models retire on June 15, 2026. After that date, every API request using claude-opus-4-20250514 or claude-sonnet-4-20250514 returns an error. No fallback. No grace period.

If you have production systems running on either model, you have exactly 60 days to migrate. Here is what changes, what breaks, and how to handle the transition without downtime.

What Is Being Deprecated

Two specific model IDs are affected:

| Model | Status | Retirement Date |

|-------|--------|----------------|

| claude-opus-4-20250514 | Deprecated | June 15, 2026 |

| claude-sonnet-4-20250514 | Deprecated | June 15, 2026 |

The replacements are claude-opus-4-6 and claude-sonnet-4-6, both released in February 2026. These are not aliases or minor updates. They are different model generations with different capabilities, different defaults, and at least one breaking API change.

What You Gain by Migrating

The 4.6 models are not just newer. They are substantially better across every metric that matters for production work.

1M Context Window at Standard Pricing. Opus 4 and Sonnet 4 required a beta header and long-context pricing to use the 1M token context window. The 4.6 versions include it at standard pricing with no beta header. Requests over 200K tokens just work.

Higher Output Limits. Opus 4.6 supports 128K max output tokens, up from Opus 4's 32K. Sonnet 4.6 supports 64K. For code generation, long-form content, and structured data extraction, this is a 4x improvement on Opus and a 2x improvement on Sonnet.

Adaptive Thinking. Both 4.6 models recommend adaptive thinking (thinking: {type: "adaptive"}), where Claude dynamically decides when and how deeply to think. This replaces the manual budget_tokens approach from Opus 4, which required you to guess how many tokens Claude needed for reasoning.

Better Benchmarks. Sonnet 4.6 scores 79.6% on SWE-bench Verified. Opus 4.6 scores 80.8%. For most coding tasks, the gap between the two is negligible. Both outperform their predecessors by significant margins.

300K Batch Output. The Message Batches API now supports up to 300K output tokens for both 4.6 models with the output-300k-2026-03-24 beta header. Long-form generation at batch pricing makes large-scale content and data processing dramatically cheaper.

What Breaks When You Switch

Not everything is a drop-in replacement. Three changes require code modifications.

Adaptive Thinking Replaces budget_tokens

If you use extended thinking with Opus 4 and set budget_tokens manually, that parameter is deprecated on Opus 4.6. The recommended approach is:


# Old (Opus 4)
response = client.messages.create(
    model="claude-opus-4-20250514",
    thinking={"type": "enabled", "budget_tokens": 8192},
    max_tokens=4096,
    messages=[{"role": "user", "content": "Analyze this code."}]
)

# New (Opus 4.6)
response = client.messages.create(
    model="claude-opus-4-6",
    thinking={"type": "adaptive"},
    max_tokens=4096,
    messages=[{"role": "user", "content": "Analyze this code."}]
)

Adaptive thinking means Claude decides whether to think and how much. For most workloads, this produces better results with fewer wasted tokens. But if you relied on precise control over thinking budget for cost management, you need to adjust your approach.

The effort parameter (effort: "low" | "medium" | "high") is now the recommended way to control thinking depth instead of raw token budgets.

No Assistant Message Prefilling

Opus 4.6 does not support prefilling assistant messages. If your application starts Claude's response with specific text to guide the output format, this will not work with Opus 4.6. You need to move that guidance into the system prompt or user message instead.

Sonnet 4.6 still supports prefilling, so this only affects Opus migrations.

output_format Moved to output_config.format

If you use structured outputs, the parameter location changed:


# Old
response = client.messages.create(
    output_format={"type": "json", "schema": my_schema},
    ...
)

# New
response = client.messages.create(
    output_config={"format": {"type": "json", "schema": my_schema}},
    ...
)

The old location still works during a transition period, but updating now prevents issues later.

Migration Checklist

Here is a step-by-step plan for migrating without production incidents.

Week 1: Audit. Find every place your codebase references the old model IDs. Check environment variables, configuration files, CI/CD pipelines, and any hardcoded strings. The Console Usage page has an Export button that shows usage broken down by model, which catches references you might miss in code.


# Quick grep for old model references
grep -r "claude-opus-4-20250514\|claude-sonnet-4-20250514" .
grep -r "claude-opus-4\b\|claude-sonnet-4\b" . --include="*.py" --include="*.ts" --include="*.yaml"

Week 2: Test. Run your evaluation suite against the 4.6 models in a staging environment. Pay attention to:

Output format consistency (especially if you parse structured responses)
Thinking token usage (adaptive vs. fixed budget)
Any prefilled assistant message patterns
Cost per request (4.6 models may use tokens differently)

Week 3: Gradual Rollout. Switch non-critical paths first. Internal tools, development environments, batch processing jobs. Monitor for regressions before touching customer-facing systems.

Week 4: Production. Update production model references. Keep the old model ID in a commented-out fallback for one week in case you need to diagnose issues by comparing outputs.

Before June 1: Clean Up. Remove all references to deprecated model IDs. Update documentation. Notify downstream consumers if you expose model selection to users.

Cost Implications

Pricing between the generations is identical for standard requests:

| Model | Input (per 1M tokens) | Output (per 1M tokens) |

|-------|----------------------|----------------------|

| Opus 4.6 | 15 USD | 75 USD |

| Sonnet 4.6 | 3 USD | 15 USD |

The cost difference comes from behavior changes. Adaptive thinking may use more or fewer thinking tokens depending on task complexity. If you had a tight budget_tokens cap that kept Opus 4 costs predictable, adaptive thinking might increase costs on complex tasks while decreasing them on simple ones.

Monitor your usage closely during the first week after migration. The Console Usage page shows token breakdowns that help you spot unexpected changes.

The 1M context window moving to standard pricing is a net cost reduction for anyone who was paying the long-context premium. If you were using the beta header with Sonnet 4 or Sonnet 4.5 for 1M context, switching to Sonnet 4.6 eliminates that surcharge.

The Bigger Pattern

This is the sixth deprecation cycle Anthropic has run since September 2024. The cadence is clear: new models launch, old models get 60 days notice, then they shut down. Anthropic has published a commitment to long-term preservation of model weights, but operational API access ends on the retirement date.

For production systems, this means model migration is not a one-time task. It is a recurring maintenance item. The teams that handle it best are the ones who abstract their model selection behind a configuration layer rather than hardcoding model IDs throughout the codebase.


# config.py
CLAUDE_MODEL = os.environ.get("CLAUDE_MODEL", "claude-sonnet-4-6")
CLAUDE_REASONING_MODEL = os.environ.get("CLAUDE_REASONING_MODEL", "claude-opus-4-6")

One environment variable change instead of a codebase-wide find-and-replace. This is not over-engineering. It is preparation for the next deprecation cycle, which will come in roughly 6 months based on Anthropic's current pace.

Also Retiring: 1M Context for Older Sonnet Models

A related change that is easy to miss: the 1M token context window beta for Claude Sonnet 4.5 and Claude Sonnet 4 retires on April 30, 2026. After that date, the context-1m-2025-08-07 beta header will have no effect on these models. Requests exceeding 200K tokens will return an error.

If you rely on long-context processing with Sonnet 4 or Sonnet 4.5, you need to migrate to Sonnet 4.6 before April 30, not June 15. That is two weeks away, not two months.

Sonnet 4.6 includes 1M context at standard pricing with no beta header. This is actually a better deal than the previous arrangement, where long-context requests incurred premium pricing. The migration removes a cost surcharge while giving you a more capable model.

Haiku 3 Is Also on the Clock

While the headline is Opus 4 and Sonnet 4, Claude Haiku 3 (claude-3-haiku-20240307) is deprecated with retirement on April 20, 2026. That is 5 days from now. If you have any systems still running Haiku 3, that migration is more urgent than the June 15 deadline.

The replacement is Haiku 4.5 (claude-haiku-4-5-20251001), which is faster, more capable, and priced comparably. The upgrade path is a model ID swap with no API changes.

Timeline

| Date | Event |

|------|-------|

| April 14, 2026 | Opus 4 and Sonnet 4 deprecation announced |

| April 20, 2026 | Haiku 3 retired (API requests fail) |

| April 30, 2026 | 1M context beta ends for Sonnet 4 and 4.5 |

| June 1, 2026 | Recommended migration deadline for Opus 4 and Sonnet 4 |

| June 15, 2026 | Opus 4 and Sonnet 4 retired (API requests fail) |

The clock is running. Haiku 3 users have days, not weeks. Sonnet long-context users have two weeks. Opus 4 and Sonnet 4 users have two months. Regardless of which bucket you fall into, start your audit this week. The migration is straightforward for most applications, but testing takes time. Do not wait until the deadline.

The ant CLI Puts the Full Claude API in Your Terminal

RAXXO Studios — Wed, 15 Apr 2026 18:32:25 +0000

ant is Anthropic's official CLI that replaces curl and hand-written JSON for Claude API work
Build requests from typed flags or piped YAML, inline files with @path references
Version-control agents, environments, and skills as YAML files checked into your repo
Claude Code understands ant natively, so you can ask it to manage API resources directly
Interactive explorer TUI for browsing responses, auto-pagination, and GJSON transforms

Every developer who has built with the Claude API knows the ritual. Open a terminal. Write a curl command. Manually escape JSON. Forget a comma. Fix the JSON. Run it again. Parse the response with jq. Repeat until the prototype works.

Anthropic just ended that loop. On April 8, they launched the ant CLI, a purpose-built command-line client for the Claude API that replaces curl, hand-written JSON, and the collection of shell scripts most of us have accumulated.

What ant Actually Does

ant is a single binary that exposes every Claude API resource as a subcommand. Messages, models, agents, sessions, files, skills, environments. If the API has an endpoint, ant has a command for it.

The simplest example sends a message to Claude:


ant messages create \
  --model claude-opus-4-6 \
  --max-tokens 1024 \
  --message '{role: user, content: "Hello, Claude"}'

Notice the YAML-like syntax for the message flag. No strict JSON required. Keys do not need quotes. Strings do not need quotes unless they contain special characters. This alone saves significant friction when working from the terminal.

The response comes back as formatted JSON when you are in an interactive terminal, or compact JSON when piped to another command. No extra formatting flags needed for the common cases.

Why This Beats curl

Three things make ant better than curl for Claude API work.

Typed flags replace raw JSON. Instead of constructing a JSON body and praying you did not miss a bracket, you use named flags. Scalar fields map directly to flags. Structured fields accept the relaxed YAML syntax. Repeatable flags build arrays automatically. Each --tool flag appends one tool to the array.


ant beta:agents create \
  --name "Research Agent" \
  --model '{id: claude-opus-4-6}' \
  --tool '{type: agent_toolset_20260401}' \
  --tool '{type: custom, name: search, input_schema: {type: object}}'

File inlining with @path. Want to send a PDF to Claude? Prefix the path with @. The CLI detects the file type and handles encoding automatically. Binary files get base64-encoded. Text files get inlined as strings. No manual base64 piping.


ant messages create \
  --model claude-opus-4-6 \
  --max-tokens 1024 \
  --message '{role: user, content: [
    {type: document, source: {type: base64, media_type: application/pdf, data: "@./report.pdf"}},
    {type: text, text: "Summarize this report."}
  ]}'

Built-in response filtering. The --transform flag uses GJSON paths to extract exactly what you need from responses. No jq dependency. No separate parsing step.


ant beta:agents list \
  --transform "{id,name,model}" \
  --format jsonl

This outputs one JSON object per line with only the fields you asked for. Clean, pipeable, ready for scripts.

The Interactive Explorer

For debugging or exploration, --format explore opens a terminal UI for browsing large responses. Arrow keys expand and collapse nodes. Slash searches within the response. Q exits. It is the kind of feature you did not know you needed until you are staring at a 500-line agent configuration and trying to find one specific field.


ant models list --format explore

Auto-pagination handles list endpoints transparently. You get all results without managing page tokens or cursor parameters. Each item streams individually, so you can pipe into head or grep without waiting for the full response.

Version-Controlling API Resources

This is where ant becomes more than a convenience tool and turns into an infrastructure management layer.

Agents, environments, skills, and deployments can be defined as YAML files in your repository. You create the resource by piping the file to ant, update it the same way, and track changes through git.

Here is a complete workflow:


# summarizer.agent.yaml
name: Summarizer
model: claude-sonnet-4-6
system: |
  You are a helpful assistant that writes concise summaries.
tools:
  - type: agent_toolset_20260401

Create it:


ant beta:agents create < summarizer.agent.yaml

Update it after making changes:


ant beta:agents update \
  --agent-id agent_011CYm1BLqPX... \
  --version 1 \
  < summarizer.agent.yaml

This pattern means your AI infrastructure lives in the same repo as your application code. Same review process. Same CI pipeline. Same git history. No more "who changed the agent prompt last Thursday" mysteries.

Environments work the same way:


# summarizer.environment.yaml
name: summarizer-env
config:
  type: cloud
  networking:
    type: unrestricted

Define once, create via CLI, update through git-tracked YAML files. Infrastructure as code for your AI agents.

Claude Code Integration

Here is the detail that makes ant different from a generic API client: Claude Code understands it natively. You can ask Claude Code to manage API resources, and it will shell out to ant, parse the structured output, and reason over the results.

No custom integration code. No wrapper scripts. No teaching Claude Code how to use your API client. It already knows.

Practical examples of what you can ask Claude Code to do through ant:

"List my recent agent sessions and summarize which ones errored."
"Upload every PDF in ./reports to the Files API and print the resulting IDs."
"Pull the events for this session and tell me where the agent got stuck."

This is automation that composes. ant gives you the building blocks. Claude Code gives you the reasoning layer on top.

Installation

Three options, all straightforward:

Homebrew (macOS):


brew install anthropics/tap/ant
xattr -d com.apple.quarantine "$(brew --prefix)/bin/ant"

curl (Linux/WSL):


VERSION=1.0.0
OS=$(uname -s | tr '[:upper:]' '[:lower:]')
ARCH=$(uname -m | sed -e 's/x86_64/amd64/' -e 's/aarch64/arm64/')
curl -fsSL "https://github.com/anthropics/anthropic-cli/releases/download/v${VERSION}/ant_${VERSION}_${OS}_${ARCH}.tar.gz" \
  | sudo tar -xz -C /usr/local/bin ant

Go (from source):


go install github.com/anthropics/anthropic-cli/cmd/ant@latest

Authentication reads from the ANTHROPIC_API_KEY environment variable. Set it once, use it everywhere.

Shell Completion

ant ships completion scripts for bash, zsh, fish, and PowerShell. For zsh:


ant @completion zsh > "${fpath[1]}/_ant"

Tab completion on API resource names and flags is the kind of quality-of-life improvement that separates a tool you tolerate from a tool you reach for instinctively.

Debugging

The --debug flag prints the full HTTP request and response to stderr, with API keys redacted. When something is not working, you see exactly what went over the wire without adding verbose logging to your code.


ant --debug beta:agents list

This shows headers, body, status codes. Everything you need to diagnose authentication issues, malformed requests, or unexpected responses.

Beta Resources Under the beta: Prefix

Resources still in beta, including agents, sessions, deployments, environments, and skills, live under the beta: prefix. Commands in this namespace automatically send the appropriate anthropic-beta header, so you never need to pass it manually.


ant beta:agents list
ant beta:sessions create --agent agent_011CYm1BLqPX...
ant beta:sessions:events list --session-id session_01JZCh78...

This is a thoughtful design choice. Beta resources are clearly namespaced. When they graduate to stable, the prefix drops and your scripts need a one-line change. No hidden header management, no accidental mixing of stable and beta endpoints.

Scripting Patterns

ant is built to compose with standard shell tools. The --transform id --format yaml pattern on list endpoints emits one bare ID per line, so head, tail, xargs, and while loops work naturally.

Chain commands together:


FIRST_AGENT=$(ant beta:agents list \
  --transform id --format yaml | head -1)

ant beta:agents:versions list \
  --agent-id "$FIRST_AGENT" \
  --transform "{version,created_at}" --format jsonl

Error handling uses --transform-error and --format-error flags that mirror the success-path counterparts:


ant beta:agents retrieve --agent-id bogus \
  --transform-error error.message --format-error yaml 2>&1

This means you can build robust shell scripts that handle both success and failure paths without wrapping everything in try-catch equivalents or parsing stderr manually.

Who Should Use This

If you interact with the Claude API from the terminal more than once a week, install ant. The time saved on JSON construction alone pays for the 30-second installation.

If you manage agents, skills, or environments through the API, the YAML version-control pattern is reason enough. Tracking AI infrastructure in git is not optional for serious production work. When your agent's behavior changes, you should be able to git blame the YAML file and see exactly who changed what and when.

If you use Claude Code as your primary development environment, ant adds capabilities that were previously impossible without custom scripts. The native integration means you can treat the Claude API as a first-class resource in your development workflow.

I have been using ant since it launched and the difference in my daily workflow is noticeable. Checking model availability, listing agent sessions, uploading files to the API. Tasks that used to require opening documentation, copying curl examples, and adjusting JSON now take a single command. That friction reduction compounds fast when you interact with the API multiple times per day.

The CLI is open source on GitHub at anthropics/anthropic-cli. It is written in Go, ships as a single binary, and has no runtime dependencies. Clean, fast, and built for the terminal-first developer.