DEV Community: Hisashi Space

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.

coreaudiod at 112% CPU: the sample-rate mismatch that froze Zoom on my Mac

Hisashi Space — Thu, 08 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. My work means a lot of Zoom calls, and it also means my main Mac is permanently mid-recording, mid-stream, or mid-long-running-job. Rebooting is never an option I accept without a fight.

So when Zoom started freezing on launch (spinning, audio dead, the whole machine feeling sticky), I did what I always do: found the actual culprit instead of power-cycling my way past it. The culprit turned out to be embarrassingly small. One audio device was set to 44.1kHz while everything else on the system ran at 48kHz. That single mismatch had macOS's audio daemon burning a full CPU core, continuously, for weeks.

If your Mac's audio feels haunted (Zoom slow to join, recording apps erroring out, UI hitching when sound plays), there's a decent chance you have the same disease. Here's the full diagnosis and the fix. Total time: about 15 minutes. Reboots required: zero.

The symptom

Clicking a Zoom link did nothing for a long time. The meeting window eventually appeared, but audio took even longer, and sometimes the app just sat there. Meanwhile the machine felt subtly wrong: keystrokes lagging, fans occasionally spinning up with nothing visible running.

top told the real story:

PID    %CPU  COMMAND
620    112.3 coreaudiod

coreaudiod is the macOS audio daemon (the process behind Core Audio; every app that plays or records sound talks to it). It should idle near 0%. Mine was pinned above 100%, meaning it had more than one full core to itself.

One more detail made it clear this wasn't a fresh problem. The process had accumulated over 39 hours of CPU time. This thing had been quietly cooking for weeks, and Zoom's launch sequence just made it visible, because Zoom enumerates and opens audio devices aggressively at startup, right into the teeth of a daemon that was already drowning.

Rule one: don't reboot

A reboot would have "fixed" this. It also would have destroyed the diagnosis, killed everything else the machine was doing, and guaranteed the problem came back next week.

macOS lets you restart a single system daemon:

sudo killall coreaudiod

launchd respawns it instantly. Audio drops for two or three seconds, then reconnects. That alone brought CPU back to normal. But that's treatment, not cure. If I stopped there, the daemon would start melting again the next time the trigger condition reappeared. So the real question: what makes coreaudiod spin?

The cause: one device at 44.1kHz

I'd seen this failure mode once before, with a Yamaha AG06MK2 mixer. The mixer was set to 44.1kHz, the Mac wanted 48kHz, and coreaudiod ground itself into paste doing sample-rate conversion on every audio callback. Unifying everything at 48kHz cured it permanently.

The AG06 wasn't even connected this time. But the pattern generalizes, so I dumped the nominal sample rate of every device on the system. You can do this in Audio MIDI Setup (the GUI way), but I wanted it scriptable, so I asked Core Audio directly. The check is a dozen lines of Swift using kAudioDevicePropertyNominalSampleRate:

MacBook Pro Microphone:  48000 Hz
MacBook Pro Speakers:    44100 Hz   <-- there it is
Microsoft Teams Audio:   48000 Hz
SWB Audio Capture:       48000 Hz
LoomAudioDevice:         48000 Hz
ZoomAudioDevice:         48000 Hz

The built-in speakers, of all things, had drifted to 44.1kHz. Everything else, including every virtual device, sat at 48kHz. Zoom negotiates 48kHz for calls.

Here's why that one line is expensive. When rates disagree, coreaudiod has to resample audio in real time between the mismatched clock domains, per stream, forever. Worse, apps that open devices at their preferred rate trigger renegotiation, and with a conferencing app in the mix you get a steady churn of format changes. Each one is cheap; a continuous stream of them, multiplied across every virtual device that mirrors system audio, is a full CPU core.

The fix is one property write (same API, AudioObjectSetPropertyData with 48000.0), or thirty seconds of clicking in Audio MIDI Setup. All devices at 48kHz, mismatch gone.

The aggravator: seven resident virtual audio drivers

While diagnosing, I looked at /Library/Audio/Plug-Ins/HAL/, the folder where apps install virtual audio devices. These are fake sound cards that apps use to capture or route system audio, and every one of them is a permanent client of coreaudiod, whether or not the app that installed it is running.

