DEV Community: JessYT

Raycast: Why I Use It Instead of Spotlight

JessYT — Tue, 02 Jun 2026 21:06:32 +0000

Raycast: Why I Use It Instead of Spotlight

Raycast is a launcher that replaces Spotlight, macOS's built-in search bar. But it's not just a "prettier Spotlight." The whole point is turning that app-launch shortcut into a work hub that handles clipboard history, window tiling, text autocomplete, and script execution all in one place. This post walks through what Raycast is, how to set it up the first time, which features to try first, and the gotchas worth knowing in advance.

Spotlight already works — so why switch?

If you use macOS, you've almost certainly hit ⌘Space to bring up Spotlight, searched for an app, and launched it. It's fast and convenient. But that's where it ends. Once the app is open, everything that comes next — pasting back something you just copied, snapping a window to half the screen, typing a phrase you use constantly — lives in a different app, behind a different shortcut.

Raycast starts from one idea: "let's pull all those scattered tasks into the same search bar." You open a single window with a shortcut, type a few characters, and it doesn't just launch apps — it searches your clipboard, tiles windows, runs calculations, and fires extensions. The biggest change is how much less your hands leave the keyboard to go digging through menus with the mouse.

Task	Spotlight	Raycast
Launch apps · search files	Yes	Yes
Re-paste something copied earlier	No (needs a separate app)	Built in (Clipboard History)
Snap windows to half-screen · maximize	No (needs a separate app)	Built in (Window Management)
Auto-type frequently used phrases	No	Built in (Snippets)
Drive external tools like GitHub · Linear	No	Yes, via extensions (Store)

How to set it up on first launch

After you install and open Raycast, the first thing you decide is the trigger shortcut. The default is ⌥Space (Option + Space), but a lot of people prefer to hand Raycast the ⌘Space slot that Spotlight occupies. You keep the key your hands already know.

There's one catch, though. macOS assigns ⌘Space to Spotlight by default, so if you leave it as-is, the two collide. The usual order is to first clear or remap the Spotlight shortcut in System Settings, then set Raycast's trigger to ⌘Space in its preferences.

Setup order: ① System Settings → Keyboard → Keyboard Shortcuts → Spotlight → disable (or change) the "Show Spotlight search" shortcut → ② Raycast Settings → General → set Raycast Hotkey to the key you want. Follow this order and the shortcuts won't clash.

Also, some features like window tiling have to move other apps' windows, so macOS asks for Accessibility permission. The first time you run a window-tiling command, a permission prompt appears — grant Raycast access once in System Settings and it works smoothly from then on.

What you can use right after installing

Even without installing a single extension, the out-of-the-box feature set is surprisingly broad. It effectively absorbs several small utilities you'd otherwise install separately. Let's go through them one by one.

Clipboard History — pull back what you copied

Copy something, then copy something else, and the previous item is gone. Clipboard History keeps a record of copied text and images so you can search and re-paste the one you want. Assign it a shortcut and you can pop the history list anywhere to instantly find "that link from earlier."

Window Management — tile windows with the keyboard

Move a window to the left half, right half, or full screen with a single command. Instead of grabbing a window corner with the mouse and dragging, you type a command like "left half" into the search bar or bind it to a shortcut. There are also commands to throw a window onto the next display on a dual-monitor setup.

Snippets — autocomplete phrases you reuse

Register repeated text — an email address, a common greeting, a signature — under a keyword, and the moment you type that keyword it expands into the full phrase. For example, you can make typing ;mail insert your email address. It also supports dynamic snippets that auto-fill the date.

Quicklinks · Calculator · Search

Quicklinks for registering frequently opened URLs or site-specific searches as commands, a Calculator for doing math and converting units · currencies right in the window, and search for finding and opening files and folders — all built in. This is where the feeling of "I start pretty much everything from one search bar" takes hold.

The real difference comes from the Store

What gives Raycast its character is the Store. Community extensions let you drive tools like GitHub, Jira, Linear, Homebrew, color pickers, and translators straight from the search bar. Installing is simple: open "Store" from the search bar, find the extension you want, install it, and its commands immediately join your search results.

For developers, the flow that really lands is something like this: checking your PR list from the search bar without opening a browser to GitHub, or searching and installing a Homebrew package without opening a terminal. Instead of "moving to a tool's window to use the tool," it shifts to "calling the tool from the search bar."

One step further — register your own scripts as commands

If you want to automate repetitive work, Script Commands are powerful. Register a shell or Python script as a Raycast command and you can run it just by typing its name into the search bar. All it takes is adding a block of structured comments (metadata) at the top of the script.

#!/bin/bash

# Raycast metadata
# @raycast.schemaVersion 1
# @raycast.title Copy today's date
# @raycast.mode silent

# Actual action
date "+%Y-%m-%d" | pbcopy

Drop a script saved like this into Raycast's Script Commands folder, and the moment you find and run "Copy today's date" from the search bar, today's date lands on your clipboard. Build commands you run often — build scripts, server logins, opening logs — into a single search-bar line this way.

How far does free go, and what's paid?

Personal use is free, and the free tier covers most of what's described above. Some features like team-wide sync and Raycast AI belong to the paid Pro plan. That said, plan structure, pricing, and the free/paid line all change over time, so for the exact, current details it's safest to check the pricing page on the official site.

Gotchas worth knowing in advance

Shortcut conflicts: as covered above, to use ⌘Space you have to clear the Spotlight shortcut first. Otherwise both windows respond at once.
Permission prompts: window tiling and some extensions need Accessibility permission. Without it, those specific commands just silently fail to work, so it's worth granting it once at the start.
Uneven extension quality: Store extensions are community-built, so their polish and maintenance vary. Sticking to extensions that are popular and have an update history is more reliable.
Platform: it's most mature on macOS right now. Rather than expecting the same experience elsewhere, keep in mind it's the tool that fits macOS users best.

So who is it for?

If you prefer working from the keyboard over the mouse, and you already run a separate clipboard manager or window-tiling app, Raycast becomes a natural choice for merging them into one. Add extensions and scripts on top, and it goes beyond a simple launcher to become "the entrance to your workflow."

On the other hand, if you only use Spotlight's app launching and need nothing more, there's little reason to switch. Rather than reaching for every feature from day one, I'd suggest binding just two — Clipboard History and Window Management — to shortcuts and living with them for about a week. Even those two alone make it easy to feel your hands leaving the keyboard less.

Sources

This post is an overview based on the official docs and Store rather than a long-term hands-on review. Specific features, shortcuts, and pricing may change with updates, so I recommend checking the settings screen and the official documentation alongside it.

Original with full infographics and visual structure: https://jessinvestment.com/raycast-why-i-use-it-instead-of-spotlight/

How One Word 'Workflow' Spins Up Hundreds of Claude Code Agents

