DEV Community: Hisashi Space

Claude vs GPT-6.1 Terra: Half the Price. I Tested It on My Real Work.

Hisashi Space — Tue, 03 Nov 2026 13:00:00 +0000

Using Claude? OpenAI's new GPT-6.1 Terra is half the price of Claude Sonnet.

I run about forty Claude sessions a day, so a model at half the price is worth a real look.
I made a video about it, but a video can only show a few numbers.
This article has all of them: every price, every effort setting on OpenAI's charts, two independent tests, and my own test with the exact prompts, timings and token counts, so you can run it yourself.

The short version

Terra is exactly half the price of Claude Sonnet 5.5 per token. But Anthropic already sells a model at Terra's exact price (Haiku 4.5), and Haiku 5.5 is ten times cheaper.
On OpenAI's own charts, Terra comes close to Claude Opus 5.5 on computer use at about one ninth of the cost per task.
On coding in the terminal, Terra is far behind Claude Sonnet 5.5: 50.3% against 70.6%. OpenAI itself says to use its bigger models for complex coding.
The effort setting matters as much as the model. On OpenAI's computer use test, Terra at its lowest setting costs one sixth of Terra at max, and scores only about 4 points lower.
In my test, Terra did three small real jobs correctly and finished each one 1.4 to 1.8 times faster than OpenAI's bigger Sol. I did not time Claude.

What GPT-6.1 Terra is

OpenAI now names its models Luna, Terra, Sol and Astra, from small to large.
Terra sits above Luna and below Sol and Astra.
It came out on October 26, 2026.

Here is what the model docs say.

Item	GPT-6.1 Terra
Where you can use it	ChatGPT (Plus, Pro, Enterprise, Edu), Codex, and the API as gpt-6.1-terra
Context window	1,050,000 tokens (max input 922,000)
Max output	128,000 tokens
Input / output	Text and images in, text out. No audio, no video
Knowledge cutoff	June 1, 2026
Effort settings	none, low, medium (default), high, xhigh, max
API rate limits (Standard)	Build 5,000 requests/min, 1M tokens/min. Launch 10,000 / 4M. Grow 15,000 / 40M
Fine-tuning	Not available

The announcement names Plus, Pro, Enterprise and Edu.
Free, Go and Business are not named.

The price, next to every Claude model

API prices per million tokens.

Model	Input	Output
Claude Haiku 5.5 (prompts up to 100K tokens)	$0.10	$0.50
Claude Haiku 5.5 (prompts over 100K tokens)	$0.50	$2.50
Claude Haiku 4.5	$1	$5
GPT-6.1 Terra	$1	$5
Claude Sonnet 5.5	$2	$10
Claude Opus 5.5	$4	$20

Two things most launch posts missed.

First, OpenAI's own "50% lower" is against its own models, GPT-5.6 Terra and GPT-6.1 Sol.
It is not a claim about Claude.
It just happens that Sonnet 5.5 is also $2 and $10.

Second, if you already live in Claude, the model at Terra's price is Haiku 4.5.
And Haiku 5.5 is ten times cheaper than Terra.
So Terra is not the cheap option. It sits between Haiku and Sonnet.

Caching changes the real bill

The price table is for fresh input.
Terra also has a cache.

Terra token type	Price per 1M tokens
Input	$1.00
Cached input	$0.05
Cache writes (kept 30 minutes)	$1.25
Output	$5.00

This matters for agents.
An agent session reads the same long context again and again: the files, the rules, the history.

Here is the math with the official prices.
Say a session has a 100,000 token context and makes 20 calls, each writing 2,000 tokens.

Without the cache: 20 × 100,000 = 2,000,000 input tokens = $2.00. Output 40,000 tokens = $0.20. Total $2.20.
With the cache: one write of 100,000 tokens = $0.125. Then 19 reads of 100,000 cached tokens = $0.095. Output $0.20. Total about $0.42.

That's about five times cheaper, from the cache alone.
The catch is the 30 minutes.
If your agent waits longer than that between calls, it pays to write the cache again.

Claude has a prompt cache too, so this is not a Terra only discount.
From Anthropic's pricing page, per million tokens:

Model	Input	Cache write (5 min)	Cache write (1 hour)	Cache read	Output
GPT-6.1 Terra	$1.00	$1.25 (30 min)		$0.05	$5.00
Claude Haiku 4.5	$1.00	$1.25	$2.00	$0.10	$5.00
Claude Sonnet 5.5	$2.00	$2.50	$4.00	$0.10	$10.00

The same session on Claude, with the 5 minute cache:

Claude Sonnet 5.5: $4.40 without the cache, about $0.84 with it.
Claude Haiku 4.5: $2.20 without the cache, about $0.52 with it.
GPT-6.1 Terra: $2.20 without the cache, about $0.42 with it.

So with caching on both sides, Terra is still half of Sonnet.
Against Haiku 4.5, the gap is small: the price list is the same, and only the cache read differs ($0.05 against $0.10).
Claude's cache lasts 5 minutes by default, or 1 hour if you pay twice the input price to write it. Terra keeps it for 30 minutes.

So for agent work, compare the cached price, not just the headline price.
A Hacker News post on October 27 redid the price comparison for exactly this kind of cache-heavy session.

OpenAI's charts, every setting

OpenAI published four charts that compare Terra with Claude.
The video showed one number from each.
Here is every point, from the data inside the charts on OpenAI's announcement page.
These are OpenAI's numbers, not independent ones.

Agents' Last Exam (the AI uses a computer to do professional work)

Model	Effort	Score	Cost per task
Claude Opus 5.5	Max	63.2%	$8.82
GPT-6.1 Terra	Max	60.0%	$1.01
GPT-6.1 Terra	Xhigh	58.5%	$0.66
GPT-6.1 Terra	High	57.2%	$0.39
GPT-6.1 Terra	Medium	57.6%	$0.29
GPT-6.1 Terra	Low	55.9%	$0.16
GPT-6.1 Sol	Max	58.6%	$2.00
GPT-5.6 Terra	Max	50.7%	$3.58

Opus still leads, by 3 points, at nearly nine times the cost.
Terra at Max also beats OpenAI's bigger Sol at Max, for half the cost.

OSWorld 2.1, offline set (using desktop apps)

Model	Effort	Score	Cost per task
Claude Sonnet 5.5	Max	83.9%	$5.74
Claude Sonnet 5.5	Xhigh	81.0%	$2.22
Claude Sonnet 5.5	High	73.3%	$1.39
Claude Sonnet 5.5	Medium	65.9%	$0.93
GPT-6.1 Sol	Max	78.0%	$1.15
GPT-6.1 Terra	Max	74.2%	$1.19
GPT-6.1 Terra	Medium	66.7%	$0.50

Sonnet wins at the top.
At the same budget of about $1.20 to $1.40 per task, Sonnet High and Terra Max score about the same.
And look at Sol: 78.0% at $1.15, a higher score than Terra Max for slightly less money.
On this chart, the cheaper model is not the better deal.

Terminal-Bench 4.0 (coding in the terminal)

Model	Effort	Score	Cost per task
Claude Sonnet 5.5	Max	70.6%	$10.44
Claude Sonnet 5.5	Xhigh	61.5%	$4.34
Claude Sonnet 5.5	High	43.0%	$1.46
GPT-6.1 Sol	Max	55.9%	$1.98
GPT-6.1 Sol	Low	47.1%	$0.76
GPT-6.1 Terra	Max	50.3%	$1.84
GPT-6.1 Terra	Xhigh	46.4%	$0.99
GPT-6.1 Terra	Medium	35.8%	$0.46

This is the one place Terra falls way behind.
Sonnet at Max is 20 points ahead.
Even inside OpenAI's lineup, Sol at Low (47.1%, $0.76) beats Terra at Xhigh (46.4%, $0.99).
OpenAI says it plainly: "For the most complex coding tasks, GPT-6.1 Sol and GPT-6 Astra remain the better choice."

Terminal-Bench-Science 0.1

Model	Effort	Score	Cost per task
Claude Opus 5.5 with fallbacks	Max	63.3%	$23.21
GPT-6.1 Terra	Max	58.3%	$4.15
GPT-6.1 Sol	Max	57.0%	$5.47

Here Terra Max edges past Sol Max, and costs less than a fifth of Opus.

The effort setting is a second price list

The tables above show something the headline price hides.
The same model costs very different amounts depending on how hard you let it think.

On Agents' Last Exam, Terra at Low scored 55.9% for $0.16 per task.
At Max it scored 60.0% for $1.01.
That's about six times the cost for about 4 more points.
And Medium (57.6%) actually scored a little higher than High (57.2%).

On Terminal-Bench, it goes the other way.
Terra climbs from 35.8% at Medium to 50.3% at Max.
For hard coding, the extra thinking is worth more.

So pick the effort per job, not per model.
For checks and short answers, start low and go up only if the answers get worse.

Fewer made up answers

OpenAI also published an internal test of how often the model states something wrong.

Model and setting	Error rate
GPT-5.6 Terra, lowest effort	53.6%
GPT-6.1 Terra, lowest effort	16.7%
GPT-6.1 Terra, max effort	4.3%

People on Hacker News called the drop "staggering".
It's still OpenAI's test and OpenAI's number, with no Claude on the chart.

Independent tests

Two independent sites test every model the same way.

Artificial Analysis (read November 2, 2026)

	GPT-6.1 Terra (Max)	Claude Sonnet 5.5 (Max)
Intelligence Index v5.0	51	54
Rank of 59 models	13th	9th
Output speed	106.8 tokens/s	138.4 tokens/s
Cost per index task	$0.96	$10.02

Sonnet is 3 points smarter on this index, and about ten times more expensive per task.
Note the speed row: on Artificial Analysis, Sonnet writes its output faster than Terra.
"Faster" in OpenAI's announcement means faster than OpenAI's own bigger models.

Vals AI

Vals ranks Terra 11th of 32 models, with a Vals Index of 60.54%.
Its own Terminal-Bench 4.0 run gave 49.49%, close to OpenAI's 50.3%.
And it noted something useful: on legal and tax questions, Terra "often declines to reach conclusions".
If those are your questions, Terra is not your model.

What Hacker News argued about

The launch thread got 637 points and 427 comments.
The main threads:

