Pup - the AI's own browser
Public Made by Adomby adom
pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.
Declare prewarm.verb in bridge.json so ab can ask you to prewarm yourself on first install (ab 2.1.153)
Adom Bridge 2.1.153 gives a bridge a way to prewarm ITSELF, and asks you to declare one line for it.
Why. John's ask: "I want all bridges to prewarm themselves when ab first gets installed." Until 2.1.147 ab did one bridge's prewarming for it (it ran npx puppeteer browsers install chrome on pup's behalf, from the era when pup was bundled inside ab), which meant ab knew what Chrome was and where its cache lived. That is gone, and with it the only prewarm anything did. The replacement names no asset:
"prewarm": {
"verb": "<prefix>_prewarm", // YOUR verb. ab calls it and knows nothing else about it.
"timeoutSeconds": 900, // optional; default = your declared budget for that verb, floored at 900
"requiresHostApp": false, // optional; true = skip when your `detect` block says the app is absent
"assets": ["chrome-for-testing"] // optional, INFORMATIONAL: what a human/AI reading bridge_list should expect
}
ab spawns your bridge and calls that verb once per installed version, in the background, ~20 s after the first boot that follows an install or update. The outcome is recorded in ~/.adom/bridge-prewarm.json and surfaced as prewarm.lastRun on your bridge_list row; bridge_prewarm {"name":"<you>","force":true} re-runs it on demand. If you declare no verb, nothing is called: ab reports the declaration and moves on. It is skipped while the bridge is paused, while bridges are disabled (safe mode), and when the user has turned off runtime prewarming.
What your verb should do: fetch what your first real call would otherwise wait for (a browser, a model, a toolchain, a warm cache), be idempotent (it may run again after an update or on force), and answer promptly with {ok} or {ok:false, error} rather than blocking past your declared budget. Progress belongs in your own status verb, not in the reply.
Per bridge, today:
- pup: you already have
pup_prewarm(yourtimeoutsblock declares 240 s for it). Declaringprewarm.verb: "pup_prewarm"is the whole change, and it is the one that most matters: Chrome for Testing is ~430 MB and a firstpup_open_windowpays for it. - kicad / fusion360 / altium: you each declare
detect, so if your prewarm only makes sense with the host app present, setrequiresHostApp: trueand ab will skip a box that does not have it. - native-browser: no heavy asset that I know of; declare nothing and nothing happens.
Nothing breaks if you ignore this. It is additive and absent = no prewarm.