I had seven:

ARK.driver
LoomAudioDevice.driver
MSTeamsAudioDevice.driver
ParrotAudioPlugin.driver
SWBAudioCapturePlugIn.driver
TVRemoteAudio.driver
ZoomAudioDevice.driver

Seven virtual sound cards, resident 24/7. Each multiplies the cost of every device enumeration (which Zoom does at launch) and every format renegotiation (which the 44.1k mismatch was causing constantly). The mismatch lit the fire; this pile of drivers was the accelerant.

Some of these names tell you nothing, and this folder is a common hiding spot for abandoned software. Don't guess; verify. codesign tells you who actually shipped each one:

codesign -dv --verbose=2 /Library/Audio/Plug-Ins/HAL/TVRemoteAudio.driver

The census results:

ARK.driver: Rogue Amoeba (the audio engine behind Loopback, Audio Hijack, SoundSource). Keeping it; I use their tools.
LoomAudioDevice / ZoomAudioDevice / SWBAudioCapture: screen-recording and conferencing tools I actually use. Kept.
ParrotAudioPlugin.driver: this one looked suspicious (unfamiliar name, sitting in a third-party folder), but the signature chain is Apple's own OS platform signing, not a Developer ID. It's a genuine macOS system component. Leave it alone; it would come back with the next OS update anyway.
TVRemoteAudio.driver: TeamViewer's remote-audio driver. I use TeamViewer occasionally but never its audio streaming. Dead weight. Removed.
MSTeamsAudioDevice.driver: Microsoft Teams. I only ever join Teams calls when someone else hosts one, and the browser version handles mic, camera, and screen share fine without installing anything. So I uninstalled the desktop app entirely. Note that uninstalling Teams leaves this driver behind; you have to delete it from the HAL folder yourself.

Two drivers gone (backed up first, always), then one more sudo killall coreaudiod to make the daemon reload its plugin list. Down to five residents, all accounted for.

Results

coreaudiod: 112% CPU before, 0.4% after, and it stays there
Zoom: clicking a meeting link now puts the window on screen in about 2 seconds
Loom and other recording tools: device enumeration is lighter, so startup errors from enumeration timeouts should drop too
Reboots: zero

Takeaways

When a Mac feels sick, name the process before you touch anything. top -o cpu costs nothing. "Reboot it" is a diagnosis you pay for later.
Audio weirdness on macOS (conferencing apps slow to join, recording apps failing, hitching when sound plays) should trigger one reflex: check that every device in Audio MIDI Setup shows the same sample rate. 48kHz is the sane default; one device at 44.1kHz can eat a core.
System daemons can be restarted individually with sudo killall <daemon>. launchd brings them back in seconds. This solves a large class of "haunted Mac" problems without a reboot.
Audit /Library/Audio/Plug-Ins/HAL/ once in a while. Every app you've ever installed for calls or screen recording may have left a virtual sound card there, and they all tax the audio daemon forever. codesign -dv identifies the vendor when the name doesn't.
The accumulated CPU time column in ps is underrated. 39 hours on a daemon that should idle told me this was chronic, not acute, before I knew anything else.

The meta-lesson is the same one that I keep coming back to. A machine you depend on deserves root-cause fixes, not rituals. The reboot ritual works just often enough to stop people from ever learning what was actually wrong.

Mac keyboard not working? Cmd+Tab dead and input switching broken? Check for a password field hidden in a background app

Hisashi Space — Wed, 07 Oct 2026 05:14:07 +0000

One morning, three things happened on my Mac at the same time:

・Cmd+Tab would not switch apps
・Switching between Japanese and English input behaved strangely
・The mouse and the other keys worked normally

A reboot might have fixed it.
But my Mac is always recording or running something long, so I don't reboot lightly.
When I tracked it down, the cause was a password field in an app hidden in the background.

The cause: macOS Secure Input

macOS has a feature called Secure Input.
While the cursor is in a password field, other apps are not allowed to read keystrokes.
It exists so nothing can snoop on your password, and that's the right call.

The catch is that it applies to the whole Mac.
While Secure Input is on, apps that work by reading keystrokes (Cmd+Tab switchers, input method helpers, key remappers) stop receiving keys.
They still see modifier keys like Cmd and Shift, but not the actual key presses.