"Can anyone give me the compelling reason for Terra and Sonnet to exist?" The argument: you can go up a tier with less thinking, or down a tier with more.
The names. Luna, Terra, Sol and Astra confused a lot of people.
Terminal-Bench looks weak. One comment: Terra at Xhigh costs more than Sol at Low and still does worse. The table above shows the same.
Price against score charts are chosen by the vendor, so some called them "mostly uninformative".
And the positive one I agree with: "This tier is what I'd actually point opencode at for PR reviews. The top models are too slow and expensive to run on every diff."

My test: 3 real jobs

Charts are charts, so I gave Terra three jobs from my own week.
I gave the same jobs to OpenAI's bigger Sol, to see what you lose by going cheaper.

Setup: Codex CLI 0.164.0 on my Mac, signed in with my ChatGPT plan (not the API).
Each job ran on each model twice: effort "none" (my Codex default) and "medium" (the API default).
One run each, timed with time, including Codex startup.

Job 1: a YouTube description with chapters.
The prompt:

Read the file (path to my script). It is the script for my English YouTube video (the English column is the narration). Write a YouTube description for it: exactly 5 lines of English text, then a chapters list starting at 0:00 with at least 3 chapters (estimate timestamps from the script, about 150 spoken words per minute). Do not use em dashes or en dashes. Output only the description.

The script was my previous video about the AI bubble.
All four answers followed every rule: 5 lines, no dashes, 11 chapters from 0:00.
The chapter times were almost the same across models.
Terra at Medium added the concrete names from the script (Anthropic, CoreWeave, Tokyo).
I found no factual errors. I'd paste any of them with light edits.

Terra's first line at none: "What happens to the AI tools you rely on if the bubble pops?"
Sol's: "If the AI bubble pops, what happens to the tools you use every day?"

Job 2: checking an illustration.
Every illustration in my videos gets checked for impossible phones and laptops: a screen on the back, a lid on the wrong side.
The prompt:

This is an illustration for an Instagram carousel. Check only one thing: is the smartphone drawn correctly? The screen must face the person holding it, and there must be no screen on the back of the phone. Answer OK or NG on the first line, then explain in 2 to 3 sentences what you see.

All four answered OK and described the back of the phone with the camera facing the viewer.
That's correct. I checked the drawing myself.
Terra at none: "The visible side of the phone has a camera lens and no screen, so it appears to be the back."

Job 3: fixing a bug.
A small script that lists the days a video is scheduled to post. It drops the last day of the range.
The prompt:

Users report that the schedule printed by schedule.py is missing the last day: posting_days(start, end) should include both start and end. Find the bug, fix it in schedule.py, and run python3 schedule.py to check. Then explain the fix in one sentence.

All four fixed it and ran the script, which printed November 1 to November 7.
They fixed it in two different places, and both are correct.

# Terra (none)
-    n = (end - start).days

+    n = (end - start).days + 1

# Sol (none)
-    for i in range(n):

+    for i in range(n + 1):

I ran every fixed file again myself. All four printed all seven days.

The results

Job	Terra none	Sol none	Terra medium	Sol medium
Description	15.9 s, 12,889 tokens	25.6 s, 13,376 tokens	15.4 s, 17,965 tokens	23.6 s, 13,406 tokens
Drawing check	6.9 s, 2,820 tokens	9.8 s, 7,236 tokens	6.9 s, 16,971 tokens	10.3 s, 20,583 tokens
Bug fix	12.9 s, 16,700 tokens	22.5 s, 7,113 tokens	9.7 s, 6,781 tokens	17.1 s, 7,141 tokens

What I read from it:

Terra was faster than Sol on every job, 1.4 to 1.8 times. Not the "over three times" in OpenAI's announcement, but these jobs are so small that Codex startup is a big part of the time.
Faster does not mean fewer tokens. On the bug fix at none, Terra used 16,700 tokens and Sol 7,113.
Medium effort can multiply tokens on easy jobs. The drawing check went from 2,820 to 16,971 tokens on Terra, with the same answer.
Quality: I couldn't see any difference. Every answer was usable.

Run the same test yourself

These are the commands I used, with Codex CLI signed in to ChatGPT.

# Job 1: text from a file
codex exec -m gpt-6.1-terra --skip-git-repo-check -C ./work "<prompt>"

# Job 2: an image
codex exec -m gpt-6.1-terra --skip-git-repo-check -C ./work -i drawing.png "<prompt>"

# Job 3: let it edit files in the folder
codex exec -m gpt-6.1-terra --skip-git-repo-check -s workspace-write -C ./work "<prompt>"

# Same job on Sol, or at another effort
codex exec -m gpt-6.1-sol ...
codex exec -m gpt-6.1-terra -c model_reasoning_effort=medium ...

Put time in front to get the seconds.
Codex prints "tokens used" at the end of each run.

What I didn't test

To be fair:

I didn't time Claude on these jobs. So I'm not saying Terra is faster than Claude.
I only gave it a drawing that was correct. I don't know yet if it catches a broken one.
One run per setting. Times will move a little from run to run.
Small jobs only. Nothing here tests the long, hard coding where Sonnet leads by 20 points.
Codex on my ChatGPT plan shows tokens, not dollars. So I have no cost per job of my own.

Which model for which job

Am I switching? No. This is how I'm splitting the work.

Job	Model	Why
Long coding across a whole project, sessions that run for hours	Claude	Sonnet leads Terra by 20 points on Terminal-Bench 4.0
Small, repeated checks (drawings, formats, rules)	Terra or Haiku, low effort	Good enough, faster, cheaper. My drawing checks already go to Codex
Code review on every change	Terra	The Hacker News point: top models are too slow and expensive for every diff
Computer use on a budget	Terra Max or Sonnet High	About the same score at about the same cost per task
Legal and tax questions	Not Terra	Vals AI: it often won't reach a conclusion
Agent sessions that reread the same context	Whatever you pick, use the cache	Cached input is $0.05 instead of $1.00 on Terra

The long, hard work stays on Claude: planning, writing code across a whole project, running for hours on my Mac.
The small, repetitive checks go to the cheapest model that's good enough.
Terra just made that side cheaper and faster.

And if you're on a budget and you live in Claude, check Haiku before you leave.
It might already be the cheap model you're looking for.

Try it yourself in 1 hour

Pick three jobs you do every week. Small ones.
Give each one to two models: the one you use now, and the cheaper one.
Run each at a low effort first. Time them, and check the answers yourself.

If the cheap one is good enough, move just that job.
Not your whole setup. One job at a time.

Don't pick a team

Every few months, someone releases a model that's cheaper, faster, or smarter.
If you pick a team, you'll be switching forever.

Don't pick a team. Pick the job. Then pick the model.

Sources: OpenAI's GPT-6.1 Terra announcement (October 26, 2026; benchmark numbers from the data inside its charts) and model docs, Anthropic's pricing page, Artificial Analysis and Vals AI (read November 2, 2026), and the Hacker News launch thread. Benchmarks are OpenAI's own numbers unless marked otherwise. My test: GPT-6.1 Terra and GPT-6.1 Sol in Codex CLI 0.164.0 on November 2, 2026, one run each. Claude was not timed in my test.

If the AI Bubble Bursts, What Happens to Your AI Tools? I Ran a Business Through 2 Crashes

Hisashi Space — Mon, 02 Nov 2026 08:52:05 +0000

If the AI bubble pops, what happens to the tools you use every day?

I've run a business through two crashes.
Here's what actually happened, and what I'm doing this time.

I also made a video of this.

This week: Anthropic files to go public

On Monday, October 26, Anthropic, the company behind Claude, filed to go public.
It's going to list on the Nasdaq under the ticker ANT.

The filing shows more than $16 billion in revenue in just six months.
That's fourteen times the year before.

It also shows an $80 billion loss.
Most of that is a one-time accounting charge, about $72 billion.
But even without it, this is a company burning money at a scale we've never seen.

The risk section alone runs almost a hundred pages.
And reports say it could be valued at $1.5 to $2 trillion.

Then there's CoreWeave. They rent out the chips that run these AI models.
On October 14, their stock dropped about 15% in a day, because the interest on their debt climbed to around 15%.

So people are asking: is this the top? Is it about to pop?
Some big banks say no, this is a boom, not a bubble. Others are less sure.

I'm not going to predict the stock market. Nobody can.
What I can tell you is what happened to people like me the last two times.

2000: the dot-com crash

In March 2000, the Nasdaq hit about 5,000.
Two and a half years later, it was at about 1,100. That's a 78% drop.

Pets.com, which had a Super Bowl ad, shut down that same year.
Hundreds of startups just vanished.

Amazon's stock went from about $107 to about $6. More than 90% gone.
People called it Amazon.bomb.

And here's what I want you to notice.
Google was founded in 1998, and it launched its ad business in 2000, right in the middle of the crash.

The internet didn't die. Email didn't die. Search didn't die.
The companies crashed. The tools stayed.
And the tools got cheaper.

2004: starting my business after the crash

That's the world I walked into.
I started my web business in Tokyo in 2004, right after the crash.
Servers were cheap, and the people who were left knew what they were doing.

I didn't have investors. I didn't have a team.
I just built small things that people actually paid for.

2008: Lehman Brothers

Then came 2008.
On September 15, Lehman Brothers collapsed. It was the biggest bankruptcy in American history.

This crash was different. It wasn't about websites. It was about borrowed money.
Overnight, it got hard to borrow anything.

Companies that ran on debt went down first.
Companies that ran on real customers paying real money mostly survived.
Mine did.

Is today 2000 or 2008?

Honestly, a bit of both.

Like 2000, there's a ton of hype, and valuations that assume everything goes perfectly.

Like 2008, a lot of it runs on borrowed money. Data centers, chips, power.
When borrowing gets expensive, that part shakes first.
That's what CoreWeave is showing us.

But unlike 2000, the revenue is real.
Millions of people pay for these tools every month. I'm one of them.

What happens to your AI tools

So here's the part that matters for you.
If money gets tight, your AI tools won't disappear. But they will change.

Right now, these companies are fighting for you.
Cheap plans, generous limits, new features every week.
A lot of that is subsidized.

If investors start asking for profit, that's the first thing to go.

・Tighter limits
・Higher prices
・Some features quietly disappear
・Some smaller tools shut down completely

That's exactly what happened in 2001. The free stuff went away first.

4 warning signs I watch

So how would you know it's starting? Here are the signals I watch.

Limits quietly get tighter. Same price, but you hit the cap sooner. That usually comes before a price increase.
The cheap plan loses features, and they reappear in a more expensive plan.
Free trials get shorter, or disappear.
Smaller AI startups start getting acquired, or announce they're shutting down, with thirty days to export your data.

