TL;DR
- Crawling now adapts to each site: Concurrency, request delays, retries, and timeouts adjust automatically to avoid overwhelming slow or rate-limited servers.
- Visibility runs are more reliable: Runs cover every enabled prompt and engine, distribute topics evenly, and use checkpoints and task leases to prevent duplicate work or charges.
- Usage is easier to manage: Visibility settings estimate monthly managed-unit usage, remaining allowance, scheduled runs available, and when paused runs will resume.
- Alerts and indexing are less noisy: Engine alerts require widespread failures, inbox badges update immediately, and background indexing limits CPU usage while showing progress.
- Hosted AI support has been refreshed: Paid plans and user-supplied keys support the latest managed models, while Send Moose automatically selects and identifies an available hosted model.
The crawler reads the room
Every site has a pace it is comfortable with. Some sit behind a content delivery network that challenges anything fetching too many pages too quickly. Our improved crawler notices which kind of site it is on and behaves accordingly.
The Moose crawler starts at two parallel requests and adds one after every dozen clean, fast pages, up to eight. After each step up it checks whether page times grew in proportion. If they did, the server is at its comfortable limit, so the crawler steps back and remembers that ceiling for a while. A rate-limit or challenge response halves the workers, doubles the gap between requests, waits a few seconds, and puts the page back in the queue for another try. A slow page does the same and stretches the per-page timeout to fit what the site is showing us.
The outcome is the most important part. In a replay of a rate-limited site, the crawler finished every page with two short pauses. In a replay of a one-page-a-second site, it settled at three workers and finished every page without a single timeout. Your site inventory comes back complete, and the server on the other end barely notices we were there.
Every prompt, every engine, one run
On managed plans, scheduled visibility (optionally) runs happen in the cloud. This week the cloud runner picked up the same run-building logic the desktop runner uses: every enabled prompt on every enabled engine goes into the run, and prompts are interleaved across topics, so each topic gets its first answers early instead of waiting behind the one you edited last.
For a project with 300 prompts across seven engines, that is a single run of just over 2,100 prompt-and-engine pairs. The runner already had what a run that size needs: a per-run allowance check up front, a defined worker budget, and checkpoints so a run picks up where it left off if it needs a second worker. Now those pieces get used.
Long runs, one worker
An AI visibility run with several hundred prompts can take a while, so the worker executing it now claims a lease when it starts and holds it to the end. The task queue's deadline matches the worker budget, and any redelivery that finds a live lease backs off.
The inbox got the same treatment. "Engine unavailable" items are now computed from the finished run's observations. An item appears only when an engine gave no answers at all, and it says how many prompts were affected. Google choosing not to show an AI Overview for a query is Google's call, not an outage, and it no longer creates an "engine unavailable" inbox item.
Your fan
The app builds a search index over your pages on your machine so chat and the entity graph can find things. That indexer now briefly uses at most a third of your CPU cores, capped at four, so a background job stays in the background.
Models
Hi, Moose gained Gemini 3.8 Flash, Claude Fable 5.1, and Muse Spark 1.3, all on paid managed plans or with your own key, and retired Gemini 3.5 Flash and the two Gemini 3.1 previews.
Small stuff
The visibility settings page now says how many managed cloud allowance units your cadence needs per month and how many remain (local AI models have no allowance of course). If the cloud allowance balance will not cover the whole month, the banner says roughly how many scheduled runs are left and when they resume, so there are no surprises. The inbox badge updates the moment a cloud run creates an item. And Send Moose picks a hosted model on its own when local AI is off on a paid plan, and says which one on screen.
Moose the dog, who I am named after, supervised all of it from under the desk. Eyes closed, but present.
FAQ
What does the crawler do when my site rate-limits it?
It backs off by halving the number of parallel requests, doubles the gap between them, waits a few seconds, and re-queues the page for another try. The wait grows if the site keeps refusing, and the footer shows that the crawler is pacing itself while it does.
Do scheduled cloud visibility runs cover all of my prompts?
Yes. Every enabled prompt on every enabled engine goes into one run, interleaved across topics, and a run that needs more than one worker continues from its checkpoint. Desktop runs with your own OpenRouter key work the same way.
When does an "engine unavailable" item show up in the inbox?
Only when an engine gave no answers at all for a run, or half or more of its prompts came back empty. The item says how many prompts were affected. Google not showing an AI Overview for a query does not count.
The one who's under the desk for all of it.