And if the cursor stays in a password field, Secure Input stays on, even when that app's window is hidden behind others.

What happened on my Mac

The first time, it was a browser password manager extension.
The password manager's Safari extension turned Secure Input on and failed to turn it off, and Cmd+Tab died.
Quitting Safari didn't fix it. Locking and unlocking the screen didn't either.

The second time, it was a browser window I was driving with automation.
A browser running in the background got stuck on a login page with the cursor in the password field.
The window was off screen, so I couldn't see it.
Cmd+Tab and input switching stayed broken from the middle of the night until morning.

Check whether Secure Input is on

Run this in Terminal:

ioreg -l -w 0 | grep -i SecureInput

If the kCGSSessionSecureInputPID line shows a number other than 0, Secure Input is on.
If nothing comes back, or the number is 0, it's off.

The trap: the app it points to may not be the culprit

kCGSSessionSecureInputPID shows a process ID.
It's tempting to read it as "this app is the culprit". That's the trap.

The number is only the process that last turned Secure Input on.
It isn't necessarily the app holding it now, and it can even be the ID of an app that has already quit.

The second time, the ID pointed to an unrelated app.
Restarting that app did nothing.
The real culprit was the password field in that off screen browser window.

How to find the real culprit

Instead of trusting the number, check these in order:

・Is any open app sitting with its cursor in a password field? Include windows that are behind others or off screen
・Is a password manager running, including browser extensions?
・Is a browser automation tool stuck on a login page?

With macOS Accessibility, you can check which element each app currently has focused, and whether it's a password field, without moving the cursor.
That's how I found the password field in the off screen window.

How to fix it

Once you know the culprit, you don't need to reboot.

・If an app has its cursor in a password field, move the cursor out of it or close that window
・If it's a password manager extension, quit just that extension's process. You don't have to quit the browser

The first time, quitting only the Safari extension's process turned Secure Input off on the spot, and Cmd+Tab came back.

# For the Bitwarden Safari extension (it starts again on its own when needed)
pkill -f "Bitwarden.app/Contents/PlugIns/safari.appex"

If you automate a browser

When you drive a browser with automation, a job can stop on a login page and leave the cursor in a password field.
Even when you can't see the window, it affects keyboard input for the whole Mac.

On my setup, automation now always moves the cursor out of password fields when it finishes.
And when the automation hits a login page, it leaves the field alone and hands it to a person.

Summary

・If Cmd+Tab or input switching suddenly stops working, suspect Secure Input first
・Confirm it with ioreg -l -w 0 | grep -i SecureInput
・The process ID it shows may not be the culprit
・Look for password fields in hidden or off screen windows, password manager extensions, and automated browsers
・Once you find the culprit, you can fix it without a reboot

I control 10+ browsers with AI agents from one terminal. Here is how

Hisashi Space — Sun, 04 Oct 2026 07:47:08 +0000

I run my business alone, and a lot of my day is browser work. Checking payouts in Stripe. Pulling rankings from Search Console. Filling in forms on directories and launch sites. Posting to a dozen places.

These days I hand most of that to Claude Code. The hard part was never the AI. It was the browser: how do you let an AI agent use a website you're already logged in to, without it getting in your way or getting you flagged?

You've probably seen demos like "I had an AI agent order Uber Eats through the browser." To me, that misses the point. I can order food myself, faster. One task done by an agent instead of me saves almost nothing.

What matters is how many jobs can run in parallel while I do something else. That's the only reason I want an agent in the browser at all.

I tried the usual ways first. Each one broke in a way I didn't expect.

1. Claude's Chrome extension

The easy answer is Claude's own extension for Chrome. My logins are already there, so the agent can start right away.

But with the extension, I give instructions browser by browser. That's fine for one task. It's not what I wanted for running several jobs side by side.

I wanted to control everything from the terminal. One place where I ask for the work, and the agents do it in whichever services they need, at the same time.

Two more things bothered me:

・I was handing over the whole browser. Every tab, every account, every service. There's no way to say "only Stripe".
・It once connected to a different browser than the one I thought, then asked me to sign in to a service I was already signed in to. Everything looked fine on my side, so it took a while to figure out why.

2. Browser automation tools with a separate browser