None of these are happening in a big way yet.
But that's the order I'd expect them in.

5 things I am doing

I run my whole business on about forty AI sessions a day. So I've had to think about this.

1. My rules and my memory live in plain files on my own Mac.
Not inside one app. If a company changes its terms, I don't lose years of setup.

2. Every big decision also goes to three other AIs.
Not just Claude. So I already know how the others work.
If I have to switch, it's an afternoon, not a month.

3. I already split the work.
Cheap, repetitive checks go to the cheapest model that's good enough.
The hard thinking stays on the best one.

4. I use this cheap era hard.
Right now you can build things for almost nothing.
I'm building things that keep working even if the price doubles.

5. The lesson from 2008: make money from real customers.
If people pay you because you solve their problem, a crash is weather, not the end.

Start today in 1 hour

If you want to start today, here's a simple version. It takes about an hour.

Write down your prompts, rules and instructions in a plain text file. The things you keep retyping. Save it on your own computer.
Export anything important from the tools you use. Chats, documents, projects. Most tools have an export button. Find it now, while it's easy.
Take one real task you do every week, and try it in a second AI. Just once. So you know it works before you need it.

That's it. You're not switching. You're just making sure you can.

The tools stayed

I've watched two bubbles pop.
Both times, the people who got hurt were the ones who depended on one company, or on borrowed money.

The tools stayed. They'll stay this time too.
Bubbles pop on companies. They don't have to pop on you.

Sources: Anthropic's IPO filing as reported by AP (October 26, 2026), CoreWeave market data (October 14, 2026), and historical records for the Nasdaq, Amazon, Pets.com, Google and Lehman Brothers. This is not financial advice.

Claude 2.0 Full Guide: 12 Changes in the New Claude Desktop App, and the Ones Burning Your Usage Limit

Hisashi Space — Sun, 01 Nov 2026 05:27:25 +0000

Using Claude? Claude 2.0, the rebuilt Claude desktop app, changed 12 things. Some of them quietly burn your usage limit.

I run about forty Claude sessions every day, so I went through the new app on my own Mac.
This is what actually matters.

I also made a video of the whole walkthrough.

1. Cowork is gone: just Chat and Code

There are only two tabs now, Chat and Code. Every new feature ships in Code.

Don't let the word "code" scare you. You still type in plain English.
Switch to that tab, because everything below lives there.

Here is why it matters. When I open Claude now, I don't pick a mode first. I pick a folder.
Claude works inside it, with my files, my rules and my tools.

2. The session rail, and what eats your limit

The session rail is the panel on the right.
The top card shows where this chat runs: your computer or the cloud.

Below that is the context card. It shows what is eating your limit before you even type.
Memory files, skills, connectors. They all load into every new chat.

On mine, tools, memory and skills together took more room than all my actual messages.
That is the first thing to clean up.

Every one of those loads on your very first message.
So a giant memory file costs you on every single chat, before you have said a word.

Once a week, open this card and ask Claude to trim whatever it doesn't need.

Trim my memory files to what you actually use

It takes two minutes, and your limit lasts longer.

3. Remote control

Flip this switch, and the same chat keeps going on your phone.
Start at your desk, check it on the train.

There is also a setting that connects every new session to remote control automatically, so you never have to remember the switch.

And turn on "Keep computer awake while Claude works." Otherwise your Mac sleeps, and the job stops halfway.

4. Sections

Right-click any chat and move it to a new section. You get folders in the sidebar, one per project or client.

I have a section for each product and each channel.
No more scrolling through fifty chats to find one.

5. Nested sessions

A chat can now start its own chats.
I asked one to write an App Store description, a launch post and keywords, all at once.

It started three sessions. When each one finished, it reported back.
And unlike sub-agents, I can click into any of them and keep talking.

That is the difference.
A sub-agent is a one-way order: you send a job and get a result.
A nested session is a real chat you can steer.

So if the launch post comes back too long, you don't start over.
Open that one session and say "shorter." Done.

6. The master session

One chat can now see your other sessions. Pin one to the top and make it your master.

Then ask it what is waiting on you.
It read my five latest sessions and told me nothing needed a decision. That is a perfect morning check.

By default it looks at your twenty most recent sessions.
You can ask it to look further back, or to sort your chats into sections for you.

7. Three settings that quietly burn your limit

Open Settings, then Claude Code.

Dynamic workflows runs agents in parallel. The app itself warns that workflows can use a lot of your usage limit quickly.

Prompt suggestions and Classify session states both say they add to your usage too.

Turn off what you don't use. Leave "Keep computer awake" on.

8. Side chats with /btw

Type /btw while Claude is working.
A side chat opens, reads the main chat, and answers without stopping it.

/btw used to vanish. Now side chats stay, and you can open as many as you want.

Why not just ask in the main chat?
Because you interrupt the work, and every question there costs more, since the whole long chat gets read again.

9. Split view

Hold Option and click a chat. It opens next to the one you are in.
I fit eight on one screen.

Start with two. Eight is a lot for your own brain.

My setup is simple. The master session on the left, the jobs it started on the right, and a side chat when I need one.

10. Docs, Slides and designs

Claude now makes these as shared pages you can edit together and send as a link.
Docs is a shared document you write together with Claude. Slides builds a deck you can present right there.

Docs and Slides got all the headlines. But they are the least of what changed.

If your brand has a design system, there is now a place for it right in Settings, so everything Claude makes looks like you.

11. New slash commands

/doctor checks your setup and offers fixes.
/rewind takes you back to an earlier point, like undo.

Pressing Escape twice rewinds without typing anything.

12. Mods

Describe a change, and Claude rewrites the app itself.
I asked for my weekly limit above the chat box.

It wrote it, asked once, and turned it on.

Now I see how much is left before I start anything big.

You don't need to code this. I typed one sentence.
The mod is just a few files Claude writes, and you can turn it off anytime.

A simple daily routine

Here is how it all fits together.

In the morning, ask the master session what is waiting on you. You get a short list.
Start the big jobs as nested sessions, one per task.
Put the master on the left in split view so you can watch them.
When you are curious about a job, don't interrupt it. Open a side chat.
Let the green meter tell you when to slow down.

That is how one person can keep forty sessions moving without losing track.

Three mistakes to avoid

Letting your memory file grow huge. Every chat pays for it.
Opening eight panes on day one. You won't follow any of them. Two panes first.
Asking questions in the main chat while it is working. It slows everything down. That is what side chats are for.

Do these three today

Check your context card
Set up a master session
Build a mod for your limit

Everyone talked about Docs. The real upgrade is that one chat can now run all the others.

How to Remove Background Music and Keep Only the Voice. With Prompts for Claude Code, Codex, Grok and Antigravity

Hisashi Space — Tue, 20 Oct 2026 13:01:18 +0000

I wanted to reuse the narration from some old TikTok videos I made.

The problem: the videos had background music, and I no longer had the original voice recordings.

So I removed the music and kept only the voice.

I used Demucs, a free sound separation model released by Meta.
It ran entirely on my Mac and took about 16 seconds for two videos.

This post shows how I did it, how I asked Claude Code, and how to ask Codex, Grok and Antigravity to do the same.

What Demucs does

Demucs splits audio into four parts:

Vocals
Drums
Bass
Other instruments

It was built to pull singing voices out of songs, but it works the same way for speech over background music.

It is free and runs on your own computer. You do not need to upload your audio anywhere.

What you can use it for

Reuse the voice from an old video in a new one
Check what someone is saying when the music is too loud
Prepare clean voice samples, for example for text to speech

How I asked Claude Code

All I did was ask Claude Code in plain language (I asked in Japanese; translated here).

First, I pasted the video URLs and asked for the audio:

Extract the audio from these TikTok videos for me

Then, when I worried about the music:

Ah, the background music will probably hurt the quality

Finally, to get the files:

Put them in Downloads too

That was enough for it to:

Save the videos
Install Demucs
Separate the voice from the music
Write the voice only audio to my Downloads folder

I did not have to look up Demucs or learn how to install it.

Asking Codex, Grok or Antigravity

Any AI agent that can run commands on your computer can do this. Here is how to start each one:

Codex (OpenAI): codex
Grok Build (xAI): grok
Antigravity (Google): agy

I have only tried this with Claude Code.
So that other agents do not get lost, here is a prompt that spells out every step. Paste it after you start the agent.

Extract only the spoken voice from this video.
Video file: (paste the file path)

Steps
1. Create a working folder and a Python virtual environment inside it
2. Install demucs in that environment
3. Extract the audio from the video with ffmpeg
4. Use demucs with --two-stems=vocals to split voice from everything else
5. Save the voice only file (vocals.wav) to my Downloads folder

Rules
- Do not delete any files outside the working folder
- When you finish, tell me what was created and where

Doing it yourself

You can also run it without an AI agent. In the macOS Terminal:

python3 -m venv demucs-env
source demucs-env/bin/activate
pip install demucs
demucs --two-stems=vocals your-audio.wav

--two-stems=vocals splits the audio into "vocals" and "everything else".
The voice only file is saved as vocals.wav inside a folder called separated.

Things to keep in mind

Only use it on videos you made, or videos you have permission to use
Where the music and the voice are equally loud, a little music may remain

Summary

You can pull just the voice out of a video with background music
I used Demucs, a free model from Meta
It ran on my Mac in about 16 seconds for two videos
With Claude Code, asking in plain language was enough
For Codex, Grok and Antigravity, paste a prompt that lists every step

I only registered a domain. Why did ChatGPT's bots show up within an hour?

Hisashi Space — Mon, 19 Oct 2026 07:03:01 +0000

In my last post, I wrote that when I launched sites on brand new domains, ChatGPT's bots showed up before Google's.
https://hisashi.space/blog/crawler-google-vs-chatgpt/

About an hour after I registered the domain, before there was a single article or a single link, OpenAI's bots were already there.
So how did OpenAI find out that a site had just been born?

My guess was the SSL certificate.
When you get a certificate, its hostname is written to a public log.
I suspected OpenAI watches that log and comes to look.

To test that, I went through the logs of test environments that are not linked from anywhere and have never been submitted to any search engine.
Unlike a production site, a test environment is a place nobody should know about except the people who built it.

What I looked at

One server runs 48 hosts for us. Ten of them are test hosts.
They are test environments for our own products and for client projects we build, and none of them are linked from anywhere.
I am keeping the product names and domains private and calling them Test env A to J.

