The constraint that shaped every decision in this is that the output is the expensive part. An agent runs a command and then has to read the answer, and a tool that is generous with its output is a tool that costs you twice for the same fact. So the CLI answers with one thing and stops. `eval <url> "document.title"` prints `"Example Domain"` and nothing else. `shot` prints the path it wrote, one line, with no confirmation around it. `console` prints `(no console output)` when there is nothing wrong, rather than a clean bill of health you have to read to the end of to find out it was clean. The install side is the same argument in megabytes. `npx playwright install` pulls a browser per engine and a dependency tree behind it. This pulls one pinned `chrome-headless-shell` into a cache directory, once, and has nothing else in it. That is the whole idea and it is the only genuinely new thing here: a tool designed so that reading its output is cheap is a different tool, not a smaller one.

Fan-out is the headline, and the first numbers I took for it were flattering because I measured them wrong. One browser launching, loading a page and closing again looked like it cost about the same as twelve doing it at once, which would have been a remarkable thing for it to do. What I had actually measured was a cold first launch against a warm dozen: the first one pays for DNS and the page cache and everything after it does not. Warmed up and run twice, the honest figures on this laptop are about a fifth of a second for one, and between three quarters of a second and a second for twelve at once. Twelve browsers cost roughly three and a half times one browser. What they do not cost is twelve times one, and the same twelve run one after another take about two and a half seconds, so the fan-out is about three times faster than the loop. That is the claim worth making and it is a smaller one than I first wrote down. There are two shapes and the skill makes the agent choose. Many pages inside one browser is the cheapest and shares cookies and storage, which is what you want for several pages of one site. Separate browsers give every job its own process and its own temporary profile, so sessions cannot see each other and one crash does not take the batch with it. What breaks first is not the machine, it is the cleanup. If a worker throws, the runner stops scheduling new work and cannot cancel what is already running, and any browser whose close never fires leaves a Chrome process and a directory in /tmp behind it. Every example in the repository closes in a finally, and that is why.

The plugin ships a skill, and the useful part of it is not the command list. It is a decision procedure. Check the environment before anything and do not install a browser unless you were asked to, because that is a hundred megabyte download. One fact about one page goes to the CLI. Anything with a second step gets a small script instead, and the reason is written out rather than assumed: each CLI call is its own launch and its own fresh profile, so logging in with one command and screenshotting with the next screenshots you logged out. There is a paragraph on reading a blank page which says to check the document request before the console, because a failed or 4xx document is a server problem and a document that loaded fine with an error under it is a client one. There is a caveat about phone screenshots coming back 980 pixels wide on a page with no viewport meta tag, labelled a caveat rather than a bug so nobody goes and fixes it. The detail sits in three reference files so the part that is always loaded stays short, which is the same argument about output applied to the documentation.