This is how most AI agent browser automation works: start Chrome with special settings and connect to it.

What I ran into:

・It's a fresh browser, so there are no logins. Sign in again, type the two-factor code again, for every service.
・Sites notice. One startup directory returned "Bot access denied" when I submitted through an automation tool. After that, even my own clicks on the Submit button stopped going through.

3. Letting it watch the screen

The agent takes a screenshot, picks a spot, clicks and types. It can drive anything.

But it drives the screen I'm looking at. While it works, my mouse and keyboard belong to it, and there is only one screen, so there's no second task running beside the first.

That's the part that bothered me most. The whole point of handing work to an agent is that I keep working. If the agent takes my focus while it works, I'm just sitting and watching. From an efficiency point of view, that defeats the purpose.

What I actually wanted

After all that, my list was short:

・I sign in myself. The agent never sees a password.
・I give the agent one service, not my whole browser.
・Nothing jumps in front of what I'm doing.
・Several jobs can run at the same time.

What I built

So I built Kagemusha. It turns any website into its own Mac app. A Stripe app, a Search Console app, a GitHub app. Each one is a separate browser with its own sign-in.

I sign in to each app once, the normal way, with my password manager or a passkey. Then, app by app, I decide whether an AI agent is allowed to operate it. A new app starts with that switched off.

When the agent works, it works inside that one app, in the background. My screen stays mine. I can show the window if I want to watch, or keep it hidden.

Getting this part right took a lot of trial and error. Windows kept coming to the front while I was typing. Even bringing one forward for a moment took my keyboard for almost three seconds, and my keystrokes went into the wrong place. I kept going until the agent could open, read and fill in pages without ever stepping in front of what I was doing.

Because each app is its own browser, I can run several at once. When I checked the other day, I had 24 of these apps open at once on my MacBook Pro (M4 Max, 128 GB of memory), using about 23 GB in total, while the same Mac was running around 20 local development servers. That was one observation on one machine, not a stress test.

What changed in practice: I stopped babysitting the browser. I ask for last week's Search Console drops, this month's Stripe refunds and a draft post, and they come back while I keep working on something else.

Where to find it

I built it for my own work first. If you want to look at it, it's here:

https://kagemusha.app/

I'd like to hear how others are handling this. If you let an agent use your browser, which of these walls did you hit?

Regex couldn't sort my sales emails. A yes/no judgment model could

Hisashi Space — Fri, 02 Oct 2026 08:08:58 +0000

After a press release, the contact address of one of my products started filling up with sales pitches: webinar invites, free whitepapers, trade show booths, agencies offering to help. I run more than ten products on my own, so I didn't have time to sort these by hand, and my Gmail filters and regex weren't holding.

This post is about what replaced them: a judgment model that answers yes/no questions about each email, and the rules I put around it. On October 2, 2026, it took the inbox from 92 messages to 2.

Why rules broke

Four kinds of mail were landing in the same inbox:

replies people had written to us (these need an answer)
auto-replies from contact forms (we reach out to companies through their website forms)
pitches, newsletters and event invites
bounces

The same phrases show up across kinds. "Thank you for your inquiry" appears in auto-replies and in thoughtful human replies. Filtering on "webinar" catches real inquiries that mention one.

Some pitches don't even come from the sender. A common trick, mostly from English-speaking companies, is to write the pitch in a Google Doc and share it with you, so the email arrives from Google. Another is signing you up for a Zoom webinar, so the invite comes from Zoom's shared address. You can't send Google or Zoom to spam without losing the shares and invites you actually need.

A wording rule also hurt us once. We treated "we'll pass this time" as a refusal and stopped contacting that company for good. It says "this time." A regex can't tell "this time" from "never" reliably.

The model: Jev

I used Jev from TypeSafe AI. It's what TypeSafe calls a System One model (the name comes from Kahneman's fast, intuitive System 1). It reads natural language like an LLM does, but it doesn't generate text. You send a state and a set of typed questions, and it returns typed answers with probabilities. No JSON to coax out of a chat model, no parsing.

There are three question types:

Type	Asks	Returns
`choice`	pick one option from a list	`choice`, per-option `probabilities`, `confidence`
`score`	place the state on 2 to 10 described levels	`score` (can land between levels), per-level `probabilities`, `confidence`
`noul`	yes or no	`noul`, the probability of yes (0 to 1)