The data is the server's access log (nginx).
The oldest records go back to the end of April 2026.
All times are Japan time.

You cannot identify a bot by the name it gives (its User-Agent).
These logs alone had 3,305 requests from fakes borrowing the names of OpenAI or Google bots.
So I matched every request against the IP ranges each company publishes, and counted only the ones that matched as real.

・OpenAI: OAI-SearchBot, GPTBot, ChatGPT-User
・Google: Googlebot
・Microsoft: bingbot

Which bots came to the test environments

Real OpenAI bots visited 8 of the 10 test environments.
2,403 requests in total.

Real Googlebot did not visit any of the 10. Not once.
Real bingbot: zero as well.

・Test env A: OpenAI 633, Google 0 (logs from May 10)
・Test env B: OpenAI 519, Google 0 (logs from May 10)
・Test env C: OpenAI 413, Google 0 (created July 6)
・Test env D: OpenAI 396, Google 0 (logs from May 10)
・Test env E: OpenAI 238, Google 0 (created August 20)
・Test env F: OpenAI 175, Google 0 (logs from May 10)
・Test env G: OpenAI 28, Google 0 (created April 30)
・Test env H: OpenAI 1, Google 0 (created October 14)
・Test env I: OpenAI 0, Google 0 (logs from October 5)
・Test env J: OpenAI 0, Google 0 (created April 30)

Googlebot visits our production sites every day.
The test environments under the same domains, on the same server, have not seen it once in more than five months.

What happened on the day they were created

For Test env C, E and H, the logs go all the way back to the day they were created.
In all three, the bots arrived in the same order.

Here is Test env E.

・17:54:00: the first request in the log. Within a few seconds, one scanner bot after another hits the top page
・18:32:44 (38 minutes later): OpenAI's OAI-SearchBot reads robots.txt
・18:32:45: OpenAI's GPTBot reads the top page, then follows its links and starts reading the pages inside

Test env H was the same: OAI-SearchBot arrived 38 minutes after the first request.
For Test env C, it was 2 hours and 12 minutes.

On Test env C and H, one of the bots in those first few seconds called itself CT-WP-Scanner.
CT stands for Certificate Transparency, the public log of SSL certificates.
When a certificate is issued, its hostname goes into this log, and anyone can read it.
The hostnames of all three test environments were in that log.

At that point, the only places anyone could learn those hostnames were the certificate log and the DNS records.
No links, no sitemap, no search engine submission.

Google and OpenAI behave differently

Google explains how Search works starting from discovering pages through links and sitemaps.
https://developers.google.com/search/docs/fundamentals/how-search-works

The test environments have no links pointing to them and no sitemap submitted anywhere.
And in the logs, Googlebot never came.

OpenAI's bots came to places we had told nobody about, within an hour of creating them.
On Test env C and E, GPTBot started reading the pages one second after OAI-SearchBot read robots.txt.

My take

From here on, this is my interpretation of the logs.

OpenAI treats a new domain or a new host getting an SSL certificate as a signal, and comes to look.
Googlebot behaves differently.

In other words, I think OpenAI collects information more widely than Google does, and analyzes it on its own.

OpenAI has not said how it finds new sites.
What the logs show is this: once a hostname appeared in the certificate log and got its first request, OpenAI's bots arrived within 38 minutes to about 2 hours. And Google has not come to similar places in more than five months.

Limits of this data

・I cannot fully rule out that one of these hostnames was written somewhere I do not know about
・For the test environments whose logs start on May 10, I cannot see what came before that
・Some places, like Test env J, did not get OpenAI either
・There is one more test environment whose only surviving logs are from April 2025. Googlebot came 54 times and bingbot 20 times. Since the period is different from the others, I left it out of the ten

How to check your own site

You can count them in your server's access log like this.

grep "OAI-SearchBot" access.log | wc -l
grep "GPTBot" access.log | wc -l
grep "Googlebot" access.log | wc -l

Any program can use any name.
To know whether a bot is real, match it against the IP ranges each company publishes.

・OpenAI: https://openai.com/searchbot.json , https://openai.com/gptbot.json
・Google: https://developers.google.com/static/search/apis/ipranges/googlebot.json

This is how you can see whether OpenAI's bots are visiting your test or staging environments.

Wrapping up

Out of 10 test environments that are not linked from anywhere, OpenAI's bots visited 8.
Googlebot visited none.

On the days they were created, OpenAI's bots arrived between 38 minutes and about 2 hours after the first request.

Even an environment you think is private gets found by OpenAI the moment you get a certificate for it.

Thanks to AI? Links to my site started arriving from an unexpected route

Hisashi Space — Thu, 15 Oct 2026 23:58:45 +0000

I opened the Links report in Search Console for a site I run.
It showed 799 external links in total.

Most of them pointed to the home page, and they were old ones from Hatena and Yahoo! Japan.
But when I looked only at the links pointing to blog posts, a different pattern showed up.
My posts were listed in the "References" section at the end of articles written by people I had never heard of.

I traced every linking page to see what kind of articles were linking to me, and how.

How I traced them

In Search Console's Links report, I went in this order:

・Listed every page under "Top linked pages" that has external links (98 pages)
・For the blog posts among them (68 posts), listed the linking sites one by one
・For links coming from note (a large Japanese blogging platform), went one level deeper and listed the URL of each linking article

Search Console shows only 25 rows per page.
I paged through all of them using the pager at the bottom of the table.

For the note articles, I pulled the publish date and body text through note's public API, and read the text around each link to my site.

Where the links to blog posts come from

68 blog posts had external links, 125 links in total.
They came from 36 sites.

・note: 19 posts
・Hatena Blog: 5 posts
・Yahoo! Japan: 3 posts
・33 other sites: 1 to 6 posts each

Each number is how many of my blog posts that site linked to.

Links to the home page were mostly from Hatena and Yahoo! Japan.
Links to blog posts were mostly from note and personal blogs.

The note links came from 31 articles

Tracing the note links further, they came from 31 articles.
By publish date:

・2020 and 2022: 2 articles
・2026: 29 articles

The 2 older ones mentioned my site as part of the writer's own experience.
The 29 from 2026 looked completely different.

20 of the 29 had a "sources" section

20 of the 29 articles from 2026 had a section after the main text titled "References", "Sources", "Information sources" or "Cited from", and my posts were in it.

Here is the kind of format I found (titles hidden):

References
[1] (My site). "2026 edition | (post title)"
[2] Cabinet Office. (2023). Annual Report on the Ageing Society 2023 (full version).
[3] (My site). (March 26, 2026). (post title)

[Information sources]
・(post title) (https://(URL of my post))
・(post title) (https://...)

Numbering each entry and listing site name, date and title in that order is how academic papers cite references.
Some of them also had markers like "[1, 2]" in the main text.

You rarely see a personal note article list its sources this carefully.
On the other hand, when you ask an AI to research something, it often returns text with exactly this kind of source list.
Whether these articles were written with AI can't be confirmed from the outside.
But the format looks very similar.

Sometimes the same writer cited my site in several articles.
One writer linked to me from 8 different articles.

By month, it is growing

I counted the 29 articles from 2026 by the month they were published.

・March: 2
・April: 1
・May: 1
・June: 2
・July: 9
・August: 5
・September: 9

It jumped in July.

A company site was inserting references automatically

Outside note, a company's owned media site in the IT space had 11 links to 6 of my posts.
On this site, I could see a bit more of how it worked.

At the end of each article there was a row of "References" cards, and my posts were among them.
In the page data, these cards were tagged "source":"injected".
It looks like the system that builds the articles picks related external articles automatically and inserts them afterwards.

The site had 65,176 reference cards in total.
My site wasn't singled out.
Other sites covering similar topics were listed the same way.

What these links actually are

A note on counting:

・Links inside note articles carry rel="nofollow"
・All 11 reference-card links on the company site were also nofollow
・Search Console still counts nofollow links as external links

For the company site, I also checked Google Analytics.
Over a little more than six months, zero visitors came from it.
Having a link and getting visitors through it are two different things.

Is there any effect on search?

Did these links change how the posts perform in search?
For the 19 blog posts cited from note articles, I compared Search Console numbers for the 21 days before and after each post was first cited.

To filter out site-wide swings, I compared each post against the growth in impressions for the whole blog.

・Posts whose impressions grew faster than the blog overall: 2 (both had fewer than 60 impressions in 21 days)
・Posts that grew slower: 17
・Average position: some went up, some went down, with no clear direction

No post visibly rose in search after being cited.
For now, I see no effect on search.
That fits with the links being nofollow.

One more thing stood out when I lined up the numbers.
All 19 posts already had an average position between 4 and 8 in the 21 days before they were cited.
In other words, posts that were already on the first page of search results got cited later.
They didn't rise because they were cited.
They were cited because they were already ranking.

Summary

・Links to my blog posts came mainly from note and personal blogs
・29 of the 31 linking note articles were from 2026, and 20 of those linked to me from a sources section at the end
・The sources sections were numbered and listed site name, date and title, like an academic paper
・Articles like this have been increasing since July 2026
・A company site was inserting references automatically with its article-building system
・The cited posts did not gain in search, so there is no visible search effect so far
・The posts that got cited were already on the first page of search results

So far, there has been no visible result.
Still, the fact that AI seems to pick up my site as a source when it researches something makes me see possibilities ahead.

Is your site listed in the sources section of someone else's article?
Try tracing it once in the Links report in Search Console.

Cloudflare split "Block AI Bots" into Search, Training and Agent. I checked all 26 of my sites through the API

Hisashi Space — Tue, 13 Oct 2026 13:55:02 +0000

On September 16, 2026, I got an email from Cloudflare titled "Updates to managing AI crawlers on your account."
It said the setting for blocking AI crawlers was changing from a single switch into three categories: Search, Training and Agent.

I manage 26 domains on Cloudflare.
Instead of opening the dashboard 26 times, I pulled the settings for every domain at once through the API.
This post covers what changed, how I checked, and how I think a site that wants to be cited in AI answers should be set up.

What changed

The email listed three changes.

The recommended setting for training crawlers changed from "Block" to "Disallow AI Training"
Sites that had turned on "Block AI Bots" or "Managed Robots.txt" are moved to the new three-category setting automatically
Sites that never touched the setting stay on "Allow," and nothing changes for them

According to Cloudflare, "Disallow AI Training" lets search crawlers such as Applebot, Googlebot and Bingbot keep crawling for search results, while telling them not to use the content for training.

Sites that are moved automatically end up with these values.

Search: Allow
Training: Disallow AI Training
Agent: Block only on pages with ads

According to the email, the "Block AI Bots" switch disappears from the dashboard once the migration is done.

Reading the settings through the API

Each zone's settings can be read with GET /zones/{zone_id}/bot_management.
I listed all zones, read the settings one by one, and printed only the AI-related fields.

#!/bin/bash
# CF_API_TOKEN needs the "Bot Management Read" permission
AUTH="Authorization: Bearer $CF_API_TOKEN"

curl -s -H "$AUTH" "https://api.cloudflare.com/client/v4/zones?per_page=100" \
  | jq -r '.result[] | "\(.id) \(.name)"' \
  | while read -r id name; do
      curl -s -H "$AUTH" "https://api.cloudflare.com/client/v4/zones/$id/bot_management" \
        | jq -c --arg name "$name" '{name: $name} + (.result | {
            ai_bots_protection, ai_search, ai_training, ai_user,
            is_robots_txt_managed, cf_robots_variant, crawler_protection
          })'
    done

