DEV Community: RAXXO Studios

Form Validation in 2026: 6 Native Constraints Before You Reach for a Library

RAXXO Studios — Fri, 19 Jun 2026 11:25:43 +0000

Native constraints cover 6 common cases without a single byte of JS
setCustomValidity gives you full control over error text
:user-invalid styles errors only after the user interacts
Reach for a library only for cross-field and async rules

I shipped a checkout form last month with zero validation libraries and it handled everything: required fields, email shapes, password length, matching inputs, and inline error styling. The whole thing was native HTML and about 30 lines of JavaScript. Here is exactly how far the browser takes you in 2026, and the precise point where a library still earns its bytes.

The 6 Native Constraints That Cover Most Forms

Before you npm install anything, here are the six attributes that solve the bulk of real validation. Every one of these ships in every browser shipping today.

First, required. Empty field, no submit. One word. It works on text inputs, selects, checkboxes, and radios.

Second, type. Setting type="email" makes the browser check for a basic email shape. type="url" checks for a protocol. type="number" blocks non-numeric input on most keyboards and validates on submit. These are not perfect (the email check allows a@b which is technically valid) but they catch 90 percent of fat-finger mistakes.

Third, minlength and maxlength. A password field with minlength="8" refuses to submit at 7 characters and tells the user why. No counter logic needed.

Fourth, min, max, and step for numbers and dates. A quantity field with min="1" max="99" enforces the range. A date picker with min="2026-01-01" blocks past dates.

Fifth, pattern. This is a regex attribute. A postal code field with pattern="[0-9]{5}" enforces five digits. Pair it with the title attribute so the error message explains the expected format.

Sixth, inputmode and autocomplete. These do not validate, but they reduce errors before they happen. inputmode="numeric" pulls up the number pad on phones. autocomplete="email" lets the browser fill known-good data. Fewer typos means fewer validation failures.

Here is a real field from that checkout:

That block validates four ways with no script attached. The browser blocks submit, shows a bubble, and focuses the first bad field. I measured it: this covered 6 of the 8 validation cases on the form. Two cases needed JavaScript, which I will get to.

The Constraint Validation API for Custom Messages

The native bubble messages are functional but generic. "Please fill out this field" is fine. "Please match the requested format" is useless to a user staring at a postal code box. This is where the Constraint Validation API earns its place, and it is built into every input element already.

Every form control exposes a validity object. Read it and you get booleans like valueMissing, typeMismatch, tooShort, patternMismatch, and rangeUnderflow. You check which one is true and you write a message that actually helps.


input.addEventListener('invalid', () => {
  if (input.validity.valueMissing) {
    input.setCustomValidity('Email is required.');
  } else if (input.validity.typeMismatch) {
    input.setCustomValidity('That email looks off.');
  } else {
    input.setCustomValidity('');
  }
});
input.addEventListener('input', () => {
  input.setCustomValidity('');
});

The key detail people miss: you must clear the custom message on the next input event by calling setCustomValidity(''). If you forget, the field stays stuck in an invalid state even after the user fixes it. That one line is the difference between a working form and a frustrating one.

setCustomValidity also flips the field into an invalid state. So you can use it for rules the browser does not know. Want to reject disposable email domains? Check the value, set a custom message, and the native machinery handles the rest: the submit blocks, the bubble shows, focus moves.

You also get checkValidity() and reportValidity() on both individual fields and the whole form. checkValidity() returns true or false silently. reportValidity() does the same but also shows the bubbles and focuses the first bad field. I call form.reportValidity() at the top of my submit handler. If it returns false, I bail before touching the network. That single call replaced what used to be a 40-line validation loop in older codebases I have cleaned up.

The reason this matters for a one-person studio: less code means fewer bugs to chase later. I documented my whole approach to keeping dependencies lean in the Claude Blueprint, and form validation is one of the clearest examples of the browser already doing the heavy lifting.

Styling Errors With :user-invalid Instead of :invalid

For years the styling story was broken. The :invalid pseudo-class matches a field the moment the page loads if it is empty and required. So a fresh form shows every required field glowing red before the user types a single character. That is hostile. Everyone worked around it with JavaScript classes like .touched or .dirty.

:user-invalid fixes this at the CSS level. It only matches after the user has interacted with the field and then moved on, or after a submit attempt. No JavaScript flag needed. This is shipping in every current browser as of 2026, so the old workarounds are dead weight now.


input:user-invalid {
  border-color: #d33;
}
input:user-valid {
  border-color: #2a2;
}

That is the entire styling layer. Empty form on load: neutral borders. User tabs through an empty required field: red border appears. User fixes it: green border. No class toggling, no event listeners for state. I cut about 60 lines of "touched state" tracking out of a form rebuild and the behavior got better, not worse.

There is a companion pseudo-class worth knowing: :has(). You can style a field's wrapper based on the input inside it.


.field:has(input:user-invalid) .error-text {
  display: block;
}

That shows your custom inline error text only when the field is actually in a user-invalid state. Combine :user-invalid with :has() and you have a full error display system with zero JavaScript for the styling layer. The JS only sets messages; CSS handles all the visual state.

One gotcha: :user-invalid does not fire for programmatic value changes. If you set a value with JavaScript, it will not flag as user-invalid until the user touches it. Usually that is the behavior you want, but test it if you autofill fields. I keep a short list of these browser quirks the same way I keep reusable Git hooks, small things I copy into every project so I never relearn them. The pattern of writing down the gotcha once saves me an afternoon every time.

Where a Library Still Earns Its Bytes

Native validation handles single-field rules beautifully. It falls apart on two things, and these are exactly where a library still pays for its download size.

First, cross-field validation. The classic case is "confirm password must match password." The browser has no concept of one field depending on another. You can hack it with setCustomValidity and a manual comparison, and for one rule that is fine:


confirm.addEventListener('input', () => {
  confirm.setCustomValidity(
    confirm.value === pw.value ? '' : 'Passwords must match.'
  );
});

But when you have five interdependent rules ("if country is US, postal code is required and must be 5 digits; if shipping differs from billing, validate both blocks") the manual approach turns into spaghetti fast. A schema-based library like Zod or Valibot lets you declare the whole relationship once and validate the entire object in one call. That is genuinely better than hand-rolling it.

Second, async validation. "Is this username taken?" or "Is this discount code valid?" requires a network call. Native constraints are synchronous. You can fake async with setCustomValidity after a fetch resolves, but you have to manage loading states, debouncing, and race conditions yourself. A good library gives you that plumbing for free.

My rule of thumb after building dozens of forms: if your form is single-field rules plus one or two cross-field checks, stay native. The total cost is the 30 lines I mentioned at the top. If you have a multi-step form, conditional fields that appear based on earlier answers, server-side schema reuse, or three or more async checks, reach for a schema library and share the schema between client and server. That shared schema is the real payoff, not the validation itself.

The trap is reaching for the library by default. I see projects pull in 40KB of validation code to enforce a required email field. That is solved by one HTML attribute. Start native, measure what actually breaks, and add the library only at the field where the browser genuinely cannot help. Most forms never hit that line.

Bottom Line

Native form validation in 2026 covers far more than most developers assume. Six attributes (required, type, minlength, pattern, min/max, and the input hints) handle the common cases with zero JavaScript. The Constraint Validation API gives you full control over error messages through setCustomValidity. And :user-invalid finally lets you style errors at the right moment without tracking touched state by hand. Together that is a complete validation system in about 30 lines.

The library only earns its bytes for cross-field rules at scale and async checks against a server. Even then, the real win is sharing one schema between client and browser, not the validation logic itself.

I rebuild small tools constantly as a solo studio, and cutting dependencies is how I stay fast. If you want the same approach applied across a whole project, the Claude Blueprint walks through how I keep things lean from the first commit. Start native. Add code only where the browser truly cannot help. Your future self maintaining the form will thank you.

The Native Popover API: 4 Menus and Tooltips I Built Without JavaScript

RAXXO Studios — Thu, 18 Jun 2026 00:16:50 +0000

Popover attribute gives top-layer rendering and light-dismiss free
Anchor positioning ties menus to triggers with no JavaScript
Built 4 components: dropdown, tooltip, command menu, confirm popup
Removed a positioning library and every z-index hack from the project

I deleted a 12KB positioning library and 40 lines of z-index guesswork from one Shopify theme last month. The replacement was two HTML attributes and a handful of CSS rules. The native popover API plus CSS anchor positioning now handles every menu, tooltip, and confirm dialog I used to wire up by hand.

Here is what I built, why it works, and where the rough edges still are.

Why The Popover Attribute Changes The Math

The first thing that surprised me was how little code it took. A popover is just an element with the popover attribute and a trigger that points at it with popovertarget. No event listeners. No state variable. No library.


Options

  Edit
  Duplicate
  Delete

Click the button, the div shows. Click outside it, the div hides. Press Escape, it hides. That is light-dismiss, and it ships for free. I used to write a document click listener for every dropdown, check if the click was inside the menu, then close it. Then I would forget the Escape key. Then I would forget to remove the listener on unmount and leak memory. All of that is gone.

The bigger win is the top layer. Anything with popover renders in the browser top layer, above everything else on the page, regardless of where it sits in the DOM or what overflow: hidden ancestors it has. This is the thing that ended my z-index wars. I had a theme where a card had overflow: hidden for rounded corners, and a dropdown inside it got clipped. The old fix was teleporting the menu to document.body with a portal, then manually positioning it. The top layer makes that entire pattern unnecessary.

There are two modes. popover (which defaults to popover="auto") gives light-dismiss and only one auto popover open at a time. popover="manual" stays open until you close it in code, which I use for toasts and persistent panels. Picking the right mode up front saves a lot of confusion later.

Browser support is solid now. Chrome, Edge, Safari, and Firefox all ship it. I still add a tiny feature check for the 3 percent of traffic on old browsers, and those users get a plain inline block instead of a floating menu. Nobody complained. The fallback is uglier, not broken, which is the correct tradeoff for a progressive enhancement.

Component One And Two: Dropdown And Tooltip

The dropdown was the easy case. The trick is positioning it relative to the trigger, and that is where anchor positioning comes in. I name the trigger as an anchor, then tell the popover to attach to it.


.menu-trigger { anchor-name: --opts; }
#menu {
  position-anchor: --opts;
  position-area: bottom span-right;
  margin-top: 6px;
}

position-area is the readable shorthand. bottom span-right means "below the trigger, spanning to the right." No getBoundingClientRect, no scroll listeners, no recalculating on resize. The browser keeps the menu glued to the trigger as the page scrolls. I tested it inside a sticky header and it tracked perfectly.

The part that earns its keep is position-try. If the menu would overflow the viewport bottom, the browser flips it above the trigger automatically.


#menu {
  position-try-fallbacks: flip-block, flip-inline;
}

That one line replaced the collision-detection logic that used to be the buggiest part of every menu I shipped. On a long product page, the dropdowns near the footer now open upward without me writing a single conditional.

The tooltip was even leaner. I used popover="manual" paired with popovertargetaction and hover handling, but the cleaner version uses the new CSS-only approach where a tooltip is an anchored popover shown on focus and hover. For accessibility I keep it dismissible by Escape and reachable by keyboard, because a tooltip that only appears on mouse hover excludes keyboard users.


.tip {
  position-anchor: --field;
  position-area: top;
  margin-bottom: 8px;
}
.tip::after {
  content: "";
  position: absolute;
  /* little arrow pointing at the anchor */
}