A few properties mattered for this job:

All questions in one request are evaluated against the same state, in parallel and independently. One answer doesn't leak into another.
The docs say most queries come back in about 100 ms, and adding questions barely changes that.
The question id is never sent to the model. Only instructions (and optional criteria) are, so the edge cases go in the instructions.
Pricing at the time of writing (Jev 1.13) is $0.042 per million input tokens, output free. Rate limits are 100K tokens/s and 40 requests/s, and you get a 429 past either.
English is the primary training language. Other languages, Japanese included, work but less accurately. My inbox is mostly Japanese, which turned out to matter for thresholds.

Five questions, one call

Each email becomes one request with five noul questions. Most of the cost is sending the body, so you put all questions in a single call instead of one call per question.

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'EOF'
{
  "model": "jev-latest",
  "state": "From: ...\nSubject: ...\n\nBody...",
  "questions": {
    "human": { "type": "noul", "instructions": "A person wrote this reply individually. Auto-replies, promotions and newsletters don't count." },
    "needReply": { "type": "noul", "instructions": "It would be appropriate, socially or commercially, for us to reply to this email." },
    "counterSales": { "type": "noul", "instructions": "The sender is trying to sell us their own product, service or seminar." },
    "meetingRequest": { "type": "noul", "instructions": "The sender wants to set up a meeting, call or visit." },
    "stopRequest": { "type": "noul", "instructions": "The sender clearly asks us not to contact them again. Declining just this one time doesn't count." }
  }
}
EOF

That last instruction is the direct fix for the "this time" mistake.

Same input, slightly different answers

The probabilities wobble between calls. In an earlier test on a different task, I sent the same three questions about the same 69 items three times. Average spread was 0.013 to 0.041 per question, the worst was 0.15, and only 2 to 11 of the 69 items got identical values all three times.

So anything near a threshold can flip if you ask again. I ask twice and only act when both answers land on the same side of the line. If they disagree, a person looks at it.

const runs = await askRepeated(state, QUESTIONS, 2);
const pick = (key) => {
  const g = agreed(runs.map((r) => gateNoul(r.answers[key], LINES[key])));
  return g.act === 'auto' ? (g.value ? 'yes' : 'no') : 'unsure';
};

gateNoul maps a probability to yes, no or "don't decide", and agreed only returns auto when every run reached the same verdict. Both live in a small wrapper I share across my products.

Draw the lines from your own mail

My wrapper's default for a single noul is 0.9 for yes and 0.1 for no. On 26 real Japanese emails, that left nearly everything undecided. The measured values looked like this:

"should we reply": real replies 0.61 to 0.93, pitches and auto-replies 0.05 to 0.49
"stop contacting us": the highest of the 26 was 0.19

So each question got its own line:

const LINES = {
  human: { yes: 0.5, no: 0.3 },
  needReply: { yes: 0.6, no: 0.599 },
  counterSales: { yes: 0.6, no: 0.599 },
  meetingRequest: { yes: 0.6, no: 0.599 },
  stopRequest: { yes: 0.7, no: 0.3 }, // can't be undone, so the bar is higher
};

Two things I learned the hard way. Changing the set of questions in a request moves the numbers for the others, so the lines belong to that set of questions and need re-measuring when you add one. And jev-latest is an alias that moves when a new version ships, so if you tuned thresholds on a version, pin it (jev-1.13.0) and re-measure before moving. The response's model field tells you which version answered, which is worth logging.

What never goes to the model

If code can decide it, code decides it:

bounces are recognizable from the sender (mailer-daemon, postmaster)
anything about invoices, payments or contracts stays in the inbox regardless of the model
if the call fails or returns nothing, the email goes to a person, never to "fine, archive it"

That last one matters most. "Couldn't judge" and "judged as harmless" aren't the same thing.

Result

On October 2, 2026:

about 70 pitches and invites moved to "no reply needed"
about 15 form auto-replies filed away
3 bounces
2 left in the inbox: a Google Workspace invoice and one reply I needed to answer

It now runs every five minutes, with judged message IDs cached so the same email isn't paid for twice.