JessYT — Tue, 02 Jun 2026 21:04:13 +0000

How One Word 'Workflow' Spins Up Hundreds of Claude Code Agents

I run a few dozen automation jobs. They've always been independent jobs, each spinning up on its own. Then Claude Code shipped Dynamic Workflows, where a single session orchestrates hundreds of agents in the background by itself. It looked close enough to what I've been doing that I spent a few days digging into it firsthand.

One word, "workflow," and Claude writes the script itself

Dynamic Workflows dropped as a research preview on May 28. It kicks in when I drop the word "workflow" into a prompt, or type /effort ultracode. It shows up on Claude Code v2.1.154 and above.

The behavior was a little unusual. Claude takes my task and, right there on the spot, writes a JavaScript orchestration script itself. That script fans out dozens to hundreds of subagents in the background at once, and checks the results itself once before handing them back to me.

Up to 1,000 agents per run, with concurrency capped at 16 at a time. The key part was that I didn't have to spawn each job by hand.

The real story was how it differs from my automation

At first I thought, "Isn't this just what I've been doing for a year?" But after a few days, the grain was completely different.

My few dozen automation jobs are all independent jobs scheduled by launchd. Publishing jobs separately, market monitoring separately, English study separately. They don't share the same reasoning context — each one wakes up at a set time, does its own work, and goes back to sleep.

Dynamic Workflows was the opposite. It splits one task into hundreds of branches inside a single session. It's not a schedule — it's a fan-out that unfolds all at once. For one big task like "audit this whole repo, file by file, in parallel," this fit way better than my cron approach.

I ran one small workflow myself

I didn't get greedy — I started with something small. A task that scanned the files in one directory in parallel.

$ claude
> review and summarize each .py file in this directory in parallel as a workflow

# Claude writes a JS script on the spot
# one subagent per file, fanned out in the background (up to 16 concurrent)
# checks each result itself, then replies all at once
# meanwhile my session stays responsive (watch progress with /workflows)

What struck me was that the session doesn't block. While it ran in the background, I could keep asking other things in the same session. Type /workflows and you get a one-liner showing how many are running and how many are done. It feels like firing it off, doing something else, and just collecting the results.

Still, I didn't tear down my cron jobs

Honestly, I didn't replace my automation jobs with this. It's still a research preview, but on paid plans it's open from Pro on up. (On Pro you have to flip it on once in the settings.)

And the whole point of my jobs is that they "wake up on their own at a fixed time," so they were never the same use case as Dynamic Workflows, which fans out inside a single session. So I decided to split the labor like this: recurring work on a fixed schedule stays a launchd scheduled job, and one-off work I want to slice up big at once goes to a workflow. They're not competing — they're tools in different seats.

If something like a full-repo migration or a large-scale audit comes up — something I need to spread wide in one shot — I'll call workflow without hesitation. For now I'm going to keep the labor split like this and run with it some more.

Sources: Claude Code Docs — Orchestrate subagents at scale with dynamic workflows · Anthropic — Introducing dynamic workflows in Claude Code

This is a first-person write-up from a few days of hands-on use. It's a research-preview feature, so plans and behavior may change. I received no sponsorship of any kind from Anthropic.

Original with full infographics and visual structure: https://jessinvestment.com/how-one-word-workflow-spins-up-hundreds-of-claude-code-agents/

Claude Code's /reload-skills Ended My Constant Session Restarts

JessYT — Tue, 02 Jun 2026 21:02:39 +0000

Claude Code can finally reload skills without a session restart

Almost everything I run daily is a Claude Code skill. Publishing, English study, market monitoring — all of it. So I end up editing skill files several times a day, and until now, changing a single line meant tearing down the whole session and starting it back up just to make the new content take effect. That whole dance is now one line: /reload-skills.

I was restarting whole sessions to fix one line in a skill

I don't write a skill perfectly in one shot. I run it, cut one awkward sentence, add one more condition… I shape it bit by bit like that.

But before this, even after I fixed that one line, the running session was still holding onto the old skill. To test the new version I had to close the session and open it again — and every time, the context I'd built up went with it. That got annoying fast.

/reload-skills rescans in one line

The new /reload-skills re-reads the skills directory without killing the session. I edit a file, type this command, and I can keep testing the updated skill right there in the same session.

$ claude
> (edit one line in a skill file and save)
> /reload-skills

# rescans the skills directory without restarting
# context intact, straight back to testing the updated skill

This might sound minor, but the biggest thing for me is fixing things without throwing away context. If your day involves touching skills several times, every single one of those restarts adds up.

The one that hit me most often was my publishing skill. Every time I ran it once and thought "I need to drop one condition here," the old way meant closing out everything I had in progress just to fix that one line. Now I delete that line in the skill file, type /reload-skills, and run it again from the exact same spot. The loop of test, fix, test again got a lot shorter.

I wired it into my SessionStart hook too

I like to auto-load a bunch of things with a hook when a session starts. So whenever a hook installed a new skill, it wouldn't show up in that session — only from the next one — and that always bugged me.