My first try used the API token I use for DNS.
It came back with Authentication error (code 10000).
The API reference says reading this setting needs either "Bot Management Read" or "Bot Management Write."
If you reuse a DNS token, you will hit the same wall.

What the fields mean

Summarizing the API reference:

Field	Values	Meaning
ai_bots_protection	block / disabled / only_on_ad_pages	Rule that blocks AI crawlers (the old "Block AI Bots")
ai_search	disabled / block / only_on_ad_pages	robots.txt policy for AI search bots
ai_training	disabled / disallow / block / only_on_ad_pages	robots.txt policy for training bots
ai_user	disabled / block / only_on_ad_pages	robots.txt policy for AI assistant and agent bots
is_robots_txt_managed	true / false	Whether Cloudflare writes robots.txt for you
crawler_protection	enabled / disabled	Rule that traps AI crawlers in a maze of links

In the reference, the three new categories (ai_search, ai_training, ai_user) are described as "robots.txt policies."
Only ai_training has a disallow value.

The point to keep in mind is that robots.txt is only a request.
Cloudflare's own documentation says whether to follow robots.txt is up to each crawler, and that it is not a technical block.
If you really want to stop a crawler, you use a rule such as AI Crawl Control.

Results for 26 sites

All 26 sites came back the same.

ai_bots_protection: disabled
ai_search, ai_training, ai_user: all disabled
is_robots_txt_managed: false
crawler_protection: disabled

In other words, none of my sites were blocking AI crawlers.
That matches "sites that never touched the setting stay the same" in the email.
They are not part of the automatic migration, so this change has no effect on them.

One field did differ between sites.
cf_robots_variant was policy_only on 10 of the 26 sites and off on the other 16.
The reference only calls it "the type of Robots Access Control License," and I do not remember ever setting it.

I fetched robots.txt from one of the policy_only sites, and Cloudflare had not added any lines.
Since is_robots_txt_managed is false, my reading is that Cloudflare is not touching robots.txt.
I have not yet confirmed what this value actually means.

I allow AI crawlers explicitly in my own robots.txt

I do not leave robots.txt to Cloudflare. I write it myself.
AI crawlers are allowed by name (excerpt):

User-Agent: *
Allow: /

# AI crawlers: fully allowed
User-Agent: GPTBot
User-Agent: ChatGPT-User
User-Agent: OAI-SearchBot
User-Agent: ClaudeBot
User-Agent: Claude-SearchBot
User-Agent: Claude-User
User-Agent: Google-Extended
User-Agent: PerplexityBot
User-Agent: Applebot-Extended
Allow: /

The reason is simple: the smaller the site, the more it gains from being named in an AI answer.
To be a candidate when someone asks "what do you recommend?", the site first has to be readable.

Settings for a site that wants to be cited in AI answers

Putting this together, here is how I think a site that wants to be cited in AI answers (ChatGPT search, Perplexity and so on) should approach it.

Do not block Search or Agent

Blocking AI search bots means losing the chance to appear in AI search results at all.
Agents that read a page because a user asked them to (ChatGPT-User and similar) cannot use your content in their answer if you block them.

Decide Training as a policy

Being used for training and being cited in a search answer are two different things.
If you do not want your content used for training, you can set only Training to Disallow AI Training and keep Search and Agent allowed.
This change is exactly what makes that split selectable in the dashboard.

If your site was migrated, check the Agent setting

Sites that had Block AI Bots turned on are moved to "Agent: Block only on pages with ads."
If you want AI agents to read pages that show ads, check the setting once after the migration.

Check that nothing else is blocking them

Even if every Cloudflare setting is disabled, a WAF custom rule or a rate limit may still be turning AI crawlers away.
Allowing them in robots.txt does nothing if they are stopped before they get there.

Summary

Cloudflare's AI crawler setting is now split into Search, Training and Agent
Only sites that were blocking before are migrated automatically. Sites that never touched it see no change
The settings can be read through the bot_management API, so you can check every zone at once. The token needs Bot Management Read
The three new categories are robots.txt policies and are not enforced
If you want to be cited in AI answers, leave Search and Agent open and decide Training as a policy

I run DeepSeek R1 70B from my Tokyo office. Here's the network setup.

Hisashi Space — Sun, 11 Oct 2026 13:00:00 +0000

I'm Hisashi. I've run my own company for 22 years, and from 2011 to 2023 I ran it while moving between countries. I still travel, and I want my tools to work the same wherever I am.

This post is about how I turned a Mac in my Tokyo office into a 70B-class AI inference server I can hit from anywhere.

I keep an M1 MacBook Pro stationed at my Tokyo office, running DeepSeek R1 70B and Qwen2.5 14B via Ollama. From my laptop, a café in Tokyo or a hotel room abroad, I get the same latency, the same response, the same experience.

Getting it to that point taught me something. Installing Ollama isn't enough. The moment you step outside the office, your "personal AI server" is dead unless you've fixed the network underneath it.

I've optimized home networks for remote work for 15+ years, and even I was surprised by how rigorous the requirements got once "70B model accessible globally" became the bar. Four things have to be right:

Fast WiFi: A WiFi 7 router (GL.iNet GL-BE9300, aka "Flint 3"), with 6GHz / 5GHz / 2.4GHz bands explicitly assigned to different device generations.
Dual-NAT elimination: My ISP (au Hikari 10G, a Japanese 10-gigabit fiber service) forces a home gateway in the path. I use DMZ-host mode to make it effectively transparent.
A stable VPN: Tailscale, which I measured at 1.6 to 2.5× faster than Cloudflare Tunnel for this use case.
Baseline security: SSH key-only auth, config tracked in git, firmware current.

Here is the overview.

1. Why the network is the foundation, not the model

Getting an LLM running on Apple Silicon is trivial. brew install ollama && ollama run deepseek-r1:70b and you have a 70B model on your Mac in 10 minutes.

The moment you try to use that model as "an AI server I can hit from anywhere," reality hits:

You can't reach it from outside. 80% of my actual use cases happen when I'm not sitting at the office Mac.
Connections drop. Even with Cloudflare Tunnel or similar overlays, long sessions don't stay stable.
Latency is mediocre. Big responses stall and hitch.
Office bandwidth suffers. AI inference traffic crowds out everything else on the same network.
You become a target. Naively open SSH to the internet, and bot brute-force attempts start within hours.

None of these are problems with Ollama. They're problems with the network underneath Ollama.

If you actually want to operate an AI server seriously, you start with the network, not the model.

2. Layer 1: Fast WiFi (WiFi 7 router)

More devices on the network means WiFi becomes a real bottleneck. My count: phone, tablet, main work Mac, AI-server Mac, printer, scanner, smart-home stuff. Easily 10 to 20 devices.

The AI-server Mac in particular downloads multi-tens-of-gigabyte model files occasionally, and during those windows every other device's WiFi degrades. It's absurd to build a "global-access AI server" while making your office WiFi unusable.

Why the Flint 3 (GL-BE9300)

WiFi 7 (802.11be) tri-band
Independent 2.4 / 5 / 6 GHz radios, each band as its own SSID
OpenWrt under the hood, so every setting is configurable via SSH + uci
GL.iNet's web UI ships with Tailscale, AdGuard Home, WireGuard, and more as first-class features
~$300. Pricey for a consumer router, but a fraction of an enterprise alternative.

My three-band assignment

6GHz: latest devices (iPhone 15/16, latest iPad, latest Macs). WPA3-only.
5GHz: main work devices, AI-server Mac, Apple TV. WPA2/WPA3 mixed.
2.4GHz: legacy IoT (scanner, printer, smart-home). WPA2.

2.4 GHz has the longest range but the lowest throughput. By dedicating it to "legacy stuff that doesn't need speed," you push your main devices to 5/6 GHz where they get full bandwidth. Cleaner separation, less interference.

3. Layer 2: Defeating dual-NAT with a DMZ host

Most Japanese fiber contracts, au Hikari 10G included, require keeping the ISP-provided HGW (home gateway router) in the path. You can't replace it; the ISP bakes authentication credentials into the device itself.

That leaves you with two layers: the HGW (192.168.0.0/24) and the Flint 3 (192.168.1.0/24). Classic dual-NAT.

Why dual-NAT is a problem

You have to open ports twice (once per device)
UPnP doesn't traverse the boundary (game console NAT-type pain)
Standing up your own WireGuard / OpenVPN server inside is awkward
mDNS / Bonjour gets segmented (AirPlay degrades)

The fix: DMZ host on the HGW

In the HGW admin UI, enable "DMZ host" mode and point it at the Flint 3's WAN-side IP. Done. External packets now pass through the HGW and land on the Flint 3. The HGW becomes effectively transparent, equivalent to bridge mode in practice.

You're safe because the Flint 3's OpenWrt firewall drops or rejects everything on the WAN zone by default. Even with all packets arriving, unsolicited packets get blocked. The HGW is transparent at the routing level, but firewalling happens on the Flint, where you have full control.

4. Layer 3: Tailscale for fast, stable, global access

Three main ways to reach your office AI server from anywhere:

Port-forwarding + DDNS: direct exposure. Fast, but a huge attack surface.
Cloudflare Tunnel: HTTPS reverse proxy via Cloudflare's edge. Medium speed, drops long sessions.
Tailscale: WireGuard-based P2P overlay. Fast, very stable.

I originally ran my server behind a Cloudflare Tunnel with a subdomain like llm.example.com. It worked, but long sessions kept dropping, HTTP/2 and QUIC stalled, latency jittered.