Summary

Wording rules break when the same words show up across different kinds of mail, and platform-borne pitches (Google Docs shares, Zoom invites) can't be filtered by sender at all.
Put every question for one email in one call.
Ask twice, act only on agreement, send disagreements to a person.
Measure thresholds on your own data, especially outside English, and raise the bar for anything irreversible.
Pin the model version you measured against.

TypeSafe AI docs:

https://docs.typesafe.ai/introduction

The longer story, including setup steps, is on my blog:

https://hisashi.space/blog/jev-inbox-triage

Traffic from ChatGPT jumped! Is it because its crawlers now run JavaScript?

Hisashi Space — Wed, 30 Sep 2026 18:03:30 +0000

On September 25, 2026, early in the morning Japan time, OpenAI's crawlers changed how they read my sites. I saw it in the server logs. OAI-SearchBot (search) and GPTBot (training) stopped just fetching HTML and started running JavaScript and rendering pages.

The accepted wisdom has been that AI crawlers don't run JavaScript. The Vercel and MERJ study from December 2024 said none of OpenAI's three bots executed it. What I'm seeing is a change from that.

This post has the numbers from the logs first. After that comes a list of what I would do now if I wanted ChatGPT to mention a site. I couldn't find any announcement from OpenAI, so where I'm guessing, I say so.

What happened

The main site is @soho (atsoho.com), a Japanese freelance marketplace built on Next.js with the App Router. A few of my product sites run on the same server. I did not trust the user agent alone. Every request was checked against OpenAI's published IP ranges (gptbot.json, searchbot.json, chatgpt-user.json), and anything outside them was dropped as a fake.

Requests per day on atsoho.com

Date	OAI-SearchBot	GPTBot	ChatGPT-User
Sep 10	1,108	34	13,538
Sep 22	1,253	83	657
Sep 24	7,082	5	911
Sep 25	41,444	28,484	1,645
Sep 28	14,339	152,009	1,071

OAI-SearchBot jumped at 4 a.m. JST on September 25, and GPTBot took off at noon the same day. Until September 24 GPTBot came from one IP a day. From September 25 it came from 36 to 131.

Most of the new traffic was prefetch

When I looked inside, almost all of the extra requests were Next.js link prefetches, the ones with ?_rsc= plus five random characters at the end. That string is not in the HTML. It only shows up when the page is rendered and its JavaScript runs.

・September 22: 80% of OAI-SearchBot requests were plain HTML fetches, 2% were prefetches
・September 28: 84% of OAI-SearchBot requests and 97% of GPTBot requests were prefetches

So 150,000 requests a day does not mean 150,000 pages read. Most of it is what a rendered page fires off on its own.

How many pages actually got rendered

Each prefetch carries the page that triggered it in the Referer. Counting distinct Referers tells you how many pages the bot rendered.

Date	Rendered by OAI-SearchBot	of which job pages	Rendered by GPTBot
Sep 18	56	2	17
Sep 25	861	108	1,994
Sep 28	539	36	4,395

About 10x for search, and well over 100x for training.

They're rendering HTML they already have

Of the 4,309 pages GPTBot rendered on September 28, only 28% had been fetched from my server by anyone that day. My HTML is not cached at the CDN, so the CDN did not serve it either. My read is that OpenAI re-renders HTML it stored earlier in its own headless browser, and the only thing that reaches my server is the prefetches that fire during that render.

OpenAI's own docs say that if a site allows both bots, it may use the results from one crawl for both purposes to avoid duplicate crawling. GPTBot rendering what OAI-SearchBot fetched fits that.

Is this happening everywhere?

On the same server, all four Next.js sites that have articles saw OAI-SearchBot go up 5 to 15x on September 24 and 25. They run different Next.js versions and deploy differently, and I did not change anything on my side that week. The change came from OpenAI.

But on Cloudflare Radar, OpenAI's share of all AI bot traffic stayed flat through September. It looks like rendering is only switched on for some sites.

It reaches static sites too. On one of my sites that doesn't use Next.js, OAI-SearchBot pulled images and CSS on September 25, which is what rendering looks like. A static page does not fire prefetches, though, so the request count barely moves. The spike on the Next.js sites is mostly prefetch amplification.