Turns out if a SessionStart hook returns reloadSkills: true, it rescans right there. That let me use a hook-installed skill in the same session. (I didn't know this and spent a while going "why isn't it showing up this session" 😭)

There are still times you have to restart

It doesn't cover everything. /reload-skills was enough when I was editing the contents inside a skill, but when I touched settings themselves or a hook definition, reopening the session was the cleaner move.

Still, for someone like me who edits skill bodies all the time, just cutting down the number of restarts was enough to feel the difference. At this point, fixing a skill and typing /reload-skills is basically muscle memory.

Source: Claude Code — Changelog (v2.1.152)

This is a first-person write-up after using it myself for a few days. I received no sponsorship of any kind from Anthropic.

Original with full infographics and visual structure: https://jessinvestment.com/claude-codes-reload-skills-ended-my-constant-session-restarts/

Opus 4.8's Default 1M Context Window Is the Upgrade I Notice Most

JessYT — Tue, 02 Jun 2026 21:01:20 +0000

This is a straightforward text transformation task — no skills apply. Here's the converted markdown:

Opus 4.8: the default 1M context window is what I notice most in long sessions

Claude Code moved to Opus 4.8 a few days ago, and the default context window is now 1M. I run several long-lived automation jobs, and the old pain was predictable: once a session ran long enough, the context would fill up and I'd have to hit /compact or spin up a fresh session. With 1M as the default, that happens far less.

Opus 4.8 shipped on May 28

Anthropic released Opus 4.8 on May 28, 2026. The thing that jumped out at me was the default 1M context window. It's 1M on the Claude API, Amazon Bedrock, and Vertex AI, while Microsoft Foundry is 200k. Max output is 128k.

Pricing stays the same as 4.7. Bumping the model without raising the per-token price was a welcome detail for me.

For someone running long sessions, this was the big one

The default 1M landed harder for me than the benchmark numbers did. Before, long sessions filling up their context and breaking my flow was the most annoying part. Working with long automation-job logs attached, I hit it even more often.

$ claude
> /model
# Check that it's running as Opus 4.8 (1M context)
# Before, long sessions would fill up the context and I'd hit /compact or open a new session
# With 1M as the default, that happens noticeably less

It's only been about two days, but I'm carrying long sessions straight through more often. If you keep an entire large repo loaded while you work, you'll probably feel it even more.

The benchmarks and honesty gains are from the announcement

Per the release notes, agentic coding went from 64.3% to 69.2% and reasoning from 54.7% to 57.9%. I didn't measure these myself — these are the numbers from the announcement, so I'm just passing them along.

The honesty improvement was more interesting to me. Anthropic said Opus 4.8 lets flaws in its own code slide roughly 4x less often than 4.7. That's not something I can confirm in a few days, though, so I've left it as something to watch for a while.

Fast mode got faster and cheaper

Fast mode got some work too. On Opus 4.8 it's about 2.5x faster and costs less than before. You still turn it on with /fast, and it doesn't drop you to a smaller model — it's the same Opus running faster.

I don't usually run fast mode, so I can't say much here yet. For light tasks that need quick responses, I'm planning to leave it on and run it for a few more days.

What I'm watching over the next few days

In the end, the core of Opus 4.8 for me was the default 1M context. More than how many percentage points a benchmark moved, long sessions not breaking is the difference that adds up day after day.

Whether the honesty improvement actually shows up is something I'll only know after running the same kinds of tasks for a while. For now, just having the context fill up less is plenty to be happy about.

Sources: Anthropic — News · Claude Code — What's New

This is a first-person take after a few days of hands-on use. The benchmark and honesty figures are copied straight from Anthropic's announcement, and this post is not sponsored in any form.

Original with full infographics and visual structure: https://jessinvestment.com/opus-4-8s-default-1m-context-window-is-the-upgrade-i-notice-most/

Opus 4.8 Launched, but Fast Mode Was the Real Win for Me

JessYT — Fri, 29 May 2026 21:04:06 +0000

Opus 4.8 Launched, but Fast Mode Was the Real Win for Me

Yesterday (May 28), Anthropic rolled Opus 4.8 out globally. The announcement was about coding scores climbing again, but since I run Claude Code all day long, something else caught my eye before the benchmark table did: the line saying fast mode got 2.5x faster and 3x cheaper.

01. Same price, just a better model

Opus 4.8 went out to everyone the moment it was announced yesterday. According to Anthropic, the core of it is doing agentic work — like coding — better.

The good news is the price. Anthropic says the per-token rate stays the same between Opus 4.7 and 4.8. It's one of those cases where the model quietly levels up but the bill doesn't change, so for an existing user there was no added burden to worry about.

02. How the benchmark table changed

These are the 4.7-vs-4.8 numbers Anthropic published. Let me note up front that I didn't measure these — they're straight from the announcement notes.

Metric	4.7	4.8
Agentic coding	64.3%	69.2%
Tool-use reasoning	54.7%	57.9%
Knowledge-work score	1753	1890
Computer use	82.8%	83.4%

They also say high effort is now the default for coding tasks. The explanation is that you spend roughly the same tokens as 4.7 but get better results.

03. For me, fast mode was the real story

What actually touched my day-to-day, more than the scores, was the fast mode side. Per the announcement, the fast mode variant now runs 2.5x faster than before while costing 3x less.

I run several Claude Code jobs at once — AI ecosystem monitoring, stock market monitoring, writing posts. In a setup like that, faster responses and cheaper tokens hit you immediately. Here's how I usually launch it.

$ claude --model opus      # this is how I usually launch it
> /fast                     # toggle fast mode (Opus 4.8/4.7/4.6 supported)

# I run a bunch of jobs in parallel, so
# faster, cheaper responses pile straight up into cost · time savings

On top of that, Claude Code's rate limits went up too. With the extra · max settings you can funnel more tokens through. Heavy work that kept hitting the ceiling should breathe a little easier now.

04. I can't speak to the coding feel yet

Honestly, I can't promise "coding got 5pp better" just from the benchmark table. The model dropped only yesterday, so it'll take a few more days of use before I know what's actually different from 4.7 in my own work.

What I haven't verified yet — The only thing I measured myself is the fast mode speed; I haven't done a hands-on comparison of coding accuracy. The benchmark table is copied straight from the announcement notes, so I'll write up the real-world feel separately.

Still, getting frozen pricing + faster fast mode + higher limits all in one drop was a pretty big bundle for someone running automation. On that part alone, I was glad from day one of the announcement.

Eddie's take — Honestly, I tend to stay pretty unmoved every time a model's benchmark table goes up. You only learn the real difference after a few days of use anyway. But this time, making fast mode faster and cheaper without raising the price was a far more concrete change — for someone running it every day — than a few percentage points on a score.

Sources

This post summarizes an external announcement. The score and price figures are based on Anthropic's announcement notes, and aside from fast mode speed, I did not personally measure the coding experience. No sponsorship of any kind was received.

Canonical: https://jessinvestment.com/opus-4-8-launched-but-fast-mode-was-the-real-win-for-me/

Original with full infographics and visual structure: https://jessinvestment.com/opus-4-8-launched-but-fast-mode-was-the-real-win-for-me/

Claude Code Checkpoints: Double-Esc to Undo a Botched Edit

JessYT — Fri, 29 May 2026 21:02:01 +0000

Claude Code Checkpoints: Double-Esc to Undo a Botched Edit

There's one moment working with Claude Code that sends a chill down my spine. Claude rolls along great, then suddenly does something I never expected. When that happens I stop it fast and ask for a rollback — but sometimes the rollback itself goes sideways from what I meant. Now the new checkpointing feature ends all of that with two presses of Esc. I wrote this as someone running the May Week 20 update (checkpoint + /rewind).

01. Yesterday I pressed Esc twice for the first time

Yesterday I had Claude refactor a function, and when I looked at the result it had changed way more than I intended. Before, I'd panic first and dig through git diff to see what got wrecked while I rolled it back. But this time I tapped Esc twice and every changed file snapped back to its original state!!

Claude Code automatically saves a snapshot of your code state right before each change. You pick whichever snapshot you want to return to, and it reverts. What I liked most: no need to git commit, and no special command to memorize!

$ claude
> refactor this whole function
(Claude edits several files at once)

# result doesn't match what I meant — Esc twice
[checkpoint] reverted to 2 minutes ago
(files restored to just before the change, all at once)
# no git stash, no git reset needed

02. /rewind for a more explicit revert

Here's what I found from using it. For me, typing /rewind brings up a list of recent checkpoints, and I pick a point and jump back to it.

When two or three suspicious changes had piled up, this was great for cleaning it all up in one shot.

03. The difference from git reset, as I see it

I'm comfortable with git, so at first I thought "how is this any different from git reset?" After a few days of use I saw two decisive differences.

First, the big one: checkpoints get captured even without a commit. I tend to work without committing in the middle, so git reset had no way to recover those in-between changes for me. What I liked most is that checkpointing snaps automatically right before Claude touches anything — completely independent of commits.

Second, I liked that it reverts multiple files as one bundle. When a task touches several files at once, it was hard for me to track what I'd changed where. Checkpointing reverts a whole "unit of work" in one shot, so there's no tracking burden.

04. /goal delegation finally feels safe

In an earlier post I covered using the /goal command so Claude stops asking me every turn. Back then the one thing nagging at me was: what if Claude goes rogue mid autonomous run?

I think checkpointing shaved off most of that worry. Even if the result drifts off-course during delegation, two presses of Esc bring me back to the last safe state. So I've been using /goal more aggressively.

The pattern I bundle them in: I run /goal for an autonomous pass → let the result play out to the end → if I don't like it, Esc twice. For me, bundling these two features dropped the psychological cost of delegating way down.

05. A case where it doesn't work so well, in my view

From my few days of use: when each change unit is tiny, they pile up like grains of sand. In that case it was sometimes hard to judge which point to revert to.

Sources

This is a first-person review after a few days of hands-on use. I received no sponsorship of any kind from Anthropic.

Original with full infographics and visual structure: https://jessinvestment.com/claude-code-checkpoints-double-esc-to-undo-a-botched-edit/

Claude Code's New /goal Command Killed My Per-Turn Confirmation Loop

JessYT — Thu, 28 May 2026 14:44:30 +0000

Claude Code `/goal` and `claude agents`

Yesterday I had multiple Claude Code sessions running at the same time. But each session kept asking me "next?" every single turn, so I was bouncing between tabs hitting Enter and losing my mind.

All that inefficiency disappeared with one line: the new /goal command.

Written from the perspective of someone using the Week 20 update (May 11–15) — agent view + /goal — every day.

01. All my sessions, one screen (`claude agents`)

I used to flip between five terminal tabs and constantly lose track of which session was doing what.

Yesterday I ran claude agents for the first time. Every session lined up in one view, each showing running / blocked on you / done at a glance. I could immediately see where I needed to respond.

What I noticed: That single blocked on you label made a surprisingly big difference for me. Before, I had to peek into every tab to figure out where things were stuck. Now it's right there.

02. My biggest frustration, gone with `/goal`

The thing that bothered me most about Claude Code was the per-turn stop-and-ask. One "should I proceed?" would be fine, but the repetition wore me down. With multiple sessions running, that fatigue multiplies.

I tried /goal for the first time yesterday. My approach was simple.

$ claude
> /goal Keep going until this PR review is done and all tests pass.

# Claude grabs the completion condition (tests passing)
# and from then on, doesn't ask every turn — it just runs
# Only stops on blocked on user (= when a real decision is needed)

The impact was huge. Once I specified the completion condition, I didn't have to babysit it anymore.

03. The time savings I felt

I timed how long my per-turn answers were taking. Each response averaged 10–15 seconds. Drag one task through about 10 turns and that's 1–2 minutes per session. With five sessions, multiply by five.

After delegating with /goal, my time spent dropped to essentially zero. I clawed back about 10 minutes of attention.

And not hitting unnecessary Enters dropped my fatigue sharply.

04. Cases where `/goal` doesn't work well

After a few days of use, /goal worked best when the completion condition was clearly verifiable.

Tests passing, build succeeding, a specific file under N lines — cases like that.

On the flip side, it didn't suit me for the exploration or ideation phase.

In a "how should I even approach this" flow, answering every turn and thinking together actually produced better results.

My take: /goal is a tool for "execute to the finish once the direction is set," not for "finding the direction."

Sources

This is a first-person review after a few days of hands-on use. I received no sponsorship of any kind from Anthropic.

Originally posted at jessinvestment.com

Original with full infographics and visual structure: https://jessinvestment.com/claude-codes-new-goal-command-killed-my-per-turn-confirmation-loop/

Anthropic Opens a Korea Office as Claude Usage Surges 12x

JessYT — Wed, 27 May 2026 22:25:45 +0000

Korea Uses Claude 3.5x Its Expected Share — Anthropic Comes to Seoul

Anthropic is moving into Korea directly. On May 27, ahead of opening its Seoul office, it appointed its first Korea Representative Director. It's not a model launch, but for Korean developers it's more directly relevant news.

01 · The News: Anthropic Named a Korea Country Head

On May 27, 2026, Anthropic announced it had appointed KiYoung Choi, former Korea head of Snowflake, as Representative Director of Anthropic Korea. The Korean entity was already registered back in July 2025, and within weeks senior leadership from headquarters will visit Seoul to officially open the office. It's the entity going fully operational 10 months after registration.

Usage vs. population: 3.5× (Economic Index)
User growth in one year: 12× (year over year)
Claude MAU (April): 2.41M (ChatGPT 23.45M)
Korea entity registered: Jul 2025 (10 months ago)

02 · Why Korea: Few Users, but the Fastest-Growing Market

Anthropic's rationale is usage. By the March Economic Index, Korea's Claude usage runs more than 3.5× what you'd expect from its population. And it's concentrated in high-difficulty technical R&D and creative work. "One of the most sophisticated AI markets in the world" is how the company puts it.

On raw user count, ChatGPT dominates. As of April, monthly active users stood at 23.45M for ChatGPT and 2.41M for Claude. But Claude grew roughly 12× (+1,148%) in a year, spreading especially on coding and writing demand from men in their 20s.

	ChatGPT	Claude
April MAU	23.45M	2.41M
Position	#1 by user base in Korea	+1,148% YoY (~12× surge)
Note	Most monthly active users	20s · coding focus

03 · Who Leads: Korea's Lead Is a Cloud Sales Veteran

KiYoung Choi has led tech companies across Korea and Asia-Pacific for over 30 years. Most recently he was Korea head of Snowflake. The fact that he's an enterprise market builder, not a product engineer, tells you the direction.

KiYoung Choi — 30 Years of Tech Leadership

Korea head, Snowflake — most recent role, data cloud
COO, Microsoft Korea — enterprise operations lead
Google Cloud Korea leadership — drove cloud adoption
Adobe · Autodesk Korea leadership — global SaaS localization experience

04 · Position: What Changes for Developers

The Korea team's priorities are nailed down to three: enterprise and startup partnerships, government and research collaboration, and local developer community support. Law&Company already runs a Claude-based legal assistant, and SK Telecom has wired Claude into customer support. Once there's a local base, Korean-language billing, enterprise contracts, and local events all get closer.

Your code won't change overnight. But a local base means Korean-language support, tax invoices, enterprise contracts, and community events all move closer to reality.

What to watch: Office opening timing, and whether Korean-language payment · tax invoices arrive
Caution: ChatGPT has ~10× the users — Claude is still behind on scale

05 · Eddie's Take

"Once there's a local base, next come Korean-language invoices and local events. The key is that developer community support made the priority list."

— Eddie · 2026.05.27

It's not a new model launch, but for Korean developers it may be a more tangible change. Just watch the office opening timing and Korean-language payment support.

Sources · References

Original announcement

Anthropic — KiYoung Choi, Representative Director, Anthropic Korea

Press

User statistics

ZDNet Korea — ChatGPT still #1, but here's why Claude users surged 12x in a year

Disclaimer: An objective summary of an external announcement. No ads or affiliate links. Figures are as cited in press coverage (Anthropic Economic Index · April 2026 MAU).

Original with full infographics and visual structure: https://jessinvestment.com/anthropic-opens-a-korea-office-as-claude-usage-surges-12x/

Claude Code Now Ships a Real Code Review Command — Down to PR Comments

JessYT — Mon, 25 May 2026 22:21:19 +0000

Claude Code now has a real code review command

The old /simplify is now /code-review. It's not just a rename. The command now goes far enough to post its findings as comments directly on a GitHub PR.

Claude Code 2.1.147 · /code-review · --comment · May 21–22

01 · Not a rename — a change of job

The first line of the Claude Code 2.1.147 changelog, shipped on May 21, says the /simplify command became /code-review. It looks like a simple rename, but what it actually does has changed.

	Before (`/simplify`, gone)	Now (`/code-review`, first-class command)
Role	Code-simplification helper	Correctness bug review
Target	current code	current diff
Output	in the terminal	down to PR comments
Focus	refactor suggestions	correctness bugs

The key is that the focus moved. Instead of "make it cleaner," it now looks at "does this change have a bug?" Anthropic has said it runs code review on nearly every PR internally.

02 · What landed in this week's batch

Review effort: tunable — low→max selectable
PR posting: --comment — GitHub inline comments
/usage: by category — skill · subagent · MCP
/diff: keyboard — j · k · PgUp scroll

You can pick the review effort, from low to max. Low and medium surface only a few high-confidence flags, while high and max cast a wider net and catch the uncertain stuff too. In the same week, 2.1.149 made /usage break usage down by skills, subagents, plugins, and MCP servers, and let you scroll /diff from the keyboard.

03 · Where it slots into your workflow

/code-review use cases:

Run it locally once before opening a PR — It only looks at the current diff, so it stays focused on what changed.
Use low effort for busy PRs to get just the essentials — Less noise, high-confidence flags only.
Use --comment to put the review on the PR for important changes — Reviewers see it right inside GitHub.
Not a replacement for human review yet — Safer to treat it as a first-pass filter.

04 · The point is that it isn't a separate tool

The most striking part of this change is that code review didn't arrive as a separate tool — it came in as a single CLI command.

Why it matters: It stays inside your terminal workflow — no separate review bot to wire up.
What to watch: How much accuracy actually differs across effort levels is something you'll only learn by using it.

05 · Eddie's take

"The thing is, the review command doesn't just end on your screen — it goes out to the PR. If it were me, I'd wire it into the team pipeline as a first-pass filter first."

— Eddie

If you're already on Claude Code, update and run /code-review first. And if you've got the /simplify shortcut in muscle memory, just remember the name changed.

References

Claude Code official

Context

Anthropic News (Code with Claude)

Disclaimer: Based on the official changelog. Features may change by version. No ads or affiliate links.

Original with full infographics and visual structure: https://jessinvestment.com/claude-code-now-ships-a-real-code-review-command-down-to-pr-comments/

One bug cascaded into three failures across my LLM agent fleet. Here are the four guardrails I added.

JessYT — Mon, 25 May 2026 14:04:16 +0000

I run a small fleet of LLM agents on a Mac mini at home — about 44 scheduled jobs that draft, review, and publish blog content without me in the loop. Most of them call the Claude CLI, drive a headless browser with Playwright, and post to a blog.

For months it just worked. Then one night a single bug took down three different parts of the system at once, and I learned that "it just works" is the most dangerous state an autonomous system can be in.

This is what broke, and the four guardrails I added so it can't break the same way again.

The cascade

On May 9 one of my publish jobs failed. Then it failed again. By the time I looked, it had failed four times and my login provider had temporarily blocked the account.

The root cause was embarrassingly small. The publish script matched a blog category by running a snippet in the page context:

page.evaluate(fn, arg1, arg2)   # three arguments

Playwright's evaluate() takes a function and at most one argument. Passing more throws at runtime. That alone was a one-line fix. But it triggered a chain:

The Playwright misuse made the publish step throw every time.
The retry logic dutifully tried again. Four rapid login attempts in a few minutes looked like an attack, so the login provider rate-limited the account.
The Telegram bot that relays my messages to the agent saved its last_update_id after processing each message. When the agent crashed mid-message, the offset was never committed — so on restart it re-read the same message and crashed again. An infinite loop.

One bug. Three independent failure modes. None of them had a guardrail.

The fix wasn't "be more careful." It was four layers, each catching a different class of failure before it can cascade.

Layer 1 — A static guard for the exact bug class

The Playwright bug was detectable without running anything. So I wrote an AST check that scans the publish infrastructure for evaluate() calls with too many arguments, and run it on every change to those files.

def check_evaluate_arity(tree: ast.AST, filename: str) -> list[str]:
    errors = []
    for node in ast.walk(tree):
        if isinstance(node, ast.Call):
            if isinstance(node.func, ast.Attribute) and node.func.attr == "evaluate":
                if len(node.args) > 2:   # fn + at most one arg
                    errors.append(
                        f"{filename}:{node.lineno} — "
                        f".evaluate() got {len(node.args)} args (max 2). "
                        f"Wrap multiple args in a dict."
                    )
    return errors

The same script also flags destructive shell strings (pkill -9, rm -rf) embedded in Python, because those should live in a wrapper script where a separate guard can see them — not hidden inside a subprocess.run.

The lesson: when a bug class is statically detectable, don't rely on catching it at runtime. A linter that knows your one specific failure is worth more than a generic test suite.

Layer 2 — A rate-limit circuit breaker

The account block happened because nothing tracked how often I was hitting the login. So I added a circuit breaker: at most two login attempts per 15 minutes, then a 30-minute cooldown.

attempts = [t for t in history.get(blog, []) if now - t < WINDOW]  # 15 min
if len(attempts) >= MAX_ATTEMPTS:                                   # 2
    cooldown_remaining = COOLDOWN - (now - min(attempts))           # 30 min
    if cooldown_remaining > 0:
        notify_alert(f"login rate limit: {len(attempts)}/15min — "
                     f"{int(cooldown_remaining/60)}min cooldown")
        return False   # refuse, don't attempt

The key design choice is that the breaker refuses the action rather than just logging a warning. A warning nobody reads is not a guardrail. And it fails open on its own errors — if the breaker itself throws, it allows the attempt, because a broken safety check shouldn't take down the whole system.

Layer 3 — Idempotency and a restart guard

The infinite loop had two causes, so it needed two fixes.

First, commit the offset before doing the work, not after:

updates = get_updates(offset=last_update_id + 1)
if updates:
    last_update_id = max(u["update_id"] for u in updates)
    save_state()          # commit BEFORE processing
for u in updates:
    process(u)            # if this crashes, the message is not re-read

This is just idempotency: a message that has been seen should never be processed twice, even if processing it crashes. Moving one line above the work loop turned an infinite loop into a single dropped message — a far better failure.

Second, a restart guard. If the process restarts four times in one minute, something is wrong and restarting faster won't help. So it backs off:

history = [t for t in history if now - t < 60]
history.append(now)
if len(history) >= 4:
    notify_alert("rapid-restart detected — 1h cool-off")
    time.sleep(3600)      # stop flailing, let a human look

Crash-loops are how a small failure becomes a 2-day outage. The guard turns "restart forever" into "restart, notice, wait."

Layer 4 — Fail fast, never retry

The most counterintuitive lesson: for this system, retrying is the dangerous path. The retries are what got the account blocked. So the publish step now aborts on the first failure, preserves its work, and tells me.

def notify_publish_failure(blog, html_path, reason):
    """One failure = abort. No retry — repeated attempts cause the block."""
    send_alert(
        f"publish failed — aborting after 1 attempt (no retry)\n"
        f"blog: {blog}\nfile: {Path(html_path).name}\nreason: {reason}\n"
        f"HTML preserved. Publish manually after review, or wait for the next run."
    )

Automatic retry assumes failures are independent and transient. In a system that talks to a rate-limited third party, failures are correlated — the second attempt is more likely to fail and more likely to do harm. The draft is preserved, a human decides, and a daily job will come around again anyway.

Bonus — Letting the system find its own patterns

Once a week, a job feeds the last seven days of error logs and a running incident table to an LLM and asks one question: which failures recurred at least twice? Single transient blips and "expected" failures are filtered out. Only repeating patterns get written to a draft file for me to review.

It does not edit the incident log directly — it only proposes. I keep the review gate, because an automated system rewriting its own postmortems is exactly the kind of clever idea that produces the next incident.

Guardrails are never done

A week after I shipped all this, the fleet broke again — for a completely different reason. A Homebrew Python upgrade changed the interpreter's signature, macOS revoked its file-access permission, and a dozen jobs started failing with a misleading ModuleNotFoundError. And while I was fixing that, I managed to start three copies of the same bot, which then fought each other for the same message queue.

None of the four layers caught it, because it was a new class of failure. That is the actual lesson. You don't write guardrails to reach "done." You write them so that each incident can only happen once — and then you go collect the next one.

I run these agents to publish content while I work a full-time backend job. The full incident archive and guardrail code live in my notes; this is the part I think generalizes. Happy to compare notes if you operate something similar.

Original with full infographics and visual structure: https://jessinvestment.com/one-bug-cascaded-into-three-failures-across-my-llm-agent-fleet-here-are-the-four-guardrails-i-added/

I Use All 5 Claude Code Plugins Every Day — An Honest Breakdown

JessYT — Sun, 24 May 2026 22:48:02 +0000

I Use All 5 Claude Code Plugins Every Day — An Honest Breakdown

Hi, I'm Edi. A month ago I'd run Claude Code for a full year with zero plugins. Today I have five installed and I use all of them every day. I'll lay it all out honestly: what's installed, when each one fires, and the difference between not having it vs having it. No ads, no sponsorship — just my own measured experience.

01 · My 5 Plugins — I use all five daily, in the order I installed them

Bottom line. My first year ran on zero plugins. A month ago (2026-04-26) I started with one — frontend-design — and on May 12 I added four more in a single day. All five have now settled into a daily or near-daily cadence.

Here are the five, ordered by how often I use them, with a one-line note on what situation triggers each.

`frontend-design` — DAILY · installed 2026-04-26

When it fires. Every time I write a post in my v2 infographic style. It auto-applies the magazine card system, light-tone readability, and my dark-box avoidance rules.

I trigger it inside all five of my post-generation jobs (run-daily · run-devtools-daily · run-weekly · run-ai-intro, etc.).

`hookify` — DAILY · installed 2026-05-12

When it fires. Right after an automation job has an incident, or when I need a new guard rule. I'm running 2 PreToolUse hooks + 1 PostToolUse hook.

My flow: check the current state with /hookify:list → write a new rule with /hookify:hookify → it lands in settings.json automatically.

`skill-creator` — DAILY · installed 2026-05-12

When it fires. Whenever I build a new skill or tweak an existing one. I carry 8 project skills (add-launch-job · blog-style-guide, etc.).

It handles the SKILL.md frontmatter format · description tuning · even the eval in one pass, so the cost of adding a skill is basically zero compared to hand-rolling it a year ago.

`telegram` — DAILY · installed 2026-05-12 (external)

When it fires. Two-way messaging between a Claude Code session ↔ my phone. I use it for interviews and instant job-debugging replies.

To avoid a token clash with my existing yongBlogBot, I spun up a separate bot via BotFather and paired it exclusively to the plugin.

`playwright` — DAILY · installed 2026-05-12 (external)

When it fires. Debugging publish jobs · inspecting pages. I keep the actual publish code in lib/ Python untouched and use the MCP browser tools only for debugging.

I don't rip out the publish job code all at once — I observe for a week → confirm it's stable → migrate gradually.

02 · Before vs After — The gap is bigger than I expected

Bottom line. For a year I held the "take it or leave it" view. After a month with them, I realized that the time freed up from hand-editing got filled with actual writing time.

Here's how I did each task without the plugin, and how it changed with it — all in one table.

Plugin	Without it (my year)	With it (one month in)
frontend-design	AI output came out as generic boxes. I hand-edited the v2 infographic design stitch by stitch.	Magazine cards · light-tone rules applied automatically. Almost zero design hand-editing.
hookify	Hand-edited settings.json directly. Looked up matcher syntax every time. Guessed at what would fire.	One line with `/hookify:list` shows the state. Rule writing is standardized. Less debugging time.
skill-creator	Started from a blank SKILL.md. Re-checked the frontmatter every time. Never wrote evals.	Auto format · description tuning · eval package. Zero cost to add a skill.
telegram	Wrote my own polling by hand with my own bot. Paired it manually. 700+ lines of two-way code.	Pair once. Session ↔ phone, two-way, instantly. Less weight on interview jobs.
playwright	Did all publish jobs directly in lib/ Python. To debug, edit code then re-run.	Inspect pages instantly with MCP browser tools. The publish jobs stay intact — it just assists.

Looking at the table taught me one thing. A plugin isn't a "new feature" — it's "automating the manual work I was already doing." All five took over something I'd been doing by hand for a year.

03 · How to Find — I locked in 4 criteria for finding a good plugin

Bottom line. I learned that if you open the marketplace and install everything that looks cool, your menu turns into a mess within days. So I run a 4-step check before installing anything.

Map your own workflow first. Standardizing what you already do often is the highest ROI. For me, that was hookify · skill-creator.
Official first, external only after vetting. Anthropic's official ones are verified. For external ones, you must check for token · credential clashes. When I installed telegram (external), I built a separate bot to avoid a bot-token clash.
One-week trial → measure ROI. If you're not using it, remove it immediately. Leaving things installed clutters the menu and causes command clashes. All five of mine survived past the one-month mark.
Don't rip out operational code like publish jobs. Even after adopting playwright, I left my lib/ Python publish code as-is. Observe for a week to confirm no stability impact, then migrate gradually — that's the safe path.

# 1. Open the marketplace
$ /plugin

# 2. Browse the official category first
   ↓ prioritize verified plugins
   ↓ vet external ones for clashes

# 3. Install one at a time (not several at once)
$ /plugin install hookify@claude-plugins-official

# 4. Use for a week → remove if unused
$ /plugin uninstall <the one you don't use>

04 · My Recommend — If you're just starting, I'd recommend three, in this order

Bottom line. All five are good, but if you're just starting, don't be greedy — look at three first. I'd recommend the order skill-creator → telegram → hookify.

The first three touch almost every workflow. The other two are optional.

#1 · skill-creator — The first step to turning your workflow into an asset. It's the fastest path to baking your repetitive work into a skill.
#2 · telegram — Session ↔ phone, two-way. Getting answers on your phone from inside a Claude Code session touches daily life more often than you'd think.
#3 · hookify — Safety net + guard rules. If you have even one automation job, you'll need a hook at some point. /hookify:hookify standardizes the rule writing.
optional · frontend-design — Only for people who touch blog · magazine design often. If you're backend-focused, you can skip it.
optional · playwright — Consider it if you do publish automation · web scraping often. Migrate operational code gradually, after a week of observation.

Coda — In the end, the answer is: I use all five every day

A month ago I ran a full year on zero. Now I use all five daily, and I can't go back. The way I see it, a good plugin isn't a new feature — it takes over the manual work.

— Edi · after one month of use

Edi's note: Don't install them all at once. Use one at a time for a week and drop it the moment the ROI isn't there — that's how you keep the menu clean.

A plugin isn't a new feature — it's the automation of manual work.

References

Claude Code official

Primary data

EDIBLOG · one month running five plugins, my own asset (first-hand)
My own setup · 39 automation jobs · 8 custom skills · 56 lib scripts

Disclaimer: this is my personal operating retro. Results may vary by environment. No ads · no affiliates.

Original with full infographics and visual structure: https://jessinvestment.com/i-use-all-5-claude-code-plugins-every-day-an-honest-breakdown/

Warp vs Ghostty vs iTerm2 — The 2026 Mac Terminal Landscape After Open Source

JessYT — Sun, 24 May 2026 06:14:22 +0000

The Mac terminal big three — as of May 2026

Warp open-sourced under AGPLv3 on April 29, and the comparison got reshuffled one more time. Here's who should be running which terminal, in one place.

"Which terminal should I use on a Mac?" is a question whose answer changes about every six months. A year ago it was "iTerm2 is the standard, Warp is a newcomer worth a look." It's not that simple anymore.

On April 29, 2026, Warp released its entire client under AGPLv3. Around the same time Ghostty 1.3 shipped, and iTerm2's AI integration beta moved close to GA. I reinstalled all three this week and ran them side by side, and my conclusion is there's no single winner — you have to split them by use case.

The three-line verdict.

If AI workflows are part of your daily life, go Warp. The open-sourcing removed the closed-source baggage.
If lightweight and fast is your top priority, go Ghostty. This is where real GPU acceleration is clearest.
If stability, plugins, and "it always just works" come first, go iTerm2. Nothing matches 12 years of accumulated detail.

One-line comparison table

Item	Warp	Ghostty	iTerm2
License	AGPLv3 + MIT (UI)	MIT	GPLv2
AI integration	Built in (multi-model)	None (use external tools)	AI Plugin (beta)
GPU rendering	Metal	Metal (native by design)	Metal (optional)
Configuration	GUI-centric	Text file	GUI + plist
Platforms	macOS, Linux, Windows	macOS, Linux	macOS only
Price	Free for individuals, paid for team/AI	Fully free	Fully free

Warp — for people whose daily work is AI workflows

Warp's strength starts with treating commands as "blocks." Input and output are captured as a single unit, and you can copy, share, or re-run that whole unit. AI integration sits naturally on top of that — ask about a command you don't know in plain language and it synthesizes it right away.

The April 29, 2026 change was significant. The client was released under AGPLv3, and OpenAI joined as a Founding Sponsor, which broadened the model choices. For anyone who refused Warp because it was closed-source, this is the biggest new variable.

The downsides are still there. It's the heaviest install of the three, and because it's GUI-centric, syncing config is fiddly if you're used to dotfiles. And fully exercising the AI features needs a paid plan to be smooth.

Recommended for: anyone who asks AI about commands every day, or frequently shares long command output with teammates. A great fit for infra/DevOps roles.

Ghostty — when you just want "fast and light"

Ghostty is a terminal that Mitchell Hashimoto (HashiCorp's founder) rebuilt from scratch as GPU-native. With 1.3.0 landing in April 2026, scrollback search arrived, and it made it into Ubuntu 26.04's official repository.

Its design philosophy is clear. "A terminal is just a terminal" — no AI integration, no block-level abstraction; instead it focuses on the essentials like rendering speed, standard terminal compatibility, and key-input latency. Config is a single text file, so you can drop it straight into your dotfiles, which makes it an obvious workflow for vim users.

The downside fits in one line: "it has fewer features." Split panes, hotkeys, and themes all work, but modern integrations like "ask AI about a command" you have to wire up yourself with external tools. For people who've built their workflow out of tmux + fzf + their own shell scripts, that's actually a plus — but if that's a burden, it's not for you.

Recommended for: anyone for whom speed matters most and who manages config through GitHub dotfiles. The neovim/tmux crowd.

iTerm2 — when "hasn't stopped in 12 years" is what matters

iTerm2 has been maintained for over 14 years, since 2009. Its stability, breadth of features, and plugin ecosystem are the deepest of the three. Split panes, a hotkey window, a password manager, shell integration, tmux integration — everything is in its place.

In 2026, what stands out is that the AI Plugin is working well at the beta stage. It's not as seamless as Warp, but integrations like command autocompletion or sending an error to an external LLM for analysis are plenty practical. You set it up by plugging in your own OpenAI/Claude key.

The downside is the GUI design. Charitably, it's classic; honestly, it looks a bit dated. And being macOS-only, it has limits if you move between Linux/Windows environments.

Recommended for: the "do I really need to switch when I'm already using it fine?" camp who stays put. And it's still the safest default for a beginner picking their first terminal.

So how should you actually choose?

Here's a line for each situation.

Ask AI about commands daily, share command output with teammates often → Warp
Manage config via dotfiles, bothered by key-input latency, neovim user → Ghostty
Already using it fine, can't be bothered to set it all up again, stability first → iTerm2
Stability on the work Mac + experiments on the personal Mac → iTerm2 (work) + Warp/Ghostty (personal) is a natural combo too

One thing worth flagging. Before Warp open-sourced, "it's closed-source, so we can't use it at work" was the most common reason for rejecting Warp. Now the opposite is possible too — a scenario where a company runs its own self-built Warp. As of the first week of May, it's worth a fresh evaluation.

My two cents.

I've honestly run all three as my main terminal for a stretch each. That's exactly why I can't land on a single answer. Right now I split it: iTerm2 on the work Mac (stability), Warp on the personal work Mac (AI workflows), and on a small side-project Mac mini I keep Ghostty installed for lightweight SSH work.

The reason I can't unify on one is that all three are well made, but their strengths point in different directions. Over the next month I plan to track the self-built cases that emerge after Warp's open-sourcing — I'm curious where the first instance of a company self-hosting Warp will show up.

Frequently asked questions

Q. If Warp is open source now, is it safe to use at work without worrying?

A. The license (AGPLv3) itself is fine for in-house use, but the moment you use the AI features, your input context goes out to an external model — that hasn't changed. First check whether your company's security policy even allows sending command input externally, and if needed there's an option to use it with the AI features turned off.

Q. What's the difference between Ghostty and Alacritty/Kitty?

A. All three are GPU-accelerated terminals, so the broad category is the same, but Ghostty has the smoothest native macOS SwiftUI integration and tends to care more about standard terminal compatibility. Alacritty/Kitty's strength is cross-platform consistency, and if you're already comfortable with one of them, there's little reason to switch.

Q. Can I use the iTerm2 AI Plugin with just a ChatGPT key?

A. You can use it by entering your OpenAI API key directly, and a Claude key can be set up the same way. The catch is that token usage is billed directly to your own account, so if you leave automatic command analysis on, it's wise to set a limit in advance.

References

This post combines public sources with the author's own usage experience. Validate any concrete adoption against your own environment (security policy, dotfiles setup, AI usage frequency).

Canonically published at jessinvestment.com.

Original with full infographics and visual structure: https://jessinvestment.com/warp-vs-ghostty-vs-iterm2-the-2026-mac-terminal-landscape-after-open-source/

DEV Community: JessYT

Raycast: Why I Use It Instead of Spotlight

Raycast: Why I Use It Instead of Spotlight

Spotlight already works — so why switch?

How to set it up on first launch

What you can use right after installing

Clipboard History — pull back what you copied

Window Management — tile windows with the keyboard

Snippets — autocomplete phrases you reuse

Quicklinks · Calculator · Search

The real difference comes from the Store

One step further — register your own scripts as commands

How far does free go, and what's paid?

Gotchas worth knowing in advance

So who is it for?

Sources

How One Word 'Workflow' Spins Up Hundreds of Claude Code Agents

How One Word 'Workflow' Spins Up Hundreds of Claude Code Agents

One word, "workflow," and Claude writes the script itself

The real story was how it differs from my automation

I ran one small workflow myself

Still, I didn't tear down my cron jobs

Claude Code's /reload-skills Ended My Constant Session Restarts

Claude Code can finally reload skills without a session restart

I was restarting whole sessions to fix one line in a skill

/reload-skills rescans in one line

I wired it into my SessionStart hook too

There are still times you have to restart

Opus 4.8's Default 1M Context Window Is the Upgrade I Notice Most

Opus 4.8: the default 1M context window is what I notice most in long sessions

Opus 4.8 shipped on May 28

For someone running long sessions, this was the big one

The benchmarks and honesty gains are from the announcement

Fast mode got faster and cheaper

What I'm watching over the next few days

Opus 4.8 Launched, but Fast Mode Was the Real Win for Me

Opus 4.8 Launched, but Fast Mode Was the Real Win for Me

01. Same price, just a better model

02. How the benchmark table changed

03. For me, fast mode was the real story

04. I can't speak to the coding feel yet

Sources

Claude Code Checkpoints: Double-Esc to Undo a Botched Edit

Claude Code Checkpoints: Double-Esc to Undo a Botched Edit

01. Yesterday I pressed Esc twice for the first time

02. /rewind for a more explicit revert

03. The difference from git reset, as I see it

04. /goal delegation finally feels safe

05. A case where it doesn't work so well, in my view

Sources

Claude Code's New /goal Command Killed My Per-Turn Confirmation Loop

Claude Code /goal and claude agents

01. All my sessions, one screen (claude agents)

02. My biggest frustration, gone with /goal

03. The time savings I felt

04. Cases where /goal doesn't work well

Anthropic Opens a Korea Office as Claude Usage Surges 12x

Korea Uses Claude 3.5x Its Expected Share — Anthropic Comes to Seoul

01 · The News: Anthropic Named a Korea Country Head

02 · Why Korea: Few Users, but the Fastest-Growing Market

03 · Who Leads: Korea's Lead Is a Cloud Sales Veteran

04 · Position: What Changes for Developers

05 · Eddie's Take

Sources · References

Claude Code Now Ships a Real Code Review Command — Down to PR Comments

Claude Code now has a real code review command

01 · Not a rename — a change of job

02 · What landed in this week's batch

03 · Where it slots into your workflow

04 · The point is that it isn't a separate tool

05 · Eddie's take

References

One bug cascaded into three failures across my LLM agent fleet. Here are the four guardrails I added.

The cascade

Layer 1 — A static guard for the exact bug class

Layer 2 — A rate-limit circuit breaker

Layer 3 — Idempotency and a restart guard

Layer 4 — Fail fast, never retry

Bonus — Letting the system find its own patterns

Guardrails are never done

Claude Code `/goal` and `claude agents`

01. All my sessions, one screen (`claude agents`)

02. My biggest frustration, gone with `/goal`

04. Cases where `/goal` doesn't work well

`frontend-design` — DAILY · installed 2026-04-26

`hookify` — DAILY · installed 2026-05-12

`skill-creator` — DAILY · installed 2026-05-12

`telegram` — DAILY · installed 2026-05-12 (external)

`playwright` — DAILY · installed 2026-05-12 (external)