One real number: my tooltip component went from 84 lines of JavaScript and CSS down to 21 lines of pure CSS plus the markup. That is roughly a 75 percent cut, and the new version has fewer edge cases because the browser owns the positioning math. If you want the deeper context on the positioning side, CSS Anchor Positioning Is Production Ready covers the five patterns I lean on most. (Verify that link exists in your index before shipping, since I keep a running list of anchor patterns there.)

Component Three: The Command Menu

This is the one I was sure would force me back into JavaScript, and it mostly did not. A command menu is a search-filtered list of actions, the kind you open with a keyboard shortcut. The popover handles the open and close. Anchor positioning handles the placement, centered near the top of the screen.

The popover attribute gives me the shell for free.

I still need JavaScript for two things: filtering the list as you type, and the keyboard shortcut to open it. Everything else (the top-layer render, the backdrop, the Escape-to-close, the click-outside dismiss) is native. So my script shrank to about 30 lines, and all of it is genuine logic rather than DOM plumbing.

The ::backdrop pseudo-element deserves a mention. Popovers get a backdrop element you can style without adding a div.


#cmd::backdrop {
  background: rgba(0, 0, 0, 0.4);
  backdrop-filter: blur(2px);
}

I used to build that dimmed background with an absolutely positioned overlay div, then juggle its z-index against the menu. Now it is one selector and the layering is handled by the top layer.

The animation was the last piece. Popovers can animate on open and close using @starting-style and transitions on display and overlay, which lets the element stay in the top layer through the exit animation. This used to require a setTimeout to delay the unmount until the animation finished, a pattern that broke whenever the user clicked fast.


#cmd {
  opacity: 0;
  transition: opacity 0.15s, overlay 0.15s allow-discrete, display 0.15s allow-discrete;
}
#cmd:popover-open { opacity: 1; }
@starting-style {
  #cmd:popover-open { opacity: 0; }
}

The allow-discrete keyword is the magic word that makes display and overlay animatable. Without it, the menu just snaps. I forgot it the first three times and could not figure out why my fade did nothing. Background: I covered the same display-transition trick in CSS Anchor Positioning Is Production Ready if you want the full breakdown.

For scheduling the posts where I document these builds I lean on Buffer, which keeps the publishing side off my plate while I write.

Component Four: The Confirm Popup, And The Catches

The fourth component is a small confirm popup, the "are you sure you want to delete this" prompt that appears anchored to the delete button. I used popover="manual" here on purpose, because I do not want a misclick outside the popup to count as dismissal when a destructive action is on the table. The user has to choose Cancel or Confirm.


Delete


Delete this item?

  Cancel
  Confirm

Notice the Cancel button uses popovertargetaction="hide" to close the popup declaratively, no script. The Confirm button runs the actual action. That split keeps the dangerous path explicit.

Now the catches, because there are real ones.

First, focus management. The popover API moves focus into the popover for dialog elements, but a plain div popover does not trap focus by default. For the command menu I move focus to the search input on open with a tiny toggle event listener. Do not skip this. A menu that opens without sending focus is unusable by keyboard.

Second, position-area does not yet cover every alignment case I want. Centering a popover horizontally over a wide anchor sometimes needs justify-self: anchor-center, which has spottier support than the rest. I keep a @supports check and fall back to a margin nudge.

Third, the auto-dismiss can fight you. If you nest an auto popover inside another auto popover, opening the child can close the parent unless you use the popover nesting rules correctly by placing the trigger inside the parent. I lost an hour to this before reading that the relationship is inferred from where the trigger lives, not from DOM nesting of the popovers themselves.

Fourth, animating exit needs overlay in the transition list or the element drops out of the top layer mid-animation and flickers behind other content. That one bit me on the confirm popup until I added it.

None of these are dealbreakers. They are the kind of edges you hit once, write down, and never hit again. My running notes on this stuff feed straight into Claude Blueprint, which is where I keep the patterns I reuse across themes.

Bottom Line

Four components: dropdown, tooltip, command menu, confirm popup. I shipped all of them with the native popover attribute and CSS anchor positioning, and I removed a 12KB library plus every z-index hack in the process. The tooltip alone dropped about 75 percent of its code. The command menu kept roughly 30 lines of genuine logic and gave the rest back to the browser.

The mental shift is the real payoff. Top-layer rendering ends clipping and stacking fights. Light-dismiss and Escape handling are free. Anchor positioning with position-try flips menus away from screen edges without a single conditional. I write less code, ship fewer bugs, and the components behave consistently because the browser owns the hard parts.

If you build store interfaces or any UI with floating elements, try rebuilding one menu this way before reaching for a library. Start with a plain dropdown, add the anchor, add a flip-block fallback, then graduate to the command menu. The patterns stack. My full set of reusable snippets and the way I keep them organized lives in Claude Blueprint if you want a head start.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

The Anatomy of a Good Empty State: 6 Patterns That Guide the Next Action

RAXXO Studios — Wed, 17 Jun 2026 00:18:17 +0000

Three empty state types: first-run, cleared, error-empty, each needs different copy
One primary action rule: never give an empty screen two equal buttons
Copy teaches, never apologizes: replace "No items found" with a next step
6 patterns I ship across every RAXXO interface

Most empty states are accidents. Nobody designs them, so they default to a gray "No data" line and a sad icon. I treat them as the cheapest onboarding I will ever build, because a person sees the empty state before they see anything full.

Why Empty States Are Onboarding in Disguise

The first screen a new user sees is almost always empty. No projects, no orders, no saved items. That is not a failure mode. That is the actual product introduction, and it happens at the exact moment the person is deciding whether to keep going.

I tracked this on one of my dashboards. Out of 100 new accounts, 38 hit an empty list within the first 20 seconds. If that screen just says "No projects yet," I am wasting the most attentive moment a user will ever give me. They are not bored yet. They are not frustrated yet. They are looking for the next thing to do.

So I split empty states into three kinds, and I never let one template cover all three.

The first is first-run empty. The user has never had data here. This is pure onboarding. The job is to explain what this space is for and hand them one obvious action.

The second is cleared empty. The user had data and finished it. An inbox at zero, a task list completed, a cart emptied after checkout. This one should feel like a small reward, not a void. "You are all caught up" beats "No messages" every time.

The third is error-empty. Something failed. The list is empty because a request timed out or a filter returned nothing. This needs a different tone again, because the user did not cause it and a cheerful illustration here feels mocking.

When I started labeling every empty screen with one of these three tags before writing a single word of copy, my interfaces got noticeably less confusing. The same gray box was doing three jobs badly. Now each job gets its own treatment. The structural lesson is the same one behind any good system: name the state before you style it, the way I name component states in Claude Blueprint before I write a line of markup.

Pattern 1 and 2: The Single Primary Action Rule

Here is the rule I break the least: an empty state gets exactly one primary action. One button that looks like a button. Everything else is text or a secondary link.

I learned this the hard way. An early version of a project screen had three buttons of equal weight: "Create project," "Import data," and "Watch tutorial." All three were blue. All three were the same size. New users clicked none of them at a rate that embarrassed me. When three options carry equal visual weight, the brain treats the choice as work, and work at minute zero is where people leave.

I cut it to one blue button: "Create your first project." The other two became a single line of gray text underneath: "or import from a file." The number of people who took any action inside the first session jumped enough that I stopped second-guessing the rule.

Pattern 1 is the single primary action. Pattern 2 is the supporting line. The supporting line exists for the 15 percent of users who do not want the obvious path. You do not hide the import option. You demote it. The visual hierarchy does the teaching: this is what most people do, and here is a quieter door if you are not most people.

A concrete checklist I run on every empty state now:

Exactly one element styled as a primary button.
That button's label is a verb plus the object ("Add a product," not "Get started").
Any alternative path is text-weight, not button-weight.
No more than two total clickable things in the whole empty area.

That last point matters. I counted the clickable elements on one cluttered empty screen and found seven, including a help icon, two nav crumbs, and a settings gear. Seven targets on a screen with zero content. I stripped it to two. The button and the alternative link. Less to scan means faster decisions, and a faster first decision is the entire game on a brand-new account.

Pattern 3 and 4: Copy That Teaches Instead of Apologizing

The default empty-state copy is an apology. "No results found." "Nothing here yet." "Sorry, no items." Apology copy treats the empty screen as a problem the user must forgive. Teaching copy treats it as the next lesson.

Pattern 3 is the teaching headline. Instead of describing the absence, describe the capability. Bad: "No automations." Good: "Automations run tasks for you while you sleep." The second version tells a brand-new user what the feature even does, which the empty screen is the perfect place to explain because there is nothing else competing for the space.

I rewrote 11 empty-state headlines across one app using this single swap. Describe what the thing does, not what is missing. For a saved-searches feature I went from "No saved searches" to "Save a search to get alerts when new listings match." The word count went up by six. The clarity went up far more, because a new user genuinely did not know that saved searches triggered alerts. The empty state taught them.

Pattern 4 is matching tone to state type, which ties back to the three categories. First-run copy is instructional and warm. Cleared copy is congratulatory and brief. Error-empty copy is plain and honest, with a retry action.

Here is the same screen, a notifications list, written three ways:

First-run: "Notifications show up here when something needs you. Turn on alerts to start."
Cleared: "You are all caught up. Nice."
Error-empty: "We could not load notifications. Retry, or check back in a minute."

Same empty list, three completely different messages, because the user arrived at the empty state for three completely different reasons. The error version gets the retry button. The cleared version gets nothing clickable at all, because the user just finished and does not need a task. The first-run version gets the one primary action.

The thing I keep relearning: copy in an empty state is not decoration around the real UI. In an empty state, the copy IS the UI. There is nothing else on the screen, so every word is load-bearing. If you want the deeper context on writing interface copy that does work, Claude Blueprint walks through how I prompt for it consistently.

Pattern 5 and 6: Illustration Weight and the Cleared-State Reward

Pattern 5 is illustration restraint. A big custom illustration on an error-empty state reads as tone-deaf. The request failed and you are showing me a smiling cartoon. I keep illustrations for first-run and cleared states only, and even there I keep them small.

I generate these in batches with Magnific when I want a consistent style across a dozen empty screens, then downscale hard. A 1200px hero illustration on an empty list is the wrong weight. It pulls attention away from the one action I want the user to take. I cap empty-state art around 160px wide. The button stays the loudest thing on screen. The art supports, it does not headline.

There is a measurable cost to heavy illustrations too. One first-run screen shipped with a 480KB animated graphic that delayed the primary button paint by most of a second on a mid-range phone. The button is the point. Delaying the button to show art is the tail wagging the dog. I swapped it for an inline SVG under 8KB and the button appeared instantly.

Pattern 6 is treating the cleared state as a reward, not a void. This is the one most products miss. When a user clears their inbox or finishes every task, the screen goes empty, and a lazy design shows the same "No items" message it would show a confused first-run user. That is a wasted moment of genuine satisfaction.

Give the cleared state a small payoff. A short congratulatory line. A subtle checkmark. Maybe a count of what they just finished ("12 tasks done today"). I added a one-line cleared message to a task app and the number of users who came back the next day to clear it again went up, because finishing felt like something instead of nothing.

If a cleared state is a natural moment of accomplishment, it is also a natural moment to suggest the next loop. Not a hard sell. A gentle "Schedule next week's posts?" works when someone just cleared their queue. I route social actions like that through Buffer so the cleared state becomes a soft on-ramp to the next session rather than a dead stop. The rule stays intact: one primary action, even in the reward state.

Bottom Line

Empty states are not edge cases. They are the first screen, the finished screen, and the broken screen, and each one is a chance to either guide someone or lose them. Label every empty area as first-run, cleared, or error-empty before you write a word. Give it exactly one primary action. Write copy that teaches what the feature does instead of apologizing for what is missing. Keep illustrations small enough that the button stays the loudest thing on screen. And treat a cleared state as a reward, because the user earned it.