What else changed at the same time

Around the same time, visits from ChatGPT to @soho's job pages went up, and daily signups rose about 1.7x. The number of people coming from ChatGPT did not change. Where they landed did. It used to be mostly blog posts, and from about September 25 it was mostly job pages. That lines up with job pages rendered by OAI-SearchBot going from 2 a day to 36 to 108. I cannot prove one caused the other.

What to do if you want ChatGPT to mention you

These six come from the logs above and from OpenAI's crawler docs.

1. Let OAI-SearchBot in

OpenAI's docs say sites that opt out of OAI-SearchBot will not be shown in ChatGPT search answers, though they can still appear as navigational links. They recommend allowing OAI-SearchBot in robots.txt and allowing requests from their published IP ranges.

Three things to check:

・robots.txt: make sure OAI-SearchBot isn't disallowed
・WAF and bot protection: Cloudflare bot rules or your own rate limits might be blocking OpenAI's IPs. My own server was returning 403 to some of their requests on September 22 to 24
・IP lists: OpenAI updates them. This time gptbot.json changed on September 22 and chatgpt-user.json on September 25. If you keep an allowlist by hand, pull it from the list URLs instead

If you do not want your content used for training, you can block GPTBot alone and keep search.

2. Put the content in the first HTML

OpenAI has started rendering, but only for some sites, it seems. Everywhere else, only the initial HTML gets read. And even where rendering happens, it starts from stored HTML.

Anything you want quoted, like the body, title, prices and dates, is safest in HTML that's readable without running JavaScript. In Next.js that means server rendering or static generation. On any site, avoid loading the main content from an API after the page opens.

3. Link to the pages you want read

The bots were reading prefetches inside rendered pages. The more internal links point at a page, the more chances it has to be read.

Google works the same way. One of my other product sites has 520 articles, and only 2.5% were indexed. The article list was paginated and Google never went past page 1, while 632 product pages linked to each other 37 times each and to the articles zero times. About 90% of Google's crawls went to those product pages.

・Do not bury articles deep in pagination
・Link related pages to each other, like a product page and the articles about that product
・Do not stop at the sitemap. Pages that only exist in the sitemap get pushed back

4. Don't block Next.js prefetches

Next.js has a check that turns prefetching off for known bots. The list has Google, Bing and others, but not OpenAI's bots (I checked the source in Next.js 14.2 and 16). So when an OpenAI bot renders a page, the prefetches go out as usual, lots of them.

I wouldn't block ?_rsc= in robots.txt or answer it with 429. A prefetch response contains the linked page's content, so for a rendering crawler it's one of the ways it reads your pages. Get the rule slightly wrong and you can block the pages themselves.

If server load becomes a problem, turn prefetch off only for the navigation links that appear on every page (prefetch={false}). That cuts the traffic and keeps the content and normal links intact. On my site most prefetches came from the category links in the global nav.

5. Tell machines how fresh things are

On @soho, ChatGPT sent people to job posts that had already closed. I cannot tell from outside how old ChatGPT thinks the information is. To avoid sending people to stale pages, put the published date, updated date and whether it's still open in both the structured data (JSON-LD) and the page itself. For job posts, one way is to mark only open posts as JobPosting and give closed ones a datePublished.

6. llms.txt can wait

I put llms.txt on @soho on September 20. OpenAI's bots read it once every few days. So far it does not look like it decides whether ChatGPT mentions you. It does not hurt, but I wouldn't put it ahead of 1 to 5.

How to check this on your own site

If you have server logs (nginx or similar), you can check all of this yourself.

・Identify the bots: match on the user agent (OAI-SearchBot, GPTBot, ChatGPT-User) and check the IP against OpenAI's three lists. An IP that is not listed is a fake
・Is it rendering: look for _rsc= in the URL (Next.js). On a static site, see whether the bot is fetching images and CSS
・Pages rendered: count distinct Referers on the _rsc= requests. Don't judge by request counts
・Traffic from ChatGPT: ChatGPT adds utm_source=chatgpt.com to its links. The Referer misses some of it, so count on the request URL
・Compare with everyone else: pull daily shares per AI bot from the Cloudflare Radar API