Switched to Tailscale. Measurements:

LAN-internal test

HTTP /api/tags round-trip: Tailscale 25 ms, Cloudflare Tunnel 64 ms
Tailscale is 2.5× faster

Tethered (simulating off-site access)

HTTP /api/tags round-trip: Tailscale 124 ms, Cloudflare Tunnel 196 ms
Tailscale is 1.6× faster
Tailscale connection mode: P2P direct (no relay)

Tailscale wins both on LAN and off-site, and because it establishes P2P direct connections it doesn't even route through Tailscale's relay servers. Structurally lower overhead.

5. Layer 4: Baseline security

If your AI server is reachable from anywhere in the world, it's also visible to attackers from anywhere in the world. With Tailscale, you're protected by the tailnet auth boundary. With Cloudflare Tunnel, you're basically internet-facing.

Three defenses are non-negotiable:

5-1. SSH key-only auth (password auth disabled)

Modern macOS defaults PasswordAuthentication to no. On OpenWrt (the Flint 3 side), I set dropbear's PasswordAuth to off as well. Password brute force becomes physically impossible.

5-2. Git-managed configuration

I track the Flint 3's /etc/config/* files in a private GitHub repo, after sanitizing secrets (WiFi PSK, rpcd password) with <REDACTED> markers. Config diffs are visible in PR form; rollback is one git checkout away.

5-3. Firmware updates

Both router and server firmware/OS stay current. The Flint 3 (GL.iNet) supports "Keep Settings" on firmware upgrades, so major configuration is preserved.

6. Before vs after

The network rebuild changed daily experience like this:

Global connection stability: before "breaks every 1 to 2 hours," after "doesn't break" (Tailscale UDP session is persistent)
Ollama API latency: before ~200ms avg, after ~124ms avg (~40% reduction)
Large file transfers: before "stalls," after "smooth"
Dual-NAT pain: before UPnP/mDNS broken, after effectively gone
Security: before "weak password, SSH wide open," after "key-only, minimal exposure"

"Getting it running" takes 10 minutes. "Operating it well" takes a few days. But once you've done it, you can hit a 70B model from anywhere in the world with the same latency you'd get sitting in front of the office Mac.

Closing thoughts

Running an AI server from a home office isn't exotic anymore.
But "Ollama installed" doesn't equal "operational."
Get all four layers right, WiFi, dual-NAT, VPN, security, and you have a globally-accessible inference server that actually works.

Running 70B-class models locally isn't special anymore. What separates the people who actually use their local model from those who just have one installed is having it "always there, from anywhere, reliably."

The M1 MacBook Pro in my Tokyo office, with this setup, has become an always-on AI inference layer for me. Same experience from a café in Tokyo or a hotel abroad.

Google vs ChatGPT: which one brings people to a brand-new site first? A month of crawler logs from nine sites

Hisashi Space — Sun, 11 Oct 2026 05:35:36 +0000

When you launch a site on a brand-new domain, Google takes its time.
It's normal to wait weeks before you show up in search results at all, and months before you rank anywhere useful.

So what about ChatGPT?

In the summer of 2026 we launched nine product sites, each on a fresh domain.
When I lined up the logs, I found that while I was still waiting on Google, ChatGPT had already sent people who went on to sign up.
And when Google traffic to some of those sites dropped to almost nothing, ChatGPT kept sending people anyway.

This post lays out those logs in time order, and ends with what I'd do on a new site if I wanted ChatGPT to send people to it.

What I looked at

Each of the nine sites is a product page plus a blog (how-to and comparison articles).
The products are all over the place: a B2B cloud service, Mac apps, tools for group messaging and bookings.
Some sites have both Japanese and English pages, some are Japanese only.
I'm leaving the product names out and calling them Site A to Site I.

Three sources:

Raw server access logs (for four of the sites, going back to the day the domain was registered)
Cloudflare analytics (for the other five; nothing before September 11 is available)
Google Analytics (all nine; how many people came and where from)

All times are Japan time.
Bots were identified by their user agent and then checked against the IP ranges each company publishes, so only the real ones are counted.

The bots in this story

Googlebot: collects pages for Google Search
OAI-SearchBot: collects pages for ChatGPT's search feature
ChatGPT-User: fetches a page on the spot when someone asks ChatGPT something
GPTBot: collects pages for training OpenAI's models

OpenAI describes each of these here:
OpenAI's crawlers

The one that matters most here is ChatGPT-User.
It doesn't crawl the web on its own schedule. It comes when a person asks ChatGPT a question.
So a ChatGPT-User hit in your logs means that, at that moment, somebody was asking ChatGPT about something.

Who showed up first

Here's Site A, from the day the domain was registered, in time order.

Walking through it:

The domain was registered in the early hours of August 29, and the SSL certificate was issued at 03:09.
Certificate issuance goes into Certificate Transparency, a public log anyone can read.

An hour later, at 04:08, four bots hit the home page within two seconds of each other.
One of them is literally named CertSignalBot, a bot that watches those certificate logs.
In other words, there are systems out there that pick up new domains and new certificates and start crawling them automatically.
If you've ever looked at your backlinks in Ahrefs and found a pile of links from random overseas sites, many of those are the same kind of thing: sites that scrape new domains and list them.

OAI-SearchBot, ChatGPT's search crawler, showed up 20 minutes later, at 04:27.
Googlebot first came two days later on August 31, and Bingbot five days later on September 3.
At that point there were no articles, no press release and no backlinks.

On Site B, where I also have server logs from the start, OAI-SearchBot came about two hours after the domain was registered.
On Site D, Googlebot came first.
Which one comes first depends on the site, but both arrived within a few days of the domain going live.

Does ChatGPT find sites through Google or Bing?

You've probably heard that ChatGPT search runs on Bing.

On Sites A and B, OAI-SearchBot arrived before both Googlebot and Bingbot.
At least at the discovery stage, ChatGPT isn't waiting for Google or Bing to index a site. It sends its own bot.

What it saw to learn about the site, I can't tell you; OpenAI doesn't say.
All the logs show is that OAI-SearchBot came 20 minutes after a certificate-watching bot did.

Where ChatGPT looks for pages when it's answering a question is a separate matter, and these logs can't settle it.
On both Site A and Site B, ChatGPT-User's first visit came after Bingbot's first visit.

At first it just checks the door

One thing to watch out for.
From August 29 to September 3, OAI-SearchBot came by one to six times a day, but all it fetched was robots.txt.
robots.txt is the file that tells bots which parts of a site they're allowed into.
So it was checking whether it could come in, and leaving without reading anything.

Articles started going up on September 2, and at 00:44 on September 4 it read an article for the first time.
It came 56 times that day.

Site I shows the difference even more clearly.
Site I's domain had existed since May, and OAI-SearchBot had been coming since May.
But ChatGPT-User didn't show up until September 8, six days after the first articles went up.
As long as there was nothing to read, ChatGPT never used the site in an answer.

ChatGPT doesn't write a site off after one visit. It keeps coming to the door every day and starts reading once there's something there.

With ChatGPT, people arrive right after it reads

The first person to come to Site A from ChatGPT arrived at 12:18 on September 4.
That's six days after the domain was registered and two days after the first articles went up.

The log shows ChatGPT-User fetching the home page, and four seconds later, a visitor arriving from chatgpt.com.

The sign-ups looked the same.

September 14:

14:22:06 ChatGPT-User fetches the home page
14:23:37 (91 seconds later) a visitor arrives from chatgpt.com
14:23:43 they open the sign-up page
14:24:15 (2 min 09 s after the fetch) sign-up complete

September 25:

05:05:22 ChatGPT-User fetches the home page
05:06:37 (75 seconds later) a visitor arrives from chatgpt.com
05:06:42 they open the sign-up page
05:07:32 (2 min 10 s after the fetch) sign-up complete

I can't prove from the logs that the fetch and the visit came from the same person's question.
What I can say is that this sequence really happened: ChatGPT read the page, about a minute later someone came from ChatGPT, and they signed up on the spot.

As of October 9, Site A had zero sign-ups from people who came through Google Search.
It had three from people who came through ChatGPT, including these two.

With Google, there are stages between reading and visiting

Google isn't slow because its bot is slow.
Googlebot came to Site A two days after the domain was registered, and from then on read pages dozens to hundreds of times a day.

Google describes Search in three stages: crawling (collecting pages), indexing (understanding and storing them), and serving (showing them in results).
How Google Search works

People only arrive once you're in the results and someone clicks.
For a new site, getting from "crawled" to "near the top of the results" takes time.

With ChatGPT, reading the page and recommending it happen inside one question.
Someone asks, ChatGPT reads the page right then, and puts a link in the answer.
That's why people show up seconds to minutes after the fetch.

When three sites vanished from Google, ChatGPT kept sending people

I compared visits to all nine sites over two eight-day windows: September 25 to October 2, and October 3 to October 10.

On October 3, Sites A, B and C pretty much stopped getting visitors from Google Search.
That lines up with Google's September 2026 spam update. I wrote that part up separately:
What happened to my one-month-old site during Google's September 2026 spam update

On those same three sites, visits from ChatGPT and other AI kept coming: 15 to 7, 14 to 13, and 11 to 7.
Whatever Google decided about those sites, ChatGPT was reading them and recommending them on its own terms.

Across all nine sites, visits from AI went from 85 to 135.
Most of that increase was Site D, though.
In raw numbers, Google Search still sends far more people, four to eight times as many as AI across the nine sites.
I'm not saying ChatGPT replaces Google.
What I am saying is that during the launch period, when Google isn't sending anyone yet, ChatGPT can.

Where ChatGPT visitors landed

I counted the first page that people coming from ChatGPT opened on the nine sites (September 1 to October 10, 257 visits):

Blog articles: 189 (74%)
Home page: 48 (19%)
Pricing and other pages: 20 (8%)

Three out of four landed on an article.
On Site D, a single how-to article for a group messaging app (how to message just one person in a group) brought 24 visits on its own.
ChatGPT is picking articles as the answer to someone's question and sending them there.

How to get ChatGPT to send people to a new site

Based on these logs, here's what I'd do on a new site. Call it ChatGPT SEO (some people call it LLM SEO), though it's mostly about not getting in the way and having something worth reading.

1. Don't block ChatGPT's bots from day one

OAI-SearchBot checked robots.txt on the same day the domain went live.
If you turn it away at that point, it has no reason to come back and read once you've built something.