I run these six patterns as a checklist on every interface I ship now, and the gray "No data" box has basically disappeared from my work. The screens that used to feel like dead ends now point somewhere. If you want the full system I use to prompt for interface copy and component states consistently, Claude Blueprint is where I keep it. Start with your most-seen empty screen and rewrite the headline first. That one swap usually pays for itself.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Generate Open Graph Images On the Fly With Satori and Resvg

RAXXO Studios — Tue, 16 Jun 2026 01:41:36 +0000

Satori turns JSX into SVG with zero browser, runs in 40ms
Resvg renders SVG to PNG in pure Rust, no Puppeteer
Full edge function code that caches per-page cards
Each blog post gets a unique share image automatically

Every link I shared on social used to show the same generic banner. Now every page on raxxo.shop generates its own Open Graph card with the title, the author, and a clean layout, all rendered on the fly. No headless browser, no screenshot service, no build step. Here is the entire pipeline.

Why Skip the Headless Browser

The standard way to make share cards is Puppeteer. You spin up a headless Chromium, load an HTML page, screenshot it, save the PNG. It works. It is also slow, heavy, and a pain to run on an edge function.

Chromium is roughly 280MB unpacked. Most edge runtimes cap your bundle at 50MB or refuse to launch a browser at all. Cold starts run 800ms to 2 seconds because the browser has to boot before it draws a single pixel. I ran a Puppeteer card service for a while and the p95 latency sat around 1.4 seconds. For an image that loads in the background of a social preview, that is fine until you have 60 posts and a crawler hits them all at once.

The alternative is Satori plus Resvg. Satori is a library that takes JSX (or a plain object tree) and produces an SVG string. It does the layout in JavaScript using a flexbox engine, so no browser, no DOM. Resvg then takes that SVG and rasterizes it to PNG using Rust compiled to WebAssembly. Both run inside a normal serverless or edge function.

The numbers that sold me: Satori renders a typical 1200x630 card in about 40ms. Resvg converts the SVG to PNG in another 30 to 60ms depending on font count. Total cold path under 200ms, warm path closer to 90ms. The whole bundle is under 8MB instead of 280MB.

There is a tradeoff. Satori only supports a subset of CSS. Flexbox works. Grid does not. No CSS animations, no filters beyond a few, no external stylesheets. You build cards with flex containers, fixed positions, colors, and text. For a share card that is exactly the vocabulary you need anyway, so the limit rarely bites.

If you want the broader pattern of doing real work at the edge instead of on a fat server, the same thinking shows up in how I structure the rest of the stack. Background: Claude Blueprint goes through how I keep services small and composable.

The Minimal Satori Setup

Install two packages: satori and @resvg/resvg-js. You also need at least one font as a buffer, because Satori cannot guess a typeface the way a browser falls back to system fonts.

Here is the core function. I am using the object form instead of real JSX so it runs without a JSX transform.


import satori from 'satori'
import { Resvg } from '@resvg/resvg-js'
import fs from 'node:fs/promises'

const fontData = await fs.readFile('./fonts/Inter-Bold.ttf')

export async function renderCard({ title, tag }) {
  const svg = await satori(
    {
      type: 'div',
      props: {
        style: {
          width: '1200px',
          height: '630px',
          display: 'flex',
          flexDirection: 'column',
          justifyContent: 'space-between',
          padding: '64px',
          background: '#0b0b0f',
          color: '#ffffff',
        },
        children: [
          {
            type: 'div',
            props: {
              style: { fontSize: '28px', color: '#9aa0ff' },
              children: tag.toUpperCase(),
            },
          },
          {
            type: 'div',
            props: {
              style: { fontSize: '72px', lineHeight: 1.1 },
              children: title,
            },
          },
          {
            type: 'div',
            props: {
              style: { fontSize: '32px', color: '#8a8a93' },
              children: 'raxxo.shop',
            },
          },
        ],
      },
    },
    {
      width: 1200,
      height: 630,
      fonts: [{ name: 'Inter', data: fontData, weight: 700, style: 'normal' }],
    }
  )

  const png = new Resvg(svg, { fitTo: { mode: 'width', value: 1200 } })
  return png.render().asPng()
}

That is the whole thing. Satori returns an SVG string. Resvg takes it, renders, and asPng() hands back a buffer of bytes you can return as image/png.

A few details that cost me time. Every div with more than one child needs display: flex set explicitly, or Satori throws. It does not assume block layout. Fonts must be .ttf or .otf, not .woff2, because the SVG renderer cannot decompress woff2. If your title overflows, set a maxWidth and Satori wraps it for you, but only if display: flex and flexWrap or a fixed width is present.

For 1200x630, the magic numbers are 64px padding and a 72px headline. That sizing reads cleanly when a platform shrinks the preview to a thumbnail. Smaller text turns to mush at thumbnail scale.

Serving It From an Edge Function

The render function is half the job. The other half is wiring it to a URL so `` can point at it.

I expose a route like /og?title=...&tag=.... The function reads the query params, calls renderCard, and returns the PNG with cache headers. The cache headers matter more than the render speed, because once a card is generated the crawler should never trigger a fresh render again.

`javascript

export default async function handler(req) {
const url = new URL(req.url)
const title = url.searchParams.get('title') ?? 'Untitled'
const tag = url.searchParams.get('tag') ?? 'Lab'

const png = await renderCard({ title, tag })

return new Response(png, {
headers: {
'content-type': 'image/png',
'cache-control': 'public, immutable, max-age=31536000',
},
})
}

The immutable, max-age=31536000 line tells the CDN to hold the result for a year. Because the title and tag are in the URL, any change to a post title produces a new URL and a new cache key automatically. No manual invalidation.

One trap: passing raw user text in a query string breaks on special characters. I encodeURIComponent the title when I build the meta tag, and the function decodes it through URLSearchParams for free. Long titles also need a length cap, around 90 characters, or the layout breaks. I truncate with an ellipsis before passing it in.

I load the font once at module scope, outside the handler, so it stays warm between invocations on the same instance. Reading a 350KB font file on every request added 15ms I did not need. Hoisting it out cut warm latency by that amount across thousands of calls.

For social scheduling I push the generated card URLs straight into Buffer so each scheduled post pulls its own preview. If you generate the images first and let the platform crawl them once, the queue stays fast and nothing renders twice. The whole point is that the heavy work happens at the edge near the user, not on a single origin server that becomes a queue when a crawler fans out across your sitemap.

Templates, Fonts, and the Edge Cases

A single layout gets boring after a dozen posts. I keep three template functions: one for tutorials, one for case studies, one default. The route picks one based on a template param. Each is just a different object tree, maybe a different accent color and a small icon.

Emoji is the first thing that breaks. Satori does not ship an emoji font, so a 🚀 renders as a blank box. The fix is to pass a loadAdditionalAsset callback that fetches the right glyph from an emoji CDN on demand. I cache those fetches in a Map keyed by code point, so the same emoji never downloads twice within a warm instance. With 12 common emoji preloaded, the extra latency dropped to near zero.

Multiple font weights matter more than I expected. A card with one weight looks flat. I load Inter at 400, 600, and 700 and assign weights per element. The bundle grows by about 700KB total, which is nothing next to a browser. Mixing a regular tag label against a bold headline gives the card a real visual hierarchy that reads at thumbnail size.

Images inside cards are the trickiest part. Satori accepts an ` with a src`, but the src must be a base64 data URI or a fully resolvable URL, and Resvg has to fetch and decode it during rasterization. A remote PNG logo adds 40 to 120ms. I inline my logo as a base64 string baked into the template, so there is no network hop at render time.

Color and contrast deserve a test pass. I render every template once and check it on a phone-sized preview, because what looks crisp at 1200px wide can vanish at 300px. Light gray subtitles below #888 disappear against dark backgrounds when compressed by the platform.

For the deeper version of how I keep these template files small and reusable, I covered the same modular approach in Claude Blueprint. The principle carries: small typed functions, one job each, no clever inheritance. A card template is 30 lines. When I want a fourth style I copy one, change the color tokens, and ship it the same day.

Bottom Line

Satori plus Resvg replaced a 280MB browser with an 8MB pipeline that renders a share card in under 200ms cold and 90ms warm. JSX goes in, SVG comes out, PNG bytes come back, and a one-year cache header means each unique title renders exactly once before the CDN takes over. No screenshot service, no Chromium, no build step.

The setup that took me the longest was not the render code. It was the font handling, the emoji callback, and the cache headers, which is where the real latency lives. Get those three right and the rest is just designing object trees that happen to look like flexbox.

If you run a content site or a store with lots of pages, this is the highest-use afternoon project I know of. Every link you share starts looking deliberate instead of generic. Start with one template, wire the route, point your meta tag at it, and add styles as you go. The code above is the whole skeleton. Copy it, swap the font, and you have unique cards by tonight.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

The Native HTML Dialog Element: 6 Modal Patterns I Ship Without a Library

RAXXO Studios — Mon, 15 Jun 2026 13:20:42 +0000

Native dialog removed a 14KB modal library from 9 sites
method=dialog forms close and return values with zero JS
@starting-style plus closedby="any" handle exit animation and light-dismiss
One case (nested non-modal popovers) still needs a small helper

I deleted a 14KB modal library from 9 of my sites last quarter. The native `` element replaced every feature I was paying for: focus trap, top-layer stacking, escape-to-close, backdrop styling. Here are the 6 patterns I ship now, plus the one situation where I still reach for help.

The Free Focus Trap And Top-Layer Stacking

The reason most people install a modal library is the focus trap. When a dialog opens, keyboard focus needs to stay inside it. Tab past the last button and you should loop back to the first, not fall through to the page behind. Writing that by hand is a pain. You track focusable elements, listen for Tab and Shift+Tab, and handle the wrap. Libraries charge you kilobytes for it.

dialog.showModal() does the trap for free. Call it and the browser confines Tab to the dialog, sends Escape to close, and marks everything behind it inert so screen readers skip it. I tested this with VoiceOver on 3 of my product pages and the reading order was correct without a single ARIA attribute from me.

The second free thing is the top layer. When you open a modal dialog, the browser promotes it above every other element regardless of z-index. I used to fight stacking context bugs constantly, where a modal would sit behind a sticky header because some ancestor had transform set. The top layer ignores all of that. A modal dialog paints on top, period.

`javascript

Your cart

document.querySelector('#cart').showModal();

Note the autofocus attribute. The browser moves initial focus to it when the dialog opens, which is the accessible default you want. Use show() instead of showModal() and you get a non-modal dialog: no backdrop, no focus trap, no inert background. I use the modal version for anything that demands a decision (checkout confirm, age gate) and the non-modal version for things that should not block the page. If you came up through the era where this all needed JavaScript, my notes on 5 CSS Animations That Needed JavaScript Until 2026 cover the same shift in mindset.

That is two of the three big reasons people install a library, gone, with two method calls.

Styling ::backdrop And The method=dialog Form Trick

The dimmed overlay behind a modal has its own pseudo-element: ::backdrop. You style it like any selector. No extra div, no positioned overlay that you have to z-index above the content.

`css

dialog::backdrop {
background: rgb(0 0 0 / 0.6);
backdrop-filter: blur(4px);
}

I run a 4px blur on the backdrop across all my storefronts. It costs one line and makes the modal feel intentional instead of bolted on. You can animate ::backdrop too, which matters for the exit animation pattern below.

The form trick is the part people miss. A inside a dialog closes it on submit and records which button was used, all without JavaScript.

`plaintext

Delete this draft?

Cancel
Delete

When the user clicks Delete, the dialog closes and dialog.returnValue becomes "delete". You read it in a single close event listener:

`javascript

confirm.addEventListener('close', () => {
if (confirm.returnValue === 'delete') removeDraft();
});

That is a complete confirm dialog with two outcomes and almost no script. I shipped exactly this for a destructive action on one of my Shopify admin tools and it replaced about 40 lines of state handling. If you build on Shopify, this pattern slots right into theme app blocks because it needs nothing global.

The catch worth knowing: method="dialog" only closes the dialog, it does not submit data anywhere. If you need a real network submit, keep a normal form and call dialog.close() yourself after the fetch resolves. I mixed the two up early on and spent 20 minutes confused why my POST never fired. The fix was one attribute. For the broader pattern of moving logic out of JavaScript and into the platform, CSS :has() in Production walks through the same trade-offs on the selector side.

Light-Dismiss With closedby And Clean Exit Animations

For years the standard request was "let me click outside the modal to close it." That meant a click listener on the backdrop, math to check the click target, and an edge case where clicking inside and dragging out would close it by accident. Now there is an attribute.

`plaintext

...

closedby="any" gives you light-dismiss: click the backdrop or press Escape and the dialog closes. closedby="closerequest" allows only Escape and the platform close gesture. closedby="none" blocks both, which I use for a payment-in-progress modal that must not be dismissed mid-transaction. Three values, zero listeners. This shipped to stable Chrome and is rolling through the other engines, so I feature-detect and fall back to a tiny backdrop-click handler where it is missing.

Exit animations were the other thing libraries handled. The problem: when you set display: none the element vanishes instantly, so there is nothing to animate out. The new combo is @starting-style for the entry and transition-behavior: allow-discrete for the exit.