If a site is served only from Cloudflare, there are no server logs. Cloudflare's GraphQL Analytics API (httpRequestsAdaptiveGroups filtered by user agent) gives you counts by day and path, even on the free plan.

What I still do not know

・How OpenAI picks which sites to render
・When and how it fetches the HTML it renders
・How much rendering actually affects whether ChatGPT mentions a site

I'll add to this post as I find out.

References

・OpenAI, Overview of OpenAI Crawlers

https://developers.openai.com/api/docs/bots

・Vercel, The rise of the AI crawler (December 2024)

https://vercel.com/blog/the-rise-of-the-ai-crawler

・Next.js, Prefetching

https://nextjs.org/docs/app/guides/prefetching

X lead gen ads are back: how to collect names and emails without sending anyone off X

Hisashi Space — Tue, 29 Sep 2026 13:00:00 +0000

Can you collect leads with X ads? Names and email addresses, straight from the ad?

Yes. X launched Lead Gen Ads on August 26, 2026.
Tap the ad, and a form opens inside X. People fill it in without leaving the app, and you get the leads as a CSV or sent to your CRM.

This isn't the first time. Twitter had lead generation cards from 2013, and stopped showing them in March 2017. Nine years later, lead capture is back on X in a new form.

What follows is based on X's own setup guide for advertisers (August 2026).

What people see

The ad shows up in their timeline
They tap the button (such as "Learn More") and a form opens inside X
They enter their name and email and submit
A final page appears. You can put a button there that takes them to your site

You build it in the opposite order: the form first, then the ad.

Step 1: Build the lead form

In Ads Manager, open Leads center from the left menu and click New form.

Content tab

・Name: the form's internal name
・Introduction (optional): a headline and description shown above the form. The description can hold extra consent text
・Purpose: what the form is for. This only shows when Introduction is turned off
・Fields: what you ask people to fill in. Email is on and required by default
・Privacy policy: your company name and a link to your privacy policy. The URL is reviewed before the ad can run

Fields you can add

・Contact: email, phone number, X handle, street address, city, state or province, country, post or zip code
・User: full name, first name, last name, date of birth, gender
・Work: company name, job title, work email, work phone number

The guide notes that the available fields may change.

Final page tab

・Headline
・Description
・Website button (optional): the URL and the button label

Step 2: Create the campaign

On the campaign form, pick Leads as the objective and name the campaign.

You can also attach a lead form to ads with other objectives, such as Reach or Video Views, by choosing the lead form as the ad's destination.
In that case, delivery is optimized for the objective of that campaign, not for leads.

Step 3: Set up the ad group

・Ad group name
・Budget (daily budget; a total cap is optional)
・Start time (end time is optional)
・Demographics (age targeting is 18 and over only)
・Placements: home timeline, search results, profiles, replies

Step 4: Create the ad

・Ad name and post text
・The lead form to attach
・Call to action
・Image or video

The call to action is one of: Book Now, Buy Tickets, Contact Us, Donate, Download, Get Offer, Learn More, Shop Now, Sign Up, Watch Now.

You can also build the ad in Composer. Choose Lead form as the destination, then pick the form and the call to action.
Posts made in Composer can also go into Takeover campaigns (Timeline Takeover and Timeline Reach only).

Step 5: Review and launch

Choose a funding source, check the campaign, and click Launch.

Reporting

Ads Manager shows the usual metrics plus lead metrics: Leads and Cost per lead.

Getting the leads out

Three ways:

・Download from Leads center as CSV or XLSX
・Connect a CRM (HubSpot, Salesforce, Zapier): pick the form and paste the webhook URL from your CRM
・Pull them through the Ads API

Four things to sort out before you launch

Leads are only available for 90 days after they're submitted.
Connect your CRM or Zapier before the ad goes live, or decide who downloads them and how often.

Your privacy policy URL gets reviewed.
If your site doesn't have a privacy policy page, the ad won't run.

Age targeting is 18+ only.
You can't use it to reach anyone younger.

Email is required by default.
In the guide, the personal email field is switched on and required from the start.

Summary

Yes, you can collect names and email addresses with X ads alone.
Build the form, run a campaign with the Leads objective, and take the leads out as CSV or into your CRM.

Have a privacy policy page and a place for the leads to land before you start, and nothing will stop you halfway.