Open https://yourdomain/robots.txt and check that there's no Disallow: / for OAI-SearchBot, for ChatGPT-User, or under User-agent: *.
According to OpenAI, sites that block OAI-SearchBot won't show up in ChatGPT's search answers.
GPTBot (training) and OAI-SearchBot (search) are configured separately, so you can opt out of training and still let search in.

Besides robots.txt, check that your CDN or server-side bot protection isn't blocking AI bots.

2. Launch once there's something to read

On Site A, OAI-SearchBot started reading articles two days after they went up, and a person came the same day.
On Site I, the domain existed from May, but as long as there were no articles, ChatGPT never used it in an answer.

If you put a domain up with nothing but a "coming soon" page, ChatGPT just checks the door and leaves.
Launch with your product pages plus a few dozen articles that answer your readers' questions, and you have a shot at being recommended in the first week.

3. Answer the questions people ask ChatGPT, one page per question

Three out of four ChatGPT visitors landed on an article.
And not product pitches: articles like "how to message just one person in a group chat" or "how to stop accepting responses on a Google Form", the kind of thing people ask when they're stuck.

ChatGPT goes looking for a page that answers each question as it's asked.
Turn each problem your product solves into an article phrased as the question, and each one becomes a way in.

4. Check it in your logs

There are two places to see whether ChatGPT is sending people.

The first is Google Analytics.
Visitors who click a link in a ChatGPT answer usually show chatgpt.com as the referrer, and the landing URL often ends in utm_source=chatgpt.com.

The second is your server access log.

grep "OAI-SearchBot" access.log | wc -l
grep "ChatGPT-User" access.log | wc -l

If ChatGPT-User is in your log, someone asked ChatGPT a question and ChatGPT came to read your site.
If there's a hit with utm_source=chatgpt.com right after it, that question sent you a person.

Anyone can fake a user agent, so to know it's really OpenAI, check the IP against the ranges OpenAI publishes.
The links to those lists are on the OpenAI crawler page above.

Wrapping up

A new site takes a while to get noticed by Google and start getting search traffic.
In the meantime, ChatGPT didn't wait for Google or Bing. It sent its own bot, started reading once there was something to read, and brought over the person who'd asked, right then.

If you've just registered a domain, first check that robots.txt isn't blocking ChatGPT's bots.
Then launch with pages that answer your readers' questions.
While you wait on Google, ChatGPT can already be sending people.

What happened to my one-month-old site during Google's September 2026 spam update

Hisashi Space — Sun, 11 Oct 2026 01:37:40 +0000

I run a bit over ten websites. During Google's September 2026 spam update, which started on September 24, one of them basically disappeared from search. Search impressions went from a few hundred a day to almost nothing on October 3.

I'm writing this up with the Search Console screens and the numbers I have, partly to keep a record and partly because I would really like to hear from anyone who's been through something similar or has a guess about what's going on. I am leaving the site's name out.

What happened

It is the marketing site for a B2B SaaS product. Here's the Performance report for the last three months, daily:

Daily impressions on the article pages:

Sept 7 to Sept 10: a big spike right after the first posts went live. Peak was 740 impressions on Sept 9, across 159 articles
Sept 11 to Sept 12: dropped about 80%, then came back within roughly ten days
Sept 23 to Oct 2: back up to around 480 a day, with up to 171 articles getting impressions
From Oct 3: about 10 a day

For the whole site (home, pricing, comparison pages and articles), it went from 364 impressions a day (Sept 20 to Oct 2) to 12 a day (Oct 4 to Oct 7). Every page type dropped on the same day, not just the blog.

Google's status dashboard lists the September 2026 spam update as starting Sept 24 and taking 13 days and 16 hours to roll out, so Oct 3 falls inside that window.

The site

Domain registered: Aug 28, 2026
First articles: Sept 2 (Japanese), Sept 16 (English)
Articles: 471 in Japanese, 249 in English, 720 in total, about 20 a day
How topics were picked: up to Sept 21 I did not check search volume for the target keyword or look at what was already ranking. After that, every article had to pass a volume check (Google Ads Keyword Planner) and a look at the current top results before going out
Other pages: home, features, pricing, comparisons with competitors

Indexing

As of Oct 4, 701 pages were indexed and 442 weren't.

Here's why the 442 are not indexed:

The biggest bucket is "Discovered - currently not indexed" at 147. I ran URL Inspection on them and none had ever been crawled.

What's interesting is that the paginated blog index pages (page 2, 3, 5, 10, 20, 30) were all crawled and indexed. So Google is seeing the links to those articles, it is just not bothering to fetch them.

Things I checked that look fine

Manual actions: none

Security issues: none
robots.txt, canonicals, noindex, redirects: unchanged and doing what they should
No code changes on the site around the drop
Searching for the product name still brings the site up. What dropped is everything else
Organic visits in Google Analytics fell to 0 to 3 a day on the same day, so it's not a reporting glitch

Backlinks

The site had 52 referring domains. 40 of them came from the syndication of a single English press release (mostly US local news sites).

What I've done so far

Oct 9: noindexed 132 articles whose target keyword had zero monthly searches (checked one by one in Keyword Planner)
Oct 9: added category index pages and changed related posts to the neighbors in the same category. Max clicks from the home page to any article went from 7 to 6
Since Oct 9: stopped publishing new articles
No mass rewrites. The plan is to wait and watch until around Oct 23

Comparing with an older site's first months

I also run a site that's been around for many years, and I added a blog to it in March 2026. Its first months looked like this:

First four weeks or so: impressions grew steadily, about 5 to 6 a day per article
Next four weeks or so: more articles were getting impressions, but total impressions flatlined. Per article it dropped to around 4
Then per-article impressions recovered and it started growing. The clear upturn in Google came about two and a half months in

From Sept 23, this site was in that same "more articles showing, fewer impressions each" phase (4.7 per article down to 2.9). The difference is the older site got through it in about six weeks, while this one sank after about ten days. The older site sits on a domain with a long history. This one is a month old.

What I'd love to hear

The paginated blog index pages get crawled, but the articles they link to have never been fetched. How should I read that?
On Sept 11 the site also dropped about 80% and came back in around ten days. This time the drop is deeper (around 97%) and it lines up with the spam update window. Is it likely to come back the same way? If you've had a whole site sink in a spam update and recover, how long did it take?
Besides noindexing the zero-volume articles, is there anything I should be doing now? Anything I should definitely not do?
Could a batch of links from one press release's syndication have played a part?

If there's a number or a screen that would help, let me know and I'll add what I can.

My office AI server hit 88 degrees C, so I made the room cool itself.

Hisashi Space — Sat, 10 Oct 2026 13:00:00 +0000

I'm Hisashi. I've run my own company for 22 years, and from 2011 to 2023 I ran it while moving between countries. I keep a Mac in my Tokyo office running as an always-on AI server.

This summer in Tokyo, my office Mac started running a multi-day job at 100% GPU, and the more interesting problem became heat. This post is about something every always-on home AI server eventually faces: it gets hot, and you're not there to watch it.

That is fine in an air-conditioned room in spring. It is not fine in a Tokyo summer when I'm in another country and the office aircon is off. Two things can go wrong: the chip thermally throttles and my job quietly slows down, or it just runs hotter than I'd like for weeks on end. I had no way to see either, because I was never in the room.

So I built two things: a dashboard that lets me watch the machine's temperature from anywhere, and an automation that turns the room's air conditioner on when the GPU gets too hot. Total cost: zero, plus a SwitchBot hub I already owned.

1. Reading the sensors without sudo

The first obstacle on Apple Silicon is that the obvious tools need root. powermetrics wants sudo, and I didn't want an automation that hangs forever on a password prompt while I'm on the other side of the planet. So I found a sudo-free source for each metric.

CPU usage: top -l 1 -n 0, then 100 minus the idle percentage.
GPU usage: ioreg -r -d 1 -c IOAccelerator. It exposes a "Device Utilization %" field with no privileges required. This is how I confirmed the GPU really was pinned at 97 to 98%.
Temperatures: smctemp, a tiny open-source SMC reader you compile with the clang already on your Mac (no Homebrew needed). -c gives CPU temperature, -g gives GPU.
Fan RPM: the same SMC interface. There's no dedicated flag, but dumping all keys and reading F0Ac and F1Ac (fan 0 and fan 1, actual RPM) works. Mine read about 5,400 and 5,760, against a ceiling near 5,350. In other words, both fans were already flat out.

A 15-line shell script samples all of that once a minute and appends one JSON line to a file. CPU, GPU, both temperatures, both fan speeds, plus the current job's progress. Nothing heavy: the whole sample takes a fraction of a second of CPU and never touches the GPU, so it can't interfere with the work it's measuring.

2. An MRTG-style dashboard I can open from anywhere

Old-school sysadmins will remember MRTG: a web page of rolling time-series graphs you glance at to know your machine is healthy. That's exactly what I wanted, minus the RRDtool setup.

The page is one static HTML file with Chart.js bundled locally (no CDN dependency, so it works even if the office internet hiccups). It fetches the JSON log, draws three graphs (usage, temperature, fan RPM), shows the latest values as cards, and refreshes every 60 seconds. Room temperature and the air-conditioner state sit in the corner.

Serving it is one line: python3 -m http.server. I run both the collector and the server as launchd jobs so they survive reboots and restart themselves if they die.

The part that makes it genuinely useful from a Bangkok hotel is how I reach it. The machine is on my Tailscale network, so from any of my devices I just open:

http://m1 from anywhere in the world, over the Tailscale tailnet.
http://m1.local when I'm on the office LAN.

Both are plain hostnames, no port number, no IP to remember. Tailscale's MagicDNS gives me the global name; mDNS gives me the local one. I bound the server to port 80 so neither needs a :8765 suffix.

What I see when I open it: a row of live cards (CPU and GPU usage, CPU and GPU temperature, both fan RPMs, room temperature, and the current training step), sitting above three rolling graphs (usage, temperature, fan speed). The temperature cards turn amber as they climb, so a glance from my phone tells me whether the machine is comfortable or cooking. Everything updates every 60 seconds.

Watching the graphs for an evening settled a question I'd assumed I'd have to guess at: was the machine throttling?

It wasn't, yet. Job step time stayed flat while the GPU held 86 to 88°C, which means the chip was holding its clocks. Good. But the fans told the real story: they were already maxed. The cooling system had no headroom left. The only lever I had not pulled was the temperature of the air going into the machine.