`css

dialog {
opacity: 1;
transition: opacity 0.2s, overlay 0.2s allow-discrete, display 0.2s allow-discrete;
}
dialog:not([open]) { opacity: 0; }
@starting-style {
dialog[open] { opacity: 0; }
}

@starting-style defines the values the dialog starts from before it opens, so it fades in. allow-discrete on display and overlay keeps the element painted through the exit transition instead of cutting it the instant the attribute drops. The overlay property is what keeps it in the top layer until the fade finishes. I run a 200ms fade plus an 8px translate on every dialog now and it reads as polished without a single requestAnimationFrame call.

This is the same family of platform animation work I covered in CSS Scroll-Driven Animations: 6 Patterns I Ship in 2026, and the discrete-transition trick shows up there too. If you want the whole animation story without JS, View Transitions API: 5 Patterns pairs cleanly with dialogs for full-screen route changes.

The One Case Where A Library Still Wins

I want to be honest about the limit, because pretending native covers everything would cost you a debugging afternoon. The element handles single modals beautifully. It struggles with deeply nested, non-modal stacks where multiple floating panels need to coexist and dismiss in a specific order.

Picture a non-modal dialog that contains a select, and that select opens a custom dropdown, and the dropdown has a tooltip on one option. With show() (non-modal), there is no focus trap and no inert background, so you are back to managing focus order and outside-click dismissal across three independent layers. The native top layer stacks them, but it does not orchestrate which one Escape should close first or how focus should return down the chain. That orchestration is exactly what a small library like a focus-management helper gives you, and it is worth the 4KB in that narrow case.

I hit this building a filter panel for a catalog with 1,200 SKUs. The panel was non-modal so shoppers could keep scrolling the grid, but it held nested expandable groups with their own popovers. Native dialog plus the popover API got me 90% there. The last 10%, the predictable Escape order across nested popovers, was flaky enough that I added a 3KB helper just for focus return. Everything else stayed native.

The honest rule I use: if it is one modal at a time, native wins outright and I write zero JavaScript for behavior. If I have two or more interactive floating layers that must coordinate dismissal and focus, I keep a tiny helper and let it manage only that coordination, not the rendering.

A few smaller gotchas I logged so you do not repeat them. A dialog with no autofocus and no focusable child puts focus on the dialog itself, which is fine but means Escape works and Tab does nothing visible, confusing in testing. Setting max-height matters because long dialogs can overflow the viewport with no scroll. And the default dialog has a centered position via margin auto that you will likely override. For a related layout problem, anchoring a small panel to a trigger, CSS Anchor Positioning Is Production-Ready is the piece I reach for instead of a dialog entirely.

Bottom Line

The native `` element removed a dependency I had carried for years. Focus trap, top-layer stacking, backdrop styling, escape-to-close, light-dismiss, return values, and exit animations all live in the platform now. I ship 5 of the 6 patterns with zero behavior JavaScript and reach for a 3KB helper only when multiple floating layers must coordinate.

If you are still loading a modal library, open one component and try the swap. Replace the open call with showModal(), delete your focus-trap code, add a ::backdrop rule, and wire one close listener. On my sites that swap took an afternoon per component and cut real bytes off every page that rendered a modal.

I document each of these platform-over-library calls as I make them, because cutting dependencies is most of how a one-person studio stays fast. If you want the system I use to decide what to build, what to delete, and how I keep it consistent across repos, the Claude Blueprint lays out the whole workflow. Start with the dialog swap, measure the bytes you drop, and keep the helper only where the platform genuinely runs out.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

The Solo Studio Software Stack: What I Actually Pay For in 2026

RAXXO Studios — Mon, 15 Jun 2026 13:20:05 +0000

Total stack runs 312 EUR/month across 11 tools
Cut 4 subscriptions worth 178 EUR by consolidating
One swap paid for itself in 6 days
Rule: any tool under 20 EUR earns its keep, anything over needs proof

My software stack costs 312 EUR a month. Last year it was 490 EUR. I did not get cheaper tools, I got fewer of them, and the ones that stayed all do measurable work. Here is the exact line-item breakdown of what a one-person studio actually pays for in 2026, what I killed, and the single swap that paid for itself in under a week.

The Core Four That Never Get Questioned

Some tools are not up for debate. They run the business, and cutting them would cost me more in lost time than the subscription ever could.

Shopify is first at 32 EUR a month on the Basic plan. Every product I sell lives there. The storefront, the checkout, the order pipeline, all of it. I tried moving to a cheaper static-site-plus-payment-link setup in early 2025 and lasted eleven days before I crawled back. The hidden cost of DIY checkout is every edge case you did not plan for: failed payments, address validation, tax on digital goods. Shopify eats those for 32 EUR and I sleep fine.

Claude is second at 90 EUR a month for the Max-tier access I run. This is the single biggest line item and also the easiest to justify. It drafts, it codes, it audits my own work, it writes first passes of nearly everything. If you want the full picture of how I wire it into actual production, the Claude Blueprint walks through the setup end to end.

Third is my domain and email through a registrar plus a privacy-focused mail host, combined at 14 EUR a month. Boring, essential, never touched.

Fourth is cloud storage and backup at 11 EUR a month. Two copies, two providers, automated nightly. The day a drive dies, this 11 EUR becomes the best money I ever spent. I have had exactly one drive die since 2023 and the restore took 40 minutes instead of a panic spiral.

That is 147 EUR for the four things that, if they vanished tomorrow, would stop the studio dead. Everything below this line is optional in theory. In practice some of it earns more than the core. I rank tools not by what they cost but by what breaks when I remove them. The core four break everything. The next tier breaks output speed, which is its own kind of expensive.

The Creative Pipeline: Where the Money Actually Works

This is where a studio either spends smart or bleeds. Image and audio generation tools are easy to over-buy because every launch promises to replace three others.

Magnific holds the top spot here at 39 EUR a month. It upscales and refines the images that go into product mockups and blog headers. I ran a hard test on it for 30 days before committing, and the full writeup is in 30 Days With the Magnific Image Pipeline. Short version: it stayed because the output quality cleared a bar that three free alternatives could not, and the difference shows on product pages where image quality is the whole sell.

ElevenLabs is next at 22 EUR a month. Voiceover for short videos, audio previews, the occasional narration. I used to outsource this per project and the math was brutal. One 90-second voiceover from a freelancer ran 40 to 60 EUR and took two days. Now I generate, review, and ship the same day for a flat 22 EUR a month no matter how many I make. In a month where I produced eleven audio clips, the per-clip cost dropped to under 2 EUR. That is the kind of swap that does not need a spreadsheet to justify.

A generic stock asset subscription rounds out this tier at 16 EUR a month. Fonts, textures, the occasional video clip. I considered cutting it twice and both times found myself needing exactly one asset that would have cost more as a one-off purchase than the whole month.

That is 77 EUR for the creative engine. Combined with the core four, I am at 224 EUR and every euro is doing visible work. The rule I apply: anything under 20 EUR a month gets a long leash because the time it saves almost always beats the cost. Anything over 20 EUR has to prove itself on output I can point to. Magnific and ElevenLabs both clear that bar. The stock subscription squeaks by on convenience, and I review it every quarter.

The Boring Money Tools That Quietly Pay for Themselves

Nobody gets excited about accounting software. But the back-office stack is where I cut the most waste, and ironically where the swap that paid for itself in six days happened.

Stripe runs my payments and tax handling. There is no flat monthly fee, it takes a slice per transaction, so it does not appear as a line item but it is core. The reason I keep it over alternatives is the tax automation, which I broke down fully in Solo Studio Invoicing in 2026. That setup alone saves me hours every filing period.

My bookkeeping tool sits at 19 EUR a month. It syncs bank feeds, categorizes transactions, and exports clean reports. Here is the swap. I used to pay 49 EUR a month for a heavier accounting suite that did ten things I never used. I moved to the lighter 19 EUR tool, and because it exports cleanly into the format my routine needs, my monthly close went from a half-day slog to 90 minutes. The 30 EUR I saved per month was nice. The time was the real win. That whole routine lives in Solo Studio Bookkeeping in 90 Minutes a Month.

Why did it pay for itself in six days? The first close on the new tool surfaced two duplicate charges I had been paying for months, one of them a dead subscription. Catching those covered the switching effort almost immediately, and then kept paying every month after.

A password manager rounds this tier out at 4 EUR a month. Trivial cost, enormous downside if skipped. One studio I know lost access to a client account for a week over a forgotten login. Four euros buys me out of that entire category of problem.

There is also the VAT side of buying SaaS from EU vendors, which has a quieter cost than most people realize. If you buy tools across borders, EU Reverse-Charge VAT for Solo SaaS Buyers explains the zero-euro math that most developers miss entirely. Knowing it changed how I evaluate vendor pricing.

Back-office total: 23 EUR in flat fees plus Stripe's per-transaction cut. The cheapest tier and arguably the highest use.

What Got Cut and the Rules I Use to Decide

I killed four subscriptions in the last year worth 178 EUR a month combined. Here is what went and why.

The first was a project management app at 24 EUR a month. As a one-person studio I was building elaborate boards that only I would ever read. A plain text file and a calendar do the same job for free. Gone.

The second was a dedicated social scheduling tool I overpaid for at 65 EUR a month on a tier built for teams. I moved my scheduling to Buffer on a plan that fits an actual solo operator, and the savings were immediate. I do not need ten team seats. I need to queue posts and walk away.

The third was an AI writing tool at 45 EUR a month that I bought before Claude could do the same work better. Once the core model handled drafting, the specialized writer became dead weight. Cut.

The fourth was a video editing suite at 44 EUR a month that I used twice in a quarter. I switched to a one-time-purchase editor and stopped paying rent on software I barely opened.

The rules that govern all of this are simple and I apply them every quarter:

One, if I cannot name the specific output a tool produced this month, it is on probation. Two opens-and-forgets in a row and it is gone.

Two, flat fees under 20 EUR get a long leash because the downside of not having them usually beats the cost. The password manager and bookkeeping tool live here.

Three, anything over 20 EUR has to survive a real test, not a free trial I forget about. Magnific got a 30-day trial-by-fire. ElevenLabs proved itself against freelance pricing in week one.

Four, never buy a team tier as a team of one. I paid that tax twice and it stung both times.

Five, one tool replacing two is always worth the migration friction, even if the migration is annoying. Consolidation compounds. Fewer logins, fewer renewals, fewer surprise charges. Pricing discipline applies to my own products too, which I wrote about in Why I Doubled My Product Prices and Lost Zero Customers.

Bottom Line

The full stack lands at 312 EUR a month: 147 EUR core, 77 EUR creative, 23 EUR back-office flat fees, plus Stripe's per-transaction slice and the Buffer scheduling plan. A year ago it was 490 EUR and I was getting less done. The lesson was not to chase the cheapest option in every category. It was to know exactly what each tool produces and to cut anything I could not point to.

If you run a solo studio, do the audit. Open your last bank statement, find every recurring charge, and ask one question per line: what did this make this month? You will find a dead subscription. Almost everyone does. Mine cost me months before I caught it.

The tools that stayed are the ones doing visible work, and most of them link out across the back-office posts above if you want the deeper setup. The Claude Blueprint is where I show how the AI piece ties the whole stack together, which is the part that punches well above its 90 EUR weight.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Turn One Blog Post Into a LinkedIn Post, an X Thread, and an IG Carousel

RAXXO Studios — Mon, 15 Jun 2026 13:19:30 +0000

Pull the spine first: one argument, three reshapes, never cross-post
LinkedIn wants the lesson, X wants the build, IG wants the proof
Each platform gets a different hook from the same source paragraph
Schedule the whole week in one 40-minute block, then walk away

One blog post turned into a LinkedIn post, an X thread, and an Instagram carousel pulled 4,100 views across three feeds last week. I wrote the article once. The three social pieces took 40 minutes total. Here is the exact flow I use, and why cross-posting the same text everywhere fails.

Stop Cross-Posting, Start Reshaping

The mistake almost everyone makes is copy-paste. They write a blog post, grab the intro, drop it on LinkedIn, paste the same lines into X, and slap a screenshot on Instagram. Then they wonder why each one gets 12 likes.

The reason is simple. Each platform rewards a different shape of the same idea. LinkedIn readers scroll for a takeaway they can repeat in a meeting. X readers want to watch you think out loud, step by step. Instagram readers want a visual they can swipe through in eight seconds without reading much at all. Same argument, three completely different containers.

So the first move is not writing. It is extraction. I open the blog post and find the spine, which is the single sentence that the whole article is trying to prove. Not the topic, the claim. If the article is "SEO for Indie Creators," the topic is SEO but the spine might be "ranking pages beat viral posts because they earn for two years." That spine is the only thing all three platform pieces share.

I write that spine at the top of a blank note. Then I list the three or four supporting beats underneath it, the ones the article uses to make the case. For a 1,800 word post that is usually four beats. These beats become my raw material. I do not reuse sentences. I reuse the logic.

This is the part that separates a repurpose flow from a spam flow. When you reshape instead of copy, the LinkedIn version and the X version can both link back to the full article without feeling redundant, because neither one is the article. They are two arguments for reading it.

I learned this the hard way after months of cross-posting identical blocks and watching engagement flatline. The fix was not better writing. It was accepting that one piece of content is actually a source file, not a finished product. If you want the video version of this same idea, How to Repurpose One Video into 10 Pieces of Content with AI covers the equivalent flow for footage instead of text. Different inputs, same principle: extract the spine, reshape per channel.

The LinkedIn Version: Lead With the Lesson

LinkedIn rewards the takeaway up front. Nobody on LinkedIn is reading to be surprised at the end. They are scanning for a line worth saving.

So my LinkedIn version always opens with the spine, rewritten as a flat statement. From the SEO example: "Ranking pages earn for two years. Viral posts earn for two days. I keep choosing the slower one." That is line one. No throat-clearing, no "I've been thinking a lot about."

Then I structure the body as a short story or a list of three. LinkedIn formatting matters more than the words. One sentence per line. White space between every thought. The feed truncates around three lines, so the first three lines have to earn the "see more" click. I rewrite those three lines four or five times before I move on, because they do 80 percent of the work.

The middle is two of my four beats from the spine note, written as lessons I learned rather than facts I know. "I shipped 30 viral attempts before I understood this" beats "viral content is unreliable." Specifics and numbers. I pull real numbers from the article wherever I can. A LinkedIn post with one concrete figure outperforms a post full of advice.

The close is a single question. Not "what do you think," which gets nothing, but a specific fork. "Are you building for next week or next year?" That gives people something to answer in one word.

I drop the blog link in the first comment, not the post body, because LinkedIn suppresses posts with outbound links. The comment trick keeps reach while still routing traffic. I have watched the same post get triple the views when the link sits in comments instead of the caption.

The whole LinkedIn version runs maybe 180 words. It took longer to write than the X thread because LinkedIn is unforgiving about flabby lines. Every word has to defend its spot. If you want the reasoning behind shipping in batches instead of daily, Why I Ship Blog Articles in Clusters of 3 explains the cadence I build all of this around.

The X Thread: Show the Build, Not the Bow

X is the opposite of LinkedIn. LinkedIn wants the conclusion. X wants the process, the receipts, the "here is exactly how" walkthrough that reads like you are figuring it out in real time.

So my X thread takes the same spine but reorders it. The hook tweet is a result or a tension, never the lesson. "I posted the same blog to 3 platforms. One got 4,100 views. The other two got 30 combined. Here's what I changed." That sets up a thread people stay for because they want the resolution.

Then each beat from my spine note becomes one tweet. I keep tweets to two or three short lines. The thread is the only format where I can be granular, so I add the steps the blog post had to skip for length. Numbers, tool names, the exact order I did things. X readers reward specificity harder than any other platform. A vague thread dies in the first two tweets.

I cap most threads at six or seven tweets. Past that, the drop-off gets brutal. The last tweet always restates the spine as a one-liner and links the full article, because by then the reader trusts me enough to click. On X the link can go in the final tweet without much penalty, unlike LinkedIn.

The reshaping work here is turning declarative blog prose into conversational fragments. The blog says "I tested four scheduling tools." The thread says "Tested 4 schedulers. Three were bloated. One did the one thing I needed." Shorter, punchier, more opinionated. X tolerates and rewards a sharper voice than LinkedIn does.

For scheduling all of this, I run the queue through Buffer so the thread, the LinkedIn post, and the carousel all go out on staggered days from one dashboard. I do not post live. Posting live means I am at the mercy of whatever mood I am in. Queuing means the week ships whether I feel like it or not. My full automation stack lives in I Automated 90 Percent of My Content Pipeline With 4 Tools if you want the rest of the rig.

The Instagram Carousel: Make the Argument Visual

Instagram is the platform where the words almost stop mattering. A carousel lives or dies on slide one, the cover, which has to stop the swipe with a single bold line. Everything after that is momentum.

I take the spine and turn it into a six-to-eight slide arc. Slide one is the hook as a big statement: "1 blog post = 3 platforms = 0 extra writing." Slides two through six are one beat each, one idea per slide, almost no body text. Maybe a headline and one supporting line. The carousel is a slideshow, not an essay, and people swipe at speed.

The design has to be consistent. Same font, same two colors, same layout grid on every slide so it reads as one set. I build the slide backgrounds and any supporting visuals in Magnific when I need clean upscaled imagery that holds up at full resolution in the feed. Blurry slides get skipped. Sharp slides get saved, and saves are what Instagram actually rewards.

The last slide is the call to action, but soft. "Full breakdown on the blog, link in bio." Instagram punishes outbound links worse than any platform, so the carousel is a top-of-funnel grab. I am not expecting clicks. I am expecting saves and a couple of follows from people who liked the format.

The reshape here is the hardest, because text-heavy blog logic has to compress into eight visual beats. I cut ruthlessly. If a beat needs three sentences to land, it does not belong in a carousel, it belongs in the X thread. The carousel only carries ideas that survive being reduced to one line plus a graphic.

The caption gets one job: repeat the cover hook and ask for the save. "Save this for your next repurpose session." That single instruction lifts saves more than any clever caption. The visual already did the persuading. The caption just tells people what to do with it. The full deck takes about 15 minutes once the spine note exists, because I am arranging, not inventing.

Bottom Line

One blog post is not one piece of content. It is a source file. Pull the spine, the single claim the whole article proves, then reshape it three ways instead of copying it three times. LinkedIn gets the lesson up front. X gets the step-by-step build. Instagram gets the visual argument in eight swipes.

The whole flow is 40 minutes once the article exists, and most of that is the extraction note that all three pieces share. Write the spine and the four beats once, and the reshaping is fast because you are arranging, not creating.

Schedule the week in one block so it ships regardless of your mood. Then move on to the next article. This is the repeatable system I run every cluster, and it is one slice of the larger operating manual in the Claude Blueprint if you want to see how the writing, the repurposing, and the scheduling fit into one solo pipeline. Start with your next post. Find the spine before you write a single social caption.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Anthropic Pulled Fable 5 and Mythos 5: What the Ban Means

RAXXO Studios — Mon, 15 Jun 2026 13:18:54 +0000

Anthropic disabled Fable 5 and Mythos 5 on June 12 after a US government export-control order
The order bars foreign nationals, so every customer lost access while compliance is sorted out
The trigger was a narrow jailbreak that asked the model to fix flaws in a codebase
Opus 4.8 and every other Claude model still work, so that is where I moved my pipelines

Six days after I started routing real work to Claude Fable 5, it vanished. On June 12 Anthropic disabled both Fable 5 and Mythos 5 worldwide, and the reason is not a billing glitch or a quiet deprecation. A US government directive forced the shutdown. Here is what actually happened, why it happened, and the calm fallback I used so none of my projects stalled.

What actually happened

Anthropic launched Fable 5 and Mythos 5 on June 9, the first public models in the new Mythos class. Fable 5 was free on Pro, Max, and Enterprise plans through June 22, it was rolling out across platforms including AWS Bedrock, and the paid pricing was set to kick in on June 23. So a lot of people, me included, spent that week pushing it hard on coding and long-context tasks while it cost nothing. Three days later it was gone.

In its public statement, Anthropic says it received a government directive on June 12 at 5:21pm Eastern. The company describes it as an export-control directive citing national security authorities. The order bars all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States, and that explicitly includes Anthropic's own foreign-national employees.

The practical problem is that you cannot cleanly separate every foreign national from a live consumer product on a few hours of notice. Citizenship is not a field most chat sessions or API keys carry. So the net effect, in Anthropic's own words, is that it had to abruptly disable Fable 5 and Mythos 5 for all customers to stay compliant. Not foreign users only. Everyone. If you had a chat open or an API job queued against either model, it stopped mid-flight, and the model picker simply dropped the options.

One detail matters for anyone in a panic: every other Claude model is fine. The directive names Fable 5 and Mythos 5 specifically, so Opus 4.8, Sonnet, and Haiku kept running without interruption. I cover the model that absorbed my workload in Claude Opus 4.8 Is Here, and that piece turned into my recovery plan within the hour.

Why the government stepped in

The trigger was a jailbreak. Governments worry that a frontier model can be talked into helping with things it should refuse, and the concern here centers on cyber capability: could someone coax Fable 5 into finding and exploiting software vulnerabilities at a level that changes the threat picture for everyone defending real systems.

Anthropic's account of the demonstrated technique is narrower than the headline suggests. As the company describes it, the jailbreak involved asking the model to read a codebase and fix software flaws, and the flaws it surfaced were minor and already known. Anthropic calls it a narrow, non-universal jailbreak, language that does a lot of work. Narrow means it did not generalize into a master key for arbitrary harmful requests. Non-universal means it did not reliably reproduce across prompts and contexts. In plain terms, the company is arguing this was a corner case, not a kicked-in door.

That framing lines up with how the Mythos class was sold at launch. The whole pitch was that Mythos-grade capability ships with extra safeguards, including a classifier that can fall back to a safer response on sensitive cyber and bio prompts. I walked through that safety architecture in Claude Fable 5 Is Here. A model marketed on its safeguards getting pulled over a safeguard gap is the kind of irony that makes a story travel, and it traveled fast.

I am not going to pretend I can grade the actual risk. I cannot see the red-team report and neither can you. What I can say is that a three-day-old model sitting at the absolute frontier of coding ability is exactly the kind of thing a security agency reacts to fast, and reacting fast tends to mean a blunt instrument rather than a scalpel. A blanket suspension is the bluntest instrument there is.

What it means if you were using it

If you built anything on Fable 5 in that first week, treat it as offline and do not wait for it to blink back on. The honest move is to assume an outage measured in weeks, not hours, and route around it today rather than refreshing a status page.

For most tasks the swap is painless because the gap between tiers is smaller than the launch benchmarks implied in daily use. Fable 5 was the sharper instrument on the hardest coding problems, and it topped the toughest coding benchmarks at launch, but Opus 4.8 already handled the bulk of my real work and it never went anywhere. I moved my agent loops, my blog generation, and my code review passes straight back to it by swapping a single model name in my config. Nothing else changed. If you are weighing the two tiers for the long run, I put them head to head in Claude Fable 5 vs Opus 4.8, and the short version is that the cheaper tier wins more often than the spec sheet suggests, since Fable 5 listed at roughly twice the price of Opus 4.8 per token once the free window closed.

There is a quieter lesson here about dependency. I had been tempted to hard-wire a few automations to Fable 5 because it was free through June 22 and genuinely strong on agentic coding. Good thing I did not. When a model can disappear on a government's timetable rather than a vendor's roadmap, you want every pipeline to fall back to a second model with one config change instead of a rewrite. Mine did, so my Monday looked completely normal while the news cycle did not. That is the entire payoff of building model choice into your tooling rather than betting a workflow on one specific name that happened to be hot that week.

Where it stands now and what I am doing

As of today the models are still down. Anthropic has not restored access, and it has framed the whole episode as a likely misunderstanding. The company says it is working to bring access back as soon as possible and has reportedly sent senior technical staff to Washington for meetings with White House officials to argue that the cited jailbreak does not justify a blanket ban. No firm restoration date has been given, and the reporting I trust suggests it could take weeks rather than days, with enterprise customers being told to plan around the absence rather than wait it out.

My plan does not depend on any of that resolving. I am keeping production work on Opus 4.8, which is unaffected and already proven in my stack, and I am treating Fable 5 as a nice-to-have that has to re-earn trust before it touches anything that matters. I am not rebuilding around it until it is back and stable for at least a couple of weeks, because a model that came and went once can do it again on the same kind of notice. And I am watching the policy side more closely than the model side, because the precedent is the real story. A capable model was switched off by directive, not by deprecation, and that is a new variable every builder now has to price into how they choose a default model.

If you only take one action from this, make it boring and useful: confirm that every automation you run can name a fallback model and switch to it without a human in the loop. I keep that wiring documented as part of my Claude Blueprint, and this week is the clearest argument I have ever had for why it belongs there.

Bottom Line

Fable 5 was the most capable coding model I had ever pointed at my own repos, and it lasted six days before a government order took it offline for everyone. The cause was a narrow jailbreak involving code-flaw fixing, the scope was a foreign-national export restriction that Anthropic could only honor by disabling the models for all customers, and the current status is still dark with no promised return date. None of that touched Opus 4.8, which is why my work never stopped for a minute. The takeaway is not which model is best this month. It is that any single model can vanish on someone else's schedule, so the resilient setup is the one that shrugs and switches. If you want the version of that setup I actually run, start with the Claude Blueprint and wire a fallback before you need one.

Loading Skeletons That Don't Lie: 5 Patterns for Honest Perceived Performance

RAXXO Studios — Mon, 15 Jun 2026 13:18:18 +0000

Content-shaped skeletons cut layout shift to zero versus 0.18 CLS for spinners
Match placeholder dimensions to final DOM exactly or you are lying to users
Spinners beat skeletons under 300ms and for unknown-shape content
Streaming SSR makes the skeleton honest about what is actually arriving

I rebuilt the loading states on my storefront and watched cumulative layout shift drop from 0.18 to 0.00 on the product grid. The fix was not faster code. It was honest placeholders that matched the final layout pixel for pixel. Here is what actually worked.

A Skeleton Lies When It Does Not Match the Final Layout

Most skeleton screens are decorative. They show three grey bars where the real content has two lines and an image, then the page snaps into a totally different shape when data lands. That snap is a layout shift, and it is the single most annoying thing a loading state can do. The user reads the skeleton, builds a mental model, and then the model is wrong.

The rule I follow now: a skeleton placeholder must occupy the exact same box as the content it replaces. Same height, same width, same number of lines, same image aspect ratio. If the product card is 320 pixels tall with a 1:1 image and two text lines, the skeleton is 320 pixels tall with a 1:1 grey block and two grey lines. No more, no less.

This means I stopped building generic skeleton components. A reusable `that renders "three bars" is a trap because it never matches anything. Instead I build a skeleton per layout. The product card has aProductCardSkeleton. The article header has anArticleHeaderSkeleton`. Each one is the real component with the data swapped for grey shapes, sharing the same CSS grid and the same fixed dimensions.

Here is the measurement that convinced me. Before, my product grid scored 0.18 CLS in Lighthouse, mostly from images loading without reserved space and text reflowing. After matching skeleton boxes to final boxes and reserving image dimensions with aspect-ratio, CLS hit 0.00 on three test pages in a row. The grid does not move when data arrives. It just fills in.

The honesty principle goes deeper than dimensions. If you show four skeleton cards but the response returns six items, you taught the user to expect four. Pull the skeleton count from the same source as the real count when you can, like a cached previous page length or a known page size. A skeleton that promises four and delivers six is a small lie, and small lies in UI add up to distrust.

Match the Box: aspect-ratio and Reserved Space Beat Spinners

The mechanical part of zero layout shift is reserving space before anything loads. Images are the worst offenders. An `` with no width and height collapses to zero height, then jumps to full height when the file decodes. The browser cannot reserve space it does not know about.

Two lines fix most of this. Set aspect-ratio on the image container and width: 100% on the image:


.card-image {
  aspect-ratio: 1 / 1;
  width: 100%;
}

Now the box holds its shape from first paint. The skeleton fills that box with a grey block of identical ratio, and when the real image decodes it slots in without moving a pixel. I do the same for text blocks using fixed line counts and min-height so a two-line title placeholder cannot become a three-line title.

The shimmer animation is where people go wrong. A diagonal gradient sweeping across the grey is fine, but it must respect motion preferences. I gate every shimmer behind a media query:


@media (prefers-reduced-motion: reduce) {
  .skeleton { animation: none; }
}

Without that, you are pushing a moving gradient at people who explicitly asked their operating system for less motion. That is an accessibility failure, and it is two lines to fix.

There is also a performance cost to shimmer that nobody talks about. Animating background-position on a hundred skeleton elements forces repaints. On a low-end Android device my old shimmer dropped the loading state to 22 frames per second. Switching to a single CSS variable driving one keyframe, and animating opacity on a pseudo-element instead of background position, brought it back to 60. The loading state should not be the slowest part of the page.

I store the skeleton dimensions in the same place as the layout tokens. The card height, the image ratio, the gap, all live as CSS custom properties that both the skeleton and the real card read. When I change the card height, both update together. They cannot drift apart because they share one source. If you want the deeper context on reserving storefront layout early, see Shopify Section Rendering API.

When a Spinner Actually Beats a Skeleton

Skeletons are not universally better. I see teams force skeletons onto everything because they read one article calling spinners outdated. That is wrong. A spinner wins in three concrete situations.

First, sub-300ms loads. If your data comes back in 180ms, a skeleton flashes for a tenth of a second and the flash itself reads as a glitch. Below roughly 300ms, showing nothing is better than showing a skeleton that vanishes before the eye registers it. I delay loading states by 200ms so fast responses never show a placeholder at all. The content just appears, which is the best possible outcome.

Second, unknown-shape content. A skeleton only works when you know the layout in advance. If the response could be a list, a single card, an error, or an empty state, you cannot draw a matching placeholder. Drawing a guess means you will almost certainly draw a lie. A centered spinner makes no claim about shape, so it cannot mislead. For search results where I do not know if zero or fifty items come back, I use a spinner, then render the real layout once I know the count.

Third, full-page transitions and actions like "saving" or "processing payment". Nobody expects a skeleton of a button they just clicked. They expect feedback that the system heard them. A small inline spinner on the button is the honest signal. A skeleton there would be absurd.

The decision tree I use is simple. Do I know the exact final layout? If no, spinner. Is the load likely under 300ms? If yes, delay then show nothing or spinner. Is it a known content shape over 300ms? Skeleton. Is it a discrete action with no layout? Inline spinner.

The mistake is treating the choice as fashion. It is an information question. A loading state communicates "what is coming and roughly how big". A skeleton answers that precisely. A spinner answers "something is coming, shape unknown". Pick the one that tells the truth about what you actually know. When you genuinely do not know the shape, pretending you do is the lie.

Streaming SSR Makes the Skeleton Honest About Timing

The most honest skeleton is one that disappears section by section as real data streams in, not one big swap at the end. Streaming server-side rendering makes this possible. The server sends the page shell immediately, holds open the connection, and flushes each slow section as its data resolves.

In practice the fast parts of my page (header, navigation, static product details) render instantly with real content. The slow part (personalized recommendations that hit a separate service) shows a skeleton until its data arrives, then streams in and replaces only that region. The skeleton is honest because it covers exactly the part that is genuinely still loading, not the whole page that already finished.

React Server Components with Suspense boundaries handle this cleanly. You wrap the slow component in }> and the framework streams the fallback first, then the real markup. The key detail most people miss: the fallback skeleton must match the resolved component dimensions, or the stream-in causes a layout shift and you have undone all your CLS work. Honesty and zero shift are the same goal.

I measured the difference on a product page. Without streaming, time to first contentful paint was 1.4 seconds because the whole page waited on the recommendation service. With streaming, FCP dropped to 0.3 seconds because the shell and main product rendered immediately, and only the recommendation strip showed a skeleton for the remaining 1.1 seconds. The user reads the product while the slow part loads behind a placeholder.

This is where skeletons earn their reputation. A skeleton that covers a section the server has already finished rendering is theater. A skeleton that covers the one section still waiting on a slow upstream call is an accurate status report. Streaming lets you draw the line in exactly the right place.

One caveat: streaming adds complexity to error handling. If the recommendation service times out, the skeleton must resolve into an error or empty state, never spin forever. I set a hard timeout and a fallback empty state so a stuck stream never leaves a skeleton shimmering into eternity. A skeleton with no exit is the worst lie of all, promising content that will never come.

Bottom Line

Honest loading states come down to one idea: never show a placeholder that contradicts what arrives. Match the box exactly so there is zero layout shift. Reserve image space with aspect-ratio. Gate shimmer behind prefers-reduced-motion. Use a spinner when you do not know the shape or the load is under 300ms, and a skeleton only when you know the layout in advance. Stream SSR so the skeleton covers the part that is genuinely still loading and nothing else.

I run all of this on a Shopify storefront, and the CLS drop from 0.18 to 0.00 was the most visible single win. The patterns are framework-agnostic though. Any stack with reserved dimensions and streamed sections can do the same.

If you want the system I use to keep these UI rules consistent across an entire site, the Claude Blueprint walks through how I document layout tokens and component contracts so skeletons and real content never drift apart. Start with one component, measure CLS before and after, and let the number prove it.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Headless Claude Code: 5 Things I Run From My GitHub Actions

RAXXO Studios — Fri, 12 Jun 2026 00:20:05 +0000

Claude Code -p runs headless in CI with zero terminal
Blog generation, daily audit, PR triage, release notes, README sync all on cron
Each run costs 0.10 to 0.60 EUR depending on context size
Pin the CLI version and cache state or you will burn tokens

I run five jobs from GitHub Actions that used to sit on my laptop. No terminal open, no me watching a progress bar. Claude Code in headless mode does the work on a schedule and opens a pull request when it has something to show me. Here is exactly what runs, what it costs, and the parts that broke before they worked.

Why headless Claude Code beats a local terminal

Most people use Claude Code interactively. You open a terminal, type a request, watch it edit files, approve a diff. That is fine for one-off work. It does not scale to anything that needs to happen every day at 6am while I am asleep.

The trick is the -p flag. It runs Claude Code in print mode: you pass a prompt, it does the work, it prints the result, and it exits. No interactive session, no approval prompts. That makes it a normal command line tool, which means GitHub Actions can run it the same way it runs a test suite.

A minimal job looks like this. You install the CLI, set your API key as a secret, and call it with a prompt.


- run: npm install -g @anthropic-ai/claude-code
- run: claude -p "Read CHANGES.md and write release notes to RELEASE.md"
  env:
    CLAUDE_KEY: ${{ secrets.CLAUDE_KEY }}

That is the whole pattern. Everything else is variations on it. The job clones my repo, Claude reads files and writes files, and a later step commits the changes or opens a pull request.

The reason this matters is consistency. When work depends on me remembering to run a script, it happens maybe three times a week. When it runs on a cron trigger, it happens 365 days a year without a single missed day. My daily audit has run 90 times in a row now. I would have skipped at least 40 of those by hand.

Costs are lower than people expect. A typical headless run uses between 15,000 and 80,000 tokens depending on how much context it reads. That lands between 0.10 and 0.60 EUR per run. My five jobs combined cost under 12 EUR a month. The GitHub Actions minutes are free for the volume I use.

The one mental shift: headless Claude cannot ask you questions. If it gets confused, it guesses and moves on. So your prompts have to be more precise than they would be in a chat. I write them like specs, not like requests. If you want the full setup behind all of this, the Claude Blueprint walks through the foundation.

Blog generation and the daily audit

Two of my five jobs touch this site directly. The first generates blog drafts. The second audits what is already published.

The generation job runs three times a week. It pulls a topic from a queue file, reads three existing articles for voice reference, and writes a full draft following a structure spec. The output goes into a pull request, never straight to publish. I read every draft before it goes live, because headless mode will confidently produce a paragraph that is technically wrong if the prompt leaves room.

The prompt for this job is long, around 600 words. It includes the word count target, the section structure, the banned words, and three example openings. The more I front-load into the prompt, the less I fix afterward. When I started, I gave it two sentences of instruction and spent 20 minutes editing each draft. Now the prompt does the heavy lifting and I spend 4 minutes.

The daily audit is the job I am proudest of. Every morning at 7am it reads my last 10 published articles and checks them against a rule list: broken internal links, missing affiliate disclosures, headings out of order, word counts that drifted out of range. It writes a report to a markdown file and, if it finds something broken, opens an issue with the specific fix.

In 90 days it has caught 31 real problems. Eleven were dead internal links where I renamed a handle and forgot to update the references. Nine were articles that drifted under my word floor. The rest were formatting drift. None of those would I have found by hand, because who re-reads their own archive every morning.

The audit costs more than the other jobs because it reads more files. A full run is around 70,000 tokens, so about 0.50 EUR. Over a month that is 15 EUR for a job that has saved me from publishing broken links 31 times. Easy trade.

One gotcha: the audit used to read every article in the repo, which pushed token use past 200,000 and the cost past 1.50 EUR per run. I capped it at the 10 most recent files by modified date. Same value, a fifth of the cost. If a job feels expensive, the answer is almost always "you are feeding it too much context."

PR triage and release notes

The third and fourth jobs handle the boring parts of maintaining the repo itself.

PR triage runs whenever a pull request opens. Most of my pull requests come from the blog generation job, but I also get the occasional manual one. The triage job reads the diff, checks it against my rules, and posts a comment summarizing what changed and whether anything looks off. For a blog draft it confirms the word count is in range and the internal links resolve. For a code change it flags anything that touches secrets or the publish flow.

This is not code review in any deep sense. It is a first-pass filter that catches the obvious stuff so I do not have to. The comment shows up within 90 seconds of the pull request opening. By the time I look at it, the summary is already there.


on:
  pull_request:
    types: [opened, synchronize]
jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @anthropic-ai/claude-code
      - run: claude -p "Review the diff in this PR against the rules in RULES.md. Post a 5-line summary." 
        env:
          CLAUDE_KEY: ${{ secrets.CLAUDE_KEY }}

Release notes are the fourth job. Every time I tag a version, this job reads the commit messages since the last tag, groups them by type, and writes human-readable release notes. My commit messages are terse and ugly. The release notes that come out are clean and grouped under headings like "Fixes" and "New." It turns "fix typo in audit prompt lol" into a proper changelog entry without me thinking about it.

The cost here is tiny, around 0.10 EUR per run, because commit messages are short. This job has written 14 release entries. I have edited exactly two of them. The rest shipped as written.

The biggest gotcha across both jobs is permissions. GitHub Actions needs explicit write permission to post comments and commit. I lost an hour to a job that ran perfectly but silently failed to post because the workflow had read-only token scope. Add permissions: pull-requests: write and contents: write at the job level. If you schedule social posts off the back of a release, Buffer takes a webhook and handles the queue.

README sync and the gotchas that cost me money

The fifth job keeps my README honest. Documentation drifts. You change a flag, you add a script, you rename a folder, and the README quietly becomes a lie. This job reads the actual project structure and the current scripts, then rewrites the relevant README sections to match reality.

It runs weekly. It opens a pull request with the diff so I can see exactly what changed before it lands. About one week in three it has a real change. The other weeks it opens nothing, which is the correct behavior. A job that does nothing when there is nothing to do is a good job.

Now the gotchas, because these cost me real tokens before I fixed them.

First, pin the CLI version. I ran npm install -g @anthropic-ai/claude-code with no version, and one morning a new release changed the default model and my token use jumped 40 percent overnight. Pin it: @anthropic-ai/claude-code@2.0.1. Upgrade on purpose, not by accident.

Second, cache nothing you do not understand. I tried caching Claude's internal state between runs to save context reads. It saved tokens but produced stale output because the cache held a version of a file that had changed. For these jobs, fresh reads every time are worth the extra 0.05 EUR. Cache the npm install, not the reasoning.

Third, set a hard timeout. A headless job that gets stuck in a loop will keep calling the API until something stops it. I add timeout-minutes: 10 to every job. One runaway run cost me 3 EUR before the timeout existed. Now the worst case is bounded.

Fourth, never let a headless job publish without a human gate. Every one of my five jobs either opens a pull request or writes a draft. None of them push to production directly. Headless Claude is good, not perfect, and the cost of a bad article going live is much higher than the cost of me reading a draft for 4 minutes.

Fifth, log the token count. Claude Code prints usage at the end of a run. Pipe it to a file and check it weekly. That is how I caught the version bump that doubled my costs. Visibility is the whole game when the work happens while you sleep.

Bottom Line

Headless Claude Code turned five chores I used to skip into five jobs that run themselves. The blog drafter, the daily audit, the PR triage, the release notes, and the README sync cost me under 12 EUR a month combined and save me hours I was not spending anyway, because half of them I simply never did by hand.

The pattern is the same every time: install the CLI, pass a precise prompt with -p, write the output to a file, open a pull request, keep a human gate before anything ships. Pin your version, set a timeout, log your tokens, and feed each job the smallest amount of context that still does the work.

If you want the full foundation behind how I run Claude as infrastructure rather than a chat window, the Claude Blueprint is where I keep the setup. Start with one job. The daily audit is the easiest win and the one most likely to catch something embarrassing before your readers do.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Why I Stopped Using Cursor for Production Code (And What I Use Now)

RAXXO Studios — Thu, 11 Jun 2026 00:17:18 +0000

Cursor felt fast for prototypes but stalled on real production tasks
Claude Code hooks let me automate checks before every commit
Skills and plugins turned a chat tool into a real pipeline
I shipped 14 product launches in one quarter with the new setup

I ran my entire studio on Cursor for about eight months. Then I switched to Claude Code and shipped 14 product launches in a single quarter, more than I managed in the previous three combined. This is the honest version of why I left and what actually changed.

What Cursor Did Well And Where It Broke

Cursor is a genuinely good editor. I want to say that up front because the internet loves a clean villain and Cursor is not one. For prototyping it is excellent. I would open a fresh file, describe a small feature, and watch it scaffold something usable in under a minute. The tab completion is sharp. The inline edit feature, where you highlight a block and ask for a change, saved me real time on small refactors.

The problem started when my projects grew past the toy stage. My main Shopify backend has about 40 files that all touch each other. Product sync, image pipelines, scheduling logic, the blog publisher. Once a codebase reaches that size, the editor needs to understand relationships, not just the file in front of it. Cursor would confidently edit one file and quietly break two others. It did not know my conventions. It did not run my tests. It treated every request as a fresh conversation with no memory of the rules I had set up the day before.

I started keeping a text file open with my own rules, pasting it into the chat every session. Naming conventions, the fact that I never use em dashes in output, the currency formatting I require, the list of words my publish script blocks. Every single session I pasted this. After two months of pasting the same 600 words I realized I had built a manual workflow around a tool that was supposed to remove manual work.

The breaking point was a Friday in March. I asked Cursor to add a field to my product schema. It updated the schema, missed three call sites, and I pushed broken code that took a live page down for 20 minutes. Not catastrophic. But it was the third time that month. The tool was fast at writing and slow at being correct, and for production work correct is the only speed that counts. I stopped trusting it for anything I planned to ship.

How Claude Code Hooks Changed My Daily Work

The single feature that moved me was hooks. Claude Code lets you define commands that fire automatically at specific moments. Before a tool runs, after it edits a file, before a commit. This sounds small. It is the whole game.

I set up a hook that runs my linter and word checks every time a file gets written. Now when the model edits my blog publisher, the hook immediately runs my forbidden-words scan and flags any em dash or blocked term before I ever see the output. The error comes back into the conversation and Claude fixes it on the spot. No manual paste. No friday afternoon outage. The rules live in the project, not in my memory.

I have a second hook that runs my test suite after any change to the schema files. If a field gets added and three call sites break, the tests fail, the failures land back in the session, and the fix happens in the same loop. The thing that took my site down in March is now caught in about four seconds, automatically, every time.

This is the difference between an editor and a system. Cursor wrote code into my files. Claude Code participates in my actual process: write, check, fix, verify, then move on. I went from pasting 600 words of rules per session to defining them once in a config and forgetting about them.

If you want the deeper context on the full setup, Claude Code Desktop Full IDE Rebuild goes through how I wired the whole thing together. The short version: my rules became infrastructure. A new project inherits the same hooks the moment I clone my template. The forbidden words, the currency format, the test gates, all of it loads automatically.

The honest tradeoff is setup cost. Hooks take an afternoon to configure properly the first time. Cursor needs zero setup. But I run my studio for years, not for one afternoon, and the math favors the tool that pays me back every single day after that first afternoon.

Skills And Plugins Turned It Into A Pipeline

Hooks fixed correctness. Skills and plugins fixed scope. A skill in Claude Code is a packaged capability you teach once and reuse forever. I built a skill for my blog format, the exact structure you are reading now. TLDR div on line one, four H2 sections, a bottom line, internal links, affiliate placement. I no longer explain the format. I say "write a lab article on X" and the skill carries every rule.

I built another skill for my product launch checklist. When I drop a new design into the system, the skill knows the sequence: generate the mockups, upscale the hero image, write the listing, schedule the social posts, update the index. Each step that used to be a separate tool sits inside one reusable capability now.

The image step runs through Magnific for upscaling because my source art comes out at low resolution and needs to be print-ready. The social scheduling step hands off to Buffer so a launch fans out across platforms without me opening five tabs. Claude Code orchestrates the whole chain. Cursor never tried to be this. It is an editor and it stays in its lane, which is fine, but my work is not editing. My work is shipping finished products end to end.

Plugins extend this further. I run my Shopify store operations through a plugin that lets the model read and write product data directly. That means a launch goes from idea to live listing inside one session, with the test gates and word checks firing the whole way. The 14 launches I mentioned came out of this exact pipeline. Each one would have been a half-day of manual stitching in my old setup. Now most take under an hour of my actual attention.

The lesson I keep relearning: the tool that wins is not the one with the slickest autocomplete. It is the one that lets me encode my process so I stop repeating myself. Cursor optimized for the keystroke. Claude Code optimized for the workflow, and the workflow is where solo studios live or die.

When I Would Still Reach For Cursor

I am not going to pretend Claude Code wins everything, because that is the kind of post that ages badly and helps nobody. There are cases where I would still open Cursor today.

If I am learning a new framework and I want to poke at it interactively, Cursor's inline editing and instant completion are lovely. The feedback loop is tight. I can type half a thought and see it finished. For pure exploration where correctness does not matter yet, the fast loop beats the structured one. I keep Cursor installed for exactly this.

If you work on a large team with an established editor culture, the calculus also shifts. My whole argument rests on being solo. I define the rules, I own the hooks, I never have to negotiate conventions with five other developers. A team has different friction, and an editor everyone already knows has real value that a single-operator workflow does not capture. I am describing what works for one person running an entire studio, not issuing a universal verdict.

And if your projects genuinely stay small, Cursor's zero setup is a feature, not a gap. The hook system I love is overhead you do not need if your codebase is three files that never break each other. I would have told my eight-months-ago self to stay on Cursor a while longer, honestly. The switch only pays off once your work outgrows the single-file mindset.

What pushed me over was the combination: production stakes, solo ownership, and a process complex enough to be worth encoding. When all three are true, hooks and skills stop being nice extras and become the reason the studio runs at all. Background: Claude Code Desktop Full IDE Rebuild walks through the moment those three lined up for me and the setup decisions I made.

So I keep both tools. I just use them for what each is actually good at, and the heavy production work all flows through the structured one now.

Bottom Line

I left Cursor because my work changed, not because the tool got worse. Prototyping rewards speed and a tight feedback loop, and Cursor is excellent there. Production rewards correctness, repeatable process, and a system that remembers my rules so I do not have to. Hooks caught the bugs that took my site down. Skills packaged my formats so I stopped explaining them. Plugins connected the model to my actual store, and 14 launches in a quarter came out the other side.

If you run a solo operation and you keep pasting the same rules into a chat box every morning, that is the signal. Encode it once. Let the tool check itself. The afternoon you spend on setup pays back every day after.

If you want the full picture of how I wired my studio around this, the Claude Blueprint lays out the hooks, skills, and project structure I use end to end. Start small, automate the check that keeps biting you, and build from there.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)

Claude Fable 5 Is Here: The First Public Mythos-Class Model

RAXXO Studios — Wed, 10 Jun 2026 07:06:42 +0000

Anthropic released Claude Fable 5 on June 9, 2026, the first Mythos-class model anyone can use
Pricing doubles Opus 4.8: 10 dollars per million input tokens, 50 out, free on paid plans until June 22
Cyber, bio, and distillation prompts get answered by Opus 4.8 instead, under 5 percent of sessions
SWE-Bench Pro hits 80.3 percent vs 69.2 for Opus 4.8, and Stripe ran a 50-million-line migration in a day

Anthropic put a model above Opus on the shelf. On June 9, 2026 it released Claude Fable 5, the first Mythos-class model available to everyone with an API key, alongside Claude Mythos 5 for a restricted partner circle. I switched my whole studio pipeline to Fable 5 on launch morning. This is what shipped, what it costs, and where the catch is.

What Anthropic Shipped on June 9

Two models, one underlying brain. Claude Fable 5 is the public release. Claude Mythos 5 is the same model with fewer safeguards, reserved for vetted partners. Mythos is not a codename, it is a new model class that sits above Opus in Anthropic's lineup, the way Opus sits above Sonnet. Fable 5 is that class made safe enough to hand to everyone.

The model ID is claude-fable-5. It carries a 1 million token context window and up to 128K output tokens, same envelope as Opus 4.8. Pricing is 10 dollars per million input tokens and 50 per million output. That is exactly double Opus 4.8, which stays at 5 and 25.

Availability moved fast. The API had it on day one. GitHub Copilot flipped it to generally available the same day, Amazon Bedrock listed it, and Claude Code picked it up immediately (this article was produced on it). For subscribers the deal is unusually good: Pro, Max, Team, and seat-based Enterprise plans include Fable 5 at no extra cost from June 9 to June 22. From June 23 it needs usage credits, with a return to standard plans promised once capacity allows. If you pay for Claude, you have a two-week window to test the strongest model Anthropic has ever shipped without spending anything extra.

For developers the migration is one line, with one trap. Fable 5 keeps the Opus 4.8 request surface: adaptive thinking, no sampling parameters, effort levels from low to max. The trap is that an explicit thinking disabled setting now returns a 400 error. Opus 4.8 tolerates it, Fable 5 does not, so omit the field instead and audit any shared request builder before you swap the ID.

Back in May I sorted through the leaks and guesses in Claude's Next Model: Sonnet 4.8 and Mythos Rumors, Sorted. The short version: the Mythos rumors were real, and the public version arrived faster than I expected.

From Locked Lab to Public Release

Fable 5 did not appear from nowhere. In April, Anthropic started Project Glasswing and handed the first Mythos-class model, Claude Mythos Preview, to a small group of cyber defenders and critical infrastructure providers. I covered the program in Project Glasswing: Anthropic's Claude Mythos Cybersecurity Bet and the unusual logic behind it in Anthropic Just Gave 12 Companies Their Most Dangerous AI Model. On Purpose.

That program just scaled. Glasswing now spans roughly 150 organizations across more than 15 countries, and those partners get Mythos 5 with the cyber safeguards lifted. Selected biology researchers are next in line, with the bio and chemistry restrictions removed for vetted labs. A broader trusted-access program is planned after that.

The pricing tells its own story: Fable 5 and Mythos 5 cost less than half of what Mythos Preview did. Anthropic is moving this class from experiment to product.

The timing raised eyebrows. The release landed days after Anthropic published warnings about AI capabilities becoming dangerous, and the press read it as a contradiction. I read it differently. The two-tier release is the answer to their own warning: ship the capability, gate the dangerous slices, and put the ungated version behind vetting. Whether that holds up is a separate question, but it is a coherent position, not an accident.

One more piece that matters if you run client work through the API: all Mythos-class traffic has a 30-day retention window, is not used for training, and every human access to that data gets logged.

The Opus Handoff: How the Safeguards Work

This is the genuinely new mechanism, and it is the part most coverage gets wrong. Fable 5 does not simply refuse risky requests. Separate classifier models watch every conversation, and when one detects a request in three specific areas, the response is generated by Claude Opus 4.8 instead of Fable 5.

The three trigger areas: cybersecurity (vulnerability discovery, exploitation, agentic hacking, attack planning), biology and chemistry around dual-use research, and distillation attempts, meaning prompts designed to extract the model's capabilities to train a competitor.

Anthropic says the classifiers trigger in under 5 percent of sessions on average. They are tuned conservatively, which means some harmless requests get the downgrade too, and the stated goal is to cut those false positives now that it is live.

The jailbreak numbers are worth quoting. Over 1,000 hours of internal and external bug bounty testing produced no universal jailbreak. Across 30 different public jailbreak techniques on cyberattack tasks, Fable 5 complied with zero harmful single-turn requests. External red teams found the same wall, with the UK AISI making only initial progress on long-form agentic tasks. One external partner called these the toughest cyber safeguards of any model they had tested.

The gap being protected is real. On ExploitBench, the unrestricted Mythos 5 scores 78 percent against 40 percent for Opus 4.8. That is the capability Anthropic decided not to hand out with an API key.

What the Extra Tier Buys

The benchmark sweep is broad, so I will stick to the numbers that changed my routing. SWE-Bench Pro, which tests real GitHub engineering tasks, lands at 80.3 percent for Fable 5 against 69.2 for Opus 4.8, 58.6 for GPT-5.5, and 54.2 for Gemini 3.1 Pro. On Cognition's FrontierCode, the hard production-standard set, Fable 5 scores 29.3 against Opus 4.8's 13.4. More than double on the tasks that actually hurt.

Outside coding: first model past 90 percent on the Core Analytics benchmark, a 10-point jump over Opus. Top score on the Hebbia finance benchmark for document and chart reasoning. On an everyday spreadsheet suite it beats Opus 4.8 at every effort level while finishing 25 to 30 percent faster.

The customer stories land harder than the benchmarks. Stripe compressed a Ruby migration across a 50-million-line codebase, previously scoped at months of engineering, into a single day. Cursor's CEO called it state of the art on their internal benchmark and said it opened long-horizon problems that were previously out of reach.

Two capabilities stand out as actually new. Vision: Fable 5 rebuilt working web app source code from screenshots, pulled precise numbers off scientific figures, and beat Pokemon FireRed using a vision-only harness, something earlier models needed helper tools for. And memory: on long Slay the Spire runs, persistent memory improved its performance 3 times more than it did for Opus 4.8, and it reached the final act 3 times more often.

The science results read like a different product category. Internal experts report drug design work running about 10 times faster, with 9 of 14 protein targets yielding strong candidates. In blinded comparisons, its molecular biology hypotheses were preferred about 80 percent of the time over Opus-class output, and one of those hypotheses was later corroborated by an independent published study. In genomics it ran a week of autonomous research and trained a custom model 100 times smaller than a Science-published baseline while outperforming it. Anthropic describes the level as senior research scientist, picking directions and allocating resources, and for the first time that claim does not read as pure marketing.

Bottom Line

Fable 5 is the new ceiling, and for once the ceiling is not locked behind a waitlist. The two-week free window on paid plans (June 9 to 22) is the right time to find out what it does to your own workload, because after June 23 every run costs credits.

My early read after a day of real use: the jump is visible on long autonomous tasks and barely visible on routine ones, which is exactly what the benchmark spread predicts. Opus 4.8 does not retire, it becomes the value pick, and I will publish the full head-to-head routing math separately. For the baseline of what Opus 4.8 brought three weeks ago, start with Claude Opus 4.8 Is Here: Everything That Changed.

If you want the Claude Code setup I ran this launch-day test on, hooks, commands, and guardrails included, it ships as Claude Blueprint.