Ryan Skidmore

Tokenomics: the 62.5-minute rule for Claude's cache

Ryan Skidmore — Sun, 17 May 2026 00:00:00 GMT

import CacheRefreshChart from '../../components/CacheRefreshChart.astro'; import CacheCompactionChart from '../../components/CacheCompactionChart.astro';

Unfortunately one of the downsides of being a chronic tokenmaxxer is regularly hitting 5-hour and weekly token limits across several providers. This often comes at the most inconvinient time possible when you're in the middle of something and ideally I'd prefer to not spend any more money on additional AI subscriptions if possible. I started looking a little more closely at my request logs to see if this was a skill issue and I noticed that I'm writing my entire context (which can be as high as 400k/500k in some sessions) to the cache a little more often than I should be. Each write was pretty small in isolation, but added up pretty quickly.

5 minutes really isn't a long time, so it's easy to get distracted and miss the cache refresh and pay for the full prefix write. This got me thinking, if a prompt cache is about to expire and I don't have a real request to send, is it cheaper to ping it with a keep-alive, or let it die and rewrite it later?

tl;dr: The answer is 62.5 minutes. If you expect to need the cache again before then, refresh it. If not, let it expire. That number doesn't move when you switch between models and it doesn't move when the cached prefix grows from 5K tokens to 500K. The dollars change, but the decision point is still the same.

The numbers

Anthropic's pricing page lists prompt caching as a set of multipliers on the normal input-token price:

Model	Base input	5-min cache write	1-hour cache write	Cache read / refresh	Output
Opus 4.7	$5 / MTok	$6.25 / MTok	$10 / MTok	$0.50 / MTok	$25 / MTok
Sonnet 4.6	$3 / MTok	$3.75 / MTok	$6 / MTok	$0.30 / MTok	$15 / MTok
Haiku 4.5	$1 / MTok	$1.25 / MTok	$2 / MTok	$0.10 / MTok	$5 / MTok

The multipliers are the same for every model: a 5-minute cache write costs 1.25x the base input price, a 1-hour cache write costs 2x, and a cache read costs 0.10x.

Read operations do two jobs: A request that hits a live cache is billed at the read rate, and the same request refreshes the cache TTL back to 5 minutes, so cache hit = cache refresh.

The trick to keeping the cache warm is a super tiny request that reads the cached prefix before the TTL runs out. The cost is 10% of the normal input price for that prefix, but the catch is that you have to keep doing it until you need it again.

A case study of a 100K-token prefix

Let's take Opus 4.7 and a 100K-token cached prefix as an example. That's not a massive context window, but really easy to hit considering it's usually just enough to cover a system prompt, tool definitions, a project sketch, and some running notes from an agent session.

Writing that prefix to the 5-minute cache costs:

100K tokens * $6.25 / MTok = $0.625

Reading it, which also refreshes it, costs:

100K tokens * $0.50 / MTok = $0.05

If I keep the cache alive for T minutes, I pay the first write and then one read every 5 minutes:

refresh_cost(T) = W + R * floor(T / 5)

If I let the cache expire and come back later, I pay the first write and then a second write:

rewrite_cost(T) = W + W
                = 2W

The break-even is where the refresh reads add up to one extra write:

W + R * (T / 5) = 2W
R * (T / 5)     = W
T               = 5 * (W / R)
                = 5 * (1.25 / 0.10)
                = 62.5 minutes

The exact boundary is a little stair-stepped in practice, because you refresh in 5-minute chunks rather than in continuous time. That doesn't change the rule though because below about an hour, refreshing always wins. Past an hour, it's no longer efficient to keep paying the keepalive tax.

What cancels out

I expected the answer to depend on the model or the text size, but surprisingly it doesn't. Both sides of the comparison scale with the model's base input price and the number of cached tokens. A bigger prefix makes both strategies more expensive and Opus makes both strategies more expensive than Sonnet, but when you divide the write price by the refresh price, all of that disappears:

W / R = (N * base * 1.25) / (N * base * 0.10)
      = 1.25 / 0.10
      = 12.5

That is why the 62.5 minute timing rule is the same for a 5K Sonnet prefix and a 500K Opus prefix, but the dollar damage from choosing suboptimally changes between the two models.

For a 100K prefix on Opus 4.7 and Sonnet 4.6, both pairs land on the same x-axis:

The Opus lines sit higher because Opus costs more per token, but the crossover time is identical.

The cache footguns

The 62.5-minute rule was the thing I wanted, but it wasn't the only useful number on the pricing page.

Opus 4.7 can use up to 35% more tokens for the same fixed text. Anthropic calls this out in a note under the model pricing table: Opus 4.7 uses a new tokenizer, and the same text may become up to 35% larger in token terms. If you move a cached prompt from Opus 4.6 to 4.7, don't assume the old token count still holds. A 100K-token prefix could become 135K tokens, and every cache write/read calculation moves with it. Run the prompt through Anthropic's token counting endpoint before you move anything expensive.

Small prefixes don't cache. Opus 4.5, 4.6, and 4.7 need at least 4,096 cacheable tokens. Sonnet 4.6 needs 1,024. If your prefix is under the floor, the API does not throw a helpful error. It just processes the request without caching it. The only reliable signal is the usage block: if cache_creation_input_tokens and cache_read_input_tokens stay at 0, your cache isn't doing anything.

The lookback window is 20 blocks. Each cache breakpoint can scan backward through 20 content blocks looking for a prior write. If your agent adds more than 20 blocks between cache hits, the cache entry you wanted can fall outside the search window. I hit this once and assumed some field in the request was invalidating the cache. I had 23 blocks in a request, and the system stopped looking at block 20. The explicit breakpoint docs show the fix: add another breakpoint earlier in the prefix before you need it.

The dollars are small until they aren't

The ratio is model-independent, but the bill is very much model specific. On Opus 4.7, one cycle is: write the cache once, go idle for T minutes, then make the next real request.

Prefix size	Strategy	T = 5 min	T = 30 min	T = 60 min	T = 90 min
50K tokens	refresh + read at T	$0.338	$0.463	$0.613	$0.763
50K tokens	rewrite at T	$0.625	$0.625	$0.625	$0.625
100K tokens	refresh + read at T	$0.675	$0.925	$1.225	$1.525
100K tokens	rewrite at T	$1.250	$1.250	$1.250	$1.250
500K tokens	refresh + read at T	$3.375	$4.625	$6.125	$7.625
500K tokens	rewrite at T	$6.250	$6.250	$6.250	$6.250

At 30 minutes, keeping a 500K Opus prefix warm saves $1.625. At 60 minutes, it saves only $0.125. At 90 minutes, refreshing has become the wrong choice and costs $1.375 more than letting the cache expire. The savings are largest on shorter idle gaps and larger prefixes. Right before the crossover, there is barely any money left to save.

Compaction is not a free lunch

The other thing agents do is compact context: take the growing transcript, ask the model to summarise it, and continue from the summary instead of the original. Claude Code, OpenCode, etc all have a /compact command - and almost all agents do it automatically at certain points too when you're nearing the context limit.

Say the conversation has N cached input tokens and the summary has S tokens. Compacting costs three things:

read the old N tokens from cache: N * R
generate S output tokens at 5x base: S * 5B
write the new S-token prefix back to cache: S * W

After that, each future turn reads S cached tokens instead of N, saving (N - S) * R per turn. The break-even number of future turns is:

break_even_turns = (N + 62.5*S) / (N - S)
                 = (1 + 62.5*r) / (1 - r), where r = S/N

Again, the absolute context size cancels, only the compression ratio matters.

That curve, (1 + 62.5r) / (1 - r), looks like this:

The rule of thumb is roughly 10:1. If you can turn 100K tokens into a 10K-token summary and you expect at least eight more turns, compaction pays for itself on token cost alone. At 20:1, it pays back in about four turns. At 5:1, you need about 17 future turns. At 2:1, you need about 65 turns, which is not a compaction strategy so much as a very expensive tl;dr.

The output price is why the curve gets ugly. Cache reads are cheap, summary tokens are output tokens, and output is 5x base. A verbose summary can be a strict loss even if it technically reduces the prompt.

There is also a quality cost that the numbers don't show. A compaction that drops the exact error message, branch name, or failed hypothesis from ten turns ago might save a few cents and then risk the agent having to rediscover the same thing again.

Where the shortcut lies

The 62.5-minute rule assumes you will actually make another request. If 30% of sessions ask one question and leave, your expected-value math changes, and the right answer may be not caching at all. Interactive coding agents are usually on the other side of that line.

It also assumes the prefix is really cached. Check cache_creation_input_tokens and cache_read_input_tokens before trusting your own instrumentation. A cache below the minimum token floor, or a cache entry outside the 20-block lookback window, is not a cache. It's just a more expensive prompt with wishful thinking attached.

Patching Berkeley Mono with Nerd Fonts for Windows Terminal/WSL

Ryan Skidmore — Sun, 10 May 2026 00:00:00 GMT

I bought Berkeley Mono v2 ages ago and finally got around to installing it on my Windows Terminal/WSL setup. When I set it as the font in Windows Terminal, my Powerlevel10k prompt rendered empty squares instead of powerline arrows and git branch glyphs. Unsurprisingly, Berkeley Mono doesn't include the Nerd Fonts glyphs required by a lot terminal prompts.

The official Nerd Fonts patcher ships as a Docker image. Richard Ilagan's blog post documents the standard command to patch the font. Running that command produces a font that fails to render correctly in Windows. OpenType naming rules, the Windows font cache, and font smoothing utilities require a weird Windows-specific patching approach.

Use TTF source files instead of OTF

US Graphics provides Berkeley Mono in both .otf and .ttf formats. The patcher accepts OTF files and runs without errors, but the resulting font renders garbage characters in Windows Terminal. Thankfully this is a known issue in the Nerd Fonts repository. You need to download the TTF format from the US Graphics portal and use those as your source files.

Bypassing the 31-character family name limit

Running the patcher with the standard flags triggers a name length error:

docker run --rm \
  -v ./original:/in \
  -v ./patched:/out \
  nerdfonts/patcher \
  --complete \
  --single-width-glyphs \
  --adjust-line-height

The output fails with:

ERROR: ====-< Family (ID 1) too long (37 > 31): BerkeleyMono Nerd Font Mono SemiLight

Name ID 1 in the OpenType name table is limited to 31 characters. The patcher's default behavior concatenates the original family name, "Nerd Font Mono", and the variant name ("SemiLight"), exceeding the limit.

Using the patcher's --name FORCE_NAME flag overrides the family name, but it collapses all patched weights into a single "Regular" subfamily, destroying the weight metadata. The correct flag is --makegroups 0. This keeps the family name stable across all variants and correctly pushes the weight data into the SubFamily field:

docker run --rm -v ./original:/in -v ./patched:/out \
  nerdfonts/patcher --complete --single-width-glyphs \
  --adjust-line-height --makegroups 0

Adding bold and italic weights for Windows Terminal

With the patched TTF installed, the prompt renders correctly, but bold text appears at the same weight as regular text.

Unlike terminals that allow you to explicitly define a bold font file, Windows Terminal selects a single font family and asks the DirectWrite API for its bold variant. If you only install the SemiLight weight (weight 380), Windows cannot locate a heavier weight. It either synthesizes a faux-bold that looks identical to the original, or it just renders SemiLight.