That reframed the whole problem. I couldn't make the Mac cool itself harder. I could only make the room cooler. And the room has an air conditioner.

3. Giving the room a thermostat

The details are where you avoid an automation that drives you crazy:

Hysteresis. Cooling turns on when the GPU stays at or above 92°C for three straight minutes, and off only when it drops to 84°C or below. The 8-degree gap stops it flapping on and off around a single threshold.
A rate limit. No more than one action every ten minutes, so it can't machine-gun the compressor.
It only undoes its own actions. The controller turns the aircon off only if it was the one that turned it on. If I switched it on myself for comfort, it leaves it alone. Infrared is fire-and-forget with no state feedback, so the controller tracks what it last commanded rather than pretending to know the real state.
A floor. It reads room temperature from a SwitchBot sensor and refuses to start cooling if the room is already below 24°C, so it never overcools an empty office.

It runs as one more launchd job on the same one-minute cadence, reading the same temperature log the dashboard uses. Default-off until I explicitly enabled it, so there was never a chance of it firing by surprise during testing.

Right now, with the room at 26°C and the GPU at 88°C, it correctly sits idle. It's waiting for the day the Tokyo heat pushes the chip past 92, at which point the office will cool itself while I'm somewhere else entirely.

4. One mistake worth copying down

When I first stood the dashboard up, I served the whole working directory. That directory also held the file with my SwitchBot API credentials. For about fifteen minutes, anyone on my private network could have fetched http://m1/.env and read my tokens.

It was tailnet-only, so the blast radius was just my own devices, but the lesson generalizes: a static file server serves everything in the folder you point it at. Put only the public files (the HTML, the graph data) in the served directory, and keep secrets and scripts one level up where the server can't reach them. I moved them, confirmed the credentials now return 404, and rotated nothing because the exposure never left my own machines, but it was a clean reminder.

Closing thoughts

An always-on AI server is a small piece of infrastructure, and infrastructure you can't see is infrastructure you'll eventually lose. Two cheap moves fix that: a one-minute sampler feeding a dashboard you can open by name from anywhere, and a temperature-driven rule that lets the room take care of the machine when you're not there.

The Mac in my Tokyo office now watches its own temperature, tells me about it over my tailnet, and cools its own room when the summer gets serious. I don't have to be in the office to keep it safe.

SshResident at 180% CPU: why my ScanSnap iX2500 took 14 seconds to start, and the fix that wasn't code

Hisashi Space — Fri, 09 Oct 2026 13:00:00 +0000

I'm Hisashi. I've run my own company for 22 years, and from 2011 to 2023 I ran it while moving between countries. Running a paperless company means I scan a lot of documents, and my main scanner had developed an annoying tic: I would press Scan, and nothing would happen. The scan button just blinked, ten to fourteen times, before the rollers finally started pulling paper.

The scanner is a ScanSnap iX2500, rated at 45 pages per minute. The reading speed was never the problem. The problem was the several-second stall before a single sheet moved, and my first instinct was the usual suspect: the connection. So I switched it from WiFi to USB. Exactly the same delay. Then I switched the save destination from the pop-up menu style to a fixed folder profile. Same delay. When two things you assumed were the cause turn out to change nothing, you are looking in the wrong layer.

The delay wasn't in the scanner, and it wasn't on the wire. It was the Mac, doing something absurd, on every single scan.

The symptom

Press Scan, watch the button blink, wait. Worse, when I scanned twice in a row, the second scan was slower than the first. That detail matters. A slow-but-constant delay smells like a fixed handshake. A delay that grows when you repeat the operation smells like contention, something piling up and not clearing.

USB versus WiFi made no difference. Quick-menu versus folder profile made no difference. So the bottleneck was not data transfer and not the scanner firmware. It was something the Mac ran between "button pressed" and "paper moving," and whatever it was, it got heavier the more I used it.

Rule one: name the process

Same reflex as always. Before touching anything, find the process. I streamed the unified log filtered to the ScanSnap helper processes and sampled CPU while I triggered a scan.

One process lit up the instant I pressed the button:

PID    %CPU  COMMAND
3798   186.6 SshResident

SshResident is the resident background app that ScanSnap Home keeps running to watch the scanner. It should sit near idle. During the blink, it was pinned above 100%, peaking near 186%, meaning it had more than one full core to itself for the entire stall. When the CPU dropped back to idle, the paper started moving. The blink and the CPU spike were the same event.

The cause: enumerating every app, hundreds of times

CPU percentage tells you a process is busy. It doesn't tell you what it's doing. For that, macOS ships sample, which snapshots a running process's call stacks. I sampled SshResident three times during the stall. All three came back with nearly all of the CPU time in the same call chain:

-[SSUIController doScanClick:]
  isAppLaunchedByBundleID
    getLaunchAppProcessIDBySignature
      GetProcessInformation          (HIServices, the old Carbon Process Manager)
        _LSCopyApplicationInformation  (LaunchServices)

Here is what that stack means. When you press Scan, SshResident needs to launch a helper app to handle the scan, and before it proceeds it polls to check whether that helper has finished launching. The way it checks is GetProcessInformation, an ancient Process Manager call that does not ask about one specific app. It walks the entire list of running applications that LaunchServices is tracking and builds an information record for each one, just to find the single process it cares about. Then it does that again on the next poll. And again, hundreds of times, until the helper is up.

The cost of one sweep is proportional to how many apps LaunchServices is tracking. On a normal Mac that is maybe thirty, and nobody ever notices this code. My Mac is a working machine for eleven businesses: browsers with dozens of tabs, editors, local dev servers, MCP servers, recording tools. At the moment I measured, LaunchServices was tracking about 380 applications, and the whole machine was running roughly 1,800 processes. So every poll walked 380 apps, and the launch wait fired hundreds of polls, and that product is a full core pinned for ten to fourteen seconds. The second scan was slower because it landed while the first scan's helper teardown was still churning the same list.

The delay was never the scanner's limit. It was an O(number of apps) loop in the vendor's software, running head-on into a machine that runs an unusual number of apps.

The clever fix that backfired

Once you know it's GetProcessInformation being called in a hot poll loop, the engineer's temptation is obvious: cache it. Intercept that one function, remember each process's answer for a second or so, and let the hundreds of repeated polls hit the cache instead of rebuilding a 380-app list every time.

You can inject code into another process on macOS with DYLD_INSERT_LIBRARIES, and normally a hardened, notarized, signed system binary would refuse it outright. This one couldn't refuse. Its own code signature carried two entitlements, allow-dyld-environment-variables and disable-library-validation, precisely the two that let an unsigned or ad-hoc dylib load into it. The vendor had left the door open, presumably for its own plug-in machinery. I wrote a small interposing library that cached GetProcessInformation per process with a short expiry, ad-hoc signed it, added the injection to the helper's Info.plist, and re-signed the bundle while preserving its entitlements.

The first version crashed the daemon on launch. The root cause is a nice trap. I had hand-declared the old ProcessInfoRec struct from memory. The real 64-bit layout is not what you'd guess: it is packed to two-byte alignment, it is 72 bytes, its first pointer sits at offset 4 rather than 8, and the processAppSpec field that exists in every online reference was dropped entirely in the 64-bit version because it was built on the 32-bit-only FSSpec type. My natural-alignment struct put every field at the wrong offset, and my copy of a 264-byte buffer into what the caller had sized as a 70-byte one smashed its stack. I rebuilt the interposer against the SDK's real types, verified it in a standalone harness that mimicked the daemon's exact call pattern, confirmed it was safe and cut real calls by 80%, and redeployed.

And scanning stopped working entirely.

This is the part worth sitting with. The library was now provably correct in isolation and provably fast. But by caching the answer to "has the helper launched yet," I had blinded the daemon to the one state change it was actually polling for. It waited forever for a launch it could no longer observe. My harness reproduced the call pattern perfectly and the state transition not at all, which is exactly the class of bug a harness cannot catch. Every failed attempt left the scanner dead until I restored the original from backup, and power-cycling a scanner mid-workflow to recover from your own patch is a strong signal you are solving the wrong problem. I reverted the whole thing.

The fix that wasn't code

Step back far enough and the real question changes. I had been trying to make the slow path fast. The better move was to delete the slow path.

The delay lives entirely in the Mac-side software that orchestrates the scan. So don't let the Mac orchestrate the scan. The iX2500 has a touchscreen and, as of a 2025 firmware feature, it can save directly to a network folder over SMB with no PC involved at scan time. The scanner writes the file itself. SshResident is never in the loop, because ScanSnap Home is never in the loop.

The setup is boring, which is the point:

Turn on File Sharing on the Mac and export the destination folder as an SMB share.
Give the Mac a fixed IP so the scanner's saved destination never breaks. I put the wired connection (a CalDigit TS4 dock) on a static 192.168.1.10, low in the range to stay clear of the DHCP pool.
On the scanner's touchscreen, register a network-folder profile pointing at \\192.168.1.10\ScanData with the Mac account's credentials.
Point the scanner's clock at an NTP server, because SMB authentication and file timestamps both care about time. The home router (a GL.iNet Flint 3 at 192.168.1.1) already answers NTP on the LAN, so that one line needs no internet at all.

Then you pick the profile on the touchscreen and scan.

Results

Time from pressing scan to paper moving: a couple of seconds, consistently
SshResident in the scan path: gone, along with the 380-app enumeration
Files land straight in a local folder on the Mac, named by timestamp, ready for whatever processing I run next
Mac-side scanning software touched during a scan: none

Takeaways

When the fix you assumed doesn't change the symptom, stop testing that layer. USB versus WiFi changing nothing is what told me the scanner and the wire were both innocent.
sample is the tool that turns "this process is busy" into "this process is calling this exact function in a loop." CPU percentage is a smoke alarm; the call stack is the fire.
A delay that gets worse when you repeat the operation is contention, not a fixed cost. Chase the thing that accumulates.
Injecting into a signed system binary is sometimes possible, and rarely wise. When a vendor daemon carries allow-dyld-environment-variables and disable-library-validation, the OS will let you in, but you are now maintaining a patch against software that fights back on every update, and a harness that reproduces the calls will still miss the state machine.
The strongest fix is often the one that removes your code from the path instead of adding more. The scanner could already do the whole job by itself. I just had to stop insisting the Mac be in the middle.

The meta-lesson is the same one that I keep coming back to. Depend on a machine and you owe it root-cause fixes, not rituals. Sometimes the root cause is that you were using the wrong tool for the job, and the cure is to use less software, not more.