Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/adityasasidhar/browsercontrol/browsercontrolnpx skills add adityasasidhar/browsercontrol --skill browsercontrolgit clone --depth 1 https://github.com/adityasasidhar/browsercontrolWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00088 | $0.02167 |
| Opus 5 | $0.00044 | $0.01084 |
| Sonnet 5 | $0.00018 | $0.00433 |
| Haiku 4.5 | $0.00009 | $0.00217 |
Grade A, and why
browsercontrol scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 204 lines — stays where its author put it; the contents beside it link to each section on GitHub.
BrowserControl
A browser you can see. Every action returns a fresh screenshot with numbered
red boxes over the interactive elements, plus a text list of those elements. You
act by number — click(7) — never by CSS selector or XPath.
Tool names below are unprefixed. Your client may expose them as
mcp__browsercontrol__click or similar — use whatever prefix your tool list shows.
The loop
navigate_to("https://example.com") → screenshot + element list
read the numbers off the screenshot
click(7) → NEW screenshot + NEW element list
read the numbers again
type_text(3, "hello") → NEW screenshot + NEW element list
Every tool that touches the page re-marks it. There is no persistent naming of elements — the numbers are recomputed from scratch each time.
Three rules that prevent almost every failure
1. Element IDs are ephemeral. Never reuse a number across actions.
The map is rebuilt after every click, type, scroll, navigation, and screenshot.
Element 7 before a click is almost never element 7 after it.
- Wrong: "I'll click 4, then click 9" — planned from one screenshot.
- Right: click 4 → read the new screenshot → find the target again → click it.
If you get Error: Element N not found, the response already contains a fresh
screenshot and element list. Re-read it and pick the ID from that, don't retry
the same number.
2. Only elements visible in the viewport get marked.
Off-screen elements are filtered out before numbering. Default viewport is 1280×720. If the thing you want has no number, it is probably below the fold:
scroll("down", "medium") # 400px; also: small=100, large=800, page, top, bottom, or "750"
scroll_to_element(id) works only for an element that is already marked. To
reach something you have not seen yet, scroll and re-screenshot.
3. Read the text summary, not just the picture.
Each response ends with Found N interactive elements: and a list like
[7] button - Sign in. That list is the ground truth for what is clickable,
and it disambiguates icon-only buttons the image cannot. Note it truncates at
30 entries with ... and N more — IDs past 30 are valid even though unlisted.
Use screenshot() to re-render if you need the rest in view.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 204 lines · 88 tokens per session scan A bba227c99ee8
browsercontrol is a skill published in the GitHub repository adityasasidhar/browsercontrol (10 stars, last pushed 28d ago), licensed MIT. It adds 88 tokens to every session and 2,167 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
browser-use
Direct browser control via CDP for web interaction: automation, scraping, testing, screenshots, and site/app work.
opencli-autofix
Automatically fix broken OpenCLI adapters when commands fail. Load this skill when an opencli command fails — it guides you through collecting a trace artifact, patching the adapter, retrying, and filing an upstream GitHub issue after a verified fix. Works with any AI agent.
open-source
Documentation reference for writing Python code using the browser-use open-source library. Use this skill whenever the user needs help with Agent, Browser, or Tools configuration, is writing code that imports from browseruse, asks about @sandbox deployment, supported LLM models, Actor API, custom tools, lifecycle…
opencli-sitemap-author
Use when creating or maintaining OpenCLI site sitemaps: agent-facing navigation, page-state, action, workflow, API-reference, pitfall, and fallback knowledge for a website. Use after browser exploration discovers durable site context, when a sitemap is stale, or when promoting local site knowledge into the repo.
opencli-browser-sitemap
Use when driving a website with opencli browser and sitemap context is available, requested, or needed to avoid blind navigation. Guides agents to consume site sitemap files lazily, choose adapter/browser fallback paths, resume from state signatures, and mark stale sitemap entries without trusting them over live…
pinchtab
Use this skill when a task needs browser automation through PinchTab: open a website, inspect interactive elements, click through flows, fill out forms, scrape page text, reuse a dedicated automation profile with user approval, export screenshots or PDFs, manage multiple browser instances, or fall back to the HTTP API…