To get working bold text, you have to download a heavier TTF weight, patch it, and install it alongside your base font. I use SemiLight for regular text and SemiBold (weight 600) for bold text. The 220-point weight difference produces visibly thicker glyphs without relying on Windows to synthesize them. You also need to patch and install the corresponding Oblique variants, or Windows will fall back to a system italic font (or just the same font).

Rewriting the SubFamily field for RIBBI compliance

After patching SemiLight, SemiLight-Oblique, SemiBold, and SemiBold-Oblique, the Windows font picker displayed two separate entries: "BerkeleyMono Nerd Font Mono" and "BerkeleyMono Nerd Font Mono SemiLight".

Dumping the name table on the patcher output confirms the cause. Name ID 2 (Subfamily) carries the original variant string straight through from the source TTF:

$ otfinfo -n BerkeleyMonoNerdFontMono-SemiLight.ttf
Family:              BerkeleyMono Nerd Font Mono
Subfamily:           SemiLight
Full name:           BerkeleyMono Nerd Font Mono SemiLight
PostScript name:     BerkeleyMonoNerdFontMono-SemiLight
Preferred family:    BerkeleyMono Nerd Font Mono
Preferred subfamily: SemiLight

OpenType uses a convention called RIBBI, which stands for the four canonical subfamilies: Regular, Italic, Bold, and Bold Italic. When a font's SubFamily (name ID 2) matches one of these four, Windows groups the variants into a single family. When the SubFamily is "SemiLight" or "Medium", Windows often splits the fonts into separate families.

To force Windows to group them, you have to rewrite the SubFamily field on the patched fonts to use the canonical RIBBI names:

Source variant	RIBBI slot
SemiLight	Regular
SemiLight Oblique	Italic
SemiBold	Bold
SemiBold Oblique	Bold Italic

This renaming means typographic applications like Photoshop will display the weight as "Bold" instead of "SemiBold". For terminal use, this inaccuracy is invisible.

Removing Preferred Family and Styles metadata

After applying the RIBBI subfamilies and reinstalling, the Windows font picker split the fonts into four distinct entries.

Dumping the name table on the renamed font shows the culprit. IDs 1 and 2 are correct, but IDs 16 and 17 still carry the patcher's original strings:

$ otfinfo -n BerkeleyMonoNF-Regular.ttf
Family:              BerkeleyMonoNF
Subfamily:           Regular
Full name:           BerkeleyMonoNF Regular
PostScript name:     BerkeleyMonoNF-Regular
Preferred family:    BerkeleyMono Nerd Font Mono
Preferred subfamily: SemiLight

The patcher includes name IDs 16 (Preferred Family) and 17 (Preferred Styles) in its output. These fields retained the original variant names. When IDs 16 and 17 are present, Windows constructs display names by concatenating them, ignoring the RIBBI values in IDs 1 and 2. That's how the four-way split happens: each variant's ID 16 + ID 17 reads as a different family.

The fix is to delete name IDs 16 and 17 entirely. Without them, Windows falls back to ID 1 and ID 2, which now contain the correct RIBBI values. You also need to remove ID 18 (Compatible Full), which carries similar legacy data.

The final state after the rewrite has only RIBBI-compliant fields:

$ otfinfo -n BerkeleyMonoNF-Regular.ttf
Family:              BerkeleyMonoNF
Subfamily:           Regular
Full name:           BerkeleyMonoNF Regular
PostScript name:     BerkeleyMonoNF-Regular

Clearing the Windows FontCache

Windows aggressively caches font metadata. Uninstalling the split fonts and installing the corrected ones often results in the system continuing to display the old names. The FontCache service retains the original metadata for fast boot enumeration.

You can clear the cache manually in PowerShell:

Stop-Service FontCache
Stop-Service FontCache3.0.0.0 -ErrorAction SilentlyContinue
Remove-Item -Force -Recurse $env:WinDir\ServiceProfiles\LocalService\AppData\Local\FontCache\*
Remove-Item -Force $env:WinDir\System32\FNTCACHE.DAT -ErrorAction SilentlyContinue
Start-Service FontCache
Start-Service FontCache3.0.0.0 -ErrorAction SilentlyContinue

Rebooting the machine achieves the same result. Windows Terminal also caches font lookups per-process, requiring you to fully close the application, not just the current tab.

To bypass the cache entirely, I renamed the font family to BerkeleyMonoNF. Because this name had never been installed, the Windows cache had no conflicting metadata to apply to it.

Excluding patched fonts from MacType

After a clean installation, I noticed faint vertical artifacts next to adjacent letters like tt and ff. I use MacType for system-wide font smoothing (oh, the troubles of OLED), and the artifacts were caused by its rendering engine.

The Nerd Fonts patcher runs ttfautohint over its output, replacing the source font's manual hinting. MacType applies its own subpixel anti-aliasing logic on top of this. The combination of ttfautohint and MacType produces visual artifacts that do not occur on the stock fonts.

To resolve this, right-click the MacType tray icon, open the wizard, and add WindowsTerminal.exe and OpenConsole.exe to the exclusion list. Restart MacType and Windows Terminal, and the artifacts disappear.

The complete patching scripts

The entire process requires two scripts running in the same directory. Both rely exclusively on Docker.

patch-fonts.sh runs the Nerd Fonts patcher against the TTFs in the source directory, then executes the renaming script.

#!/usr/bin/env bash
# Usage: ./patch-fonts.sh <source-dir> <output-dir>
set -euo pipefail

if [ "$#" -ne 2 ]; then
  echo "usage: $0 <source-dir> <output-dir>" >&2
  exit 1
fi

SRC="$(cd "$1" && pwd)"
OUT="$(mkdir -p "$2" && cd "$2" && pwd)"
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"

docker pull -q nerdfonts/patcher >/dev/null

# Patch with Nerd Font glyphs
docker run --rm -v "$SRC:/in" -v "$OUT:/out" \
  nerdfonts/patcher \
  --complete --single-width-glyphs --adjust-line-height \
  --makegroups 0 --quiet

# Rewrite name table for RIBBI compliance
docker run --rm -v "$OUT:/out" -v "$SCRIPT_DIR/fix-font-names.py:/fix.py" \
  --entrypoint fontforge nerdfonts/patcher \
  -script /fix.py /out

ls "$OUT"/*.ttf

fix-font-names.py executes inside the patcher's Docker image using its bundled fontforge environment. It renames the family to BerkeleyMonoNF, maps the source variants to RIBBI subfamilies, drops name IDs 16 and 17, and sets the OS/2 weight class.

#!/usr/bin/env python3
"""Rewrite the name table on patched TTFs so they form a single RIBBI family."""

import sys, os, re, glob
import fontforge

FAMILY = "BerkeleyMonoNF"

# Source variant -> (RIBBI subfamily, italic angle, OS/2 weight class)
VARIANT_MAP = {
    "SemiLight":        ("Regular",     0,   380),
    "SemiLightOblique": ("Italic",      -10, 380),
    "SemiBold":         ("Bold",        0,   600),
    "SemiBoldOblique":  ("Bold Italic", -10, 600),
}

DROP_KEYS = {"Preferred Family", "Preferred Styles"}

def fix_one(path):
    m = re.match(r"BerkeleyMonoNerdFontMono-(\w+)\.ttf$", os.path.basename(path))
    if not m or m.group(1) not in VARIANT_MAP:
        return False

    ribbi, italic_angle, weight = VARIANT_MAP[m.group(1)]
    psname_subfamily = ribbi.replace(" ", "")

    f = fontforge.open(path)
    f.familyname = FAMILY
    f.fullname = f"{FAMILY} {ribbi}"
    f.fontname = f"{FAMILY}-{psname_subfamily}"

    override = {
        "Family":          FAMILY,
        "SubFamily":       ribbi,
        "Fullname":        f"{FAMILY} {ribbi}",
        "PostScriptName":  f.fontname,
        "Compatible Full": f"{FAMILY} {ribbi}",
        "UniqueID":        f"{FAMILY}-{psname_subfamily} v1",
    }
    
    f.sfnt_names = tuple(
        (lang, k, override.get(k, v))
        for lang, k, v in f.sfnt_names
        if k not in DROP_KEYS
    )

    f.os2_weight = weight
    style = 0
    if "Italic" in ribbi:  style |= 0x0001
    if "Bold" in ribbi:    style |= 0x0020
    if ribbi == "Regular": style |= 0x0040
    f.os2_stylemap = style
    f.macstyle = (2 if "Italic" in ribbi else 0) | (1 if "Bold" in ribbi else 0)
    
    if italic_angle and f.italicangle == 0:
        f.italicangle = italic_angle

    new_path = os.path.join(os.path.dirname(path), f"{f.fontname}.ttf")
    f.generate(new_path, flags=("opentype",))
    
    if new_path != path:
        os.remove(path)
        
    print(f"✓ {os.path.basename(new_path)} → {ribbi}, weight={weight}")
    return True

if __name__ == "__main__":
    out_dir = sys.argv[1] if len(sys.argv) > 1 else "."
    for p in glob.glob(os.path.join(out_dir, "BerkeleyMonoNerdFontMono-*.ttf")):
        fix_one(p)

To run the patcher, place the TTF files in an incoming directory and execute the bash script:

chmod +x patch-fonts.sh

mkdir incoming
cp ~/Downloads/BerkeleyMono-{SemiLight,SemiLight-Oblique,SemiBold,SemiBold-Oblique}.ttf incoming/

./patch-fonts.sh incoming/ patched/

The script outputs the patched and renamed fonts into the patched/ directory. Copy those files to Windows, install them, and set the Windows Terminal font to BerkeleyMonoNF.

Adjusting for other fonts

This naming table structure applies to any commercial font patched with Nerd Fonts. The patcher consistently emits non-RIBBI subfamily names, which causes Windows to fragment the font family. If you patch another font, you can use the same scripts by modifying the VARIANT_MAP dict and the filename regex in the Python file.

Slopdocs: notes for the next clanker

Ryan Skidmore — Sat, 02 May 2026 00:00:00 GMT

As a fully-certified AI stan who uses AI almost religiously both at home and at work, I kept running into a frustrating papercut where I'd set an agent to go work on a task without much (or sometimes any) guidance and I'd tell it to go figure it out without me. This is fantastic for working on 14 tasks in parallel, but starts to become a real problem when you're trying to figure out why one of your clankers made a certain decision or implemented something in a certain way.

A lot of agents now do pretty comprehensive planning before implementing features or making changes, but often that plan ends up in the ether and along with it, all of the context about the decision making and thinking that happened.

The stateless agent problem

Agents don't remember anything, and sometimes they forget things you've told them in the very same session. Each session starts from a blank slate, and whatever you taught the last one lives in your head until you need to explain it again in the next session, the next morning, or the next branch.

You stop realizing how much mental baggage you're carrying, and after a few weeks, you become the only reliable source of truth in the system. You end up acting as the human glue holding together a chain of sessions from the last few weeks.

Diffs don't capture the thinking

Code goes into git, but the reasoning, thinking and exploration behind it rarely does. A diff tells the next reader what changed, but it doesn't tell them what wasn't tried, or why a weird-looking workaround was actually the best approach.

A few weeks later, the code looks normal and the alternatives look obvious. Someone, whether an agent or a human, refactors the weirdness away, and the original constraint resurfaces soon after. The reasoning for that weird choice had been written down in the original plan. It just wasn't anywhere reachable by the next session.

Let the slop flow!

I stopped trying to tidy up all of the AI-generated slop documentation and started letting it hang out. Initially I didn't have any kind of methodology or system in place (which was about as disastrous as you imagine), but I quickly adopted a "slopdocs" convention where I (read: the robot) tidied away all of the messy documentation in a slopdocs directory.

My approach uses three folders:

slopdocs/
├── features/
├── bugs/
└── plans/

Files in bugs/ and plans/ get a date prefix so they act as point-in-time snapshots, while features get one living document that gets updated over time. None of it is intended for humans to consume.

I wrote the full convention up at slopdocs.dev. It includes an agent skill that drops into any codebase in a few seconds. The skill teaches your agent the directory structure and, more importantly, when to skip writing a document. If you save every output, the folder becomes a garbage dump and your agent stops being able to wrangle it.

It plays nicely alongside skills that handle the actual writing, like superpowers. Slopdocs just decides where the output goes. My agent now reads the existing slopdocs before touching an area, and the plethora of documentation becomes a shared history at a repository level.

Orchestrating AI Code Review at scale

Ryan Skidmore — Mon, 20 Apr 2026 00:00:00 GMT

Learn about how we built a CI-native AI code reviewer using OpenCode that helps our engineers ship better, safer code.

We're back baby! New year, new blog updates 🚀

Ryan Skidmore — Tue, 22 Apr 2025 00:00:00 GMT

I haven't blogged once since my last post ✨ That new blog smell ✨ about a year ago, where I similarly talked about updates I'd made to my personal site. Well, we're back again with almost the exact same thing, but the 2025 edition!

This time I've not made quite as many changes. My site still runs on Next.js but a lot of other things have changed. I previously commented how the performance of Next.js wasn't quite as good as SSGs like Gatsby but since then I've learned that this was due to a personal skill issue, not an artefact of the framework itself. I was previously using the Outstatic framework to manage my blog posts, which worked pretty well (and had a nice UI) but was a bit of a PITA to integrate nicely.

I've since switched to Nextra, which seems a lot more promising and more importantly, easy to integrate while remaining performant. Everything is pre-generated at build time, and blog posts are written in MDX, which opens a huge amount of possibilities.

I was also previously hosting this site on Cloudflare Pages via next-on-pages - because that was the only real option for running Next.js on Cloudflare. Since then, OpenNext was released which enables running Next.js on the Workers ecosystem as well as other non-Vercel platforms. OpenNext has been gaining in popularity recently following its first major (1.x.x) release (okay admittedly it's a beta, but still!). Running Next.js on the Workers ecosystem is an absolute dream, and I'm not just saying that to be a corporate simp.

How does Next on Workers compare to Vercel?

I deployed a copy of this site to Vercel to measure the performance and compare that to the active deployment on Workers, and honestly there's not really that much in it. Both sites load within ~350ms, which is to be expected considering I'm in a central metro area with a beefy computer and fast internet. I imagine for bigger projects or applications with users in a lot of varied, distinct geographies there might be a bit more of a difference - but for my use case it doesn't really matter too much. I think the biggest deciding factor is the ecosystem. I've been a fan of Vercel's platform for a while, but their pricing is pretty whack and that doesn't give me a huge amount of confidence to deploy anything other than small hobby projects.

✨ That new blog smell ✨

Ryan Skidmore — Sun, 23 Jun 2024 00:00:00 GMT

It turns out I'm not very good at blogging, in fact the last time (and first time) I wrote a blog post on the previous incarnation of this blog was November 2020. In lieu of biting the bullet and writing a second blog post, I thought it was about time I rebuilt my blog again! and not on Kubernetes this time

My previous blog was built using Gatsby and hosted on Netlify. This stack works perfectly well but over the last few years I've been using a lot of Next.js on Vercel. The performance of Next.js isn't as good as Gatsby, but it's a lot more flexible at runtime and the ecosystem is huge - so it's a worthwhile trade-off. I was going to host this on Vercel like I've done with my other Next.js projects, but I thought I'd give Cloudflare Pages a go this time instead. After all, I do work for Cloudflare now!

See you again probably in 4 years folks 🫡