Run browser automation for agents

Your agent’s job needs more than a fetch: it has to interact with a page — dismiss a modal, click “load more”, fill a field, wait for content to render, then capture the result or read the updated DOM. A plain HTTP GET can’t do any of that. Running your own headless browser farm to make it possible is a project of its own. This page shows the agent-native path to browser automation on a single Auxiliar key.

What the agent is trying to do

The agent has a concrete job: drive a real browser through a short sequence of actions and get back the result — the rendered content, extracted fields, or a screenshot. It ranges from a single scripted click-and-capture to a full stateful, multi-step, authenticated flow.

That requires a real browser under the agent’s control:

• Scripted actions — click, type, scroll, and wait, in order, before reading the page.
• Rendering and capture — run the page’s JS, then return clean content or a full-page screenshot.
• Stateful sessions — for multi-step or auth-walled flows, a browser that holds cookies and context across steps.
• Anti-bot handling — many interactive targets are also defended, so the browser has to look real.

Why the agent cannot solve this alone

A browser is infrastructure, not a prompt — you can’t reason your way to a rendered click. On its own, an agent cannot:

• Create or manage provider accounts — it can’t open a Browserbase, Apify, or Firecrawl account and accept terms for a human.
• Pass signup, payment, and bot flows — provider onboarding sits behind email verification, card entry, and its own bot gates that need a real human browser.
• Safely hold many upstream keys — spreading provider secrets across an agent’s context or environment is a credential-sprawl and exfiltration risk.
• Know which browser tool is winning right now — which provider captures valid screenshots or drives sessions best at the lowest cost today is live measured data the model can’t sample.
• Run a headless-browser fleet — provisioning, driving, scaling and unblocking real browsers is a system you operate, not a conclusion you reach by thinking harder.

So the blocker isn’t reasoning. Browser automation needs accounts, credentials, browser infrastructure, and current benchmark data — none of which live inside the model.

How Auxiliar solves it

Auxiliar is a web-access API gateway that collapses all of the above into one credential:

• One AUXILIAR_API_KEY — the only secret the agent ever holds.
• Upstream keys server-side — Firecrawl, Browserbase, Apify and the screenshot providers are authenticated by Auxiliar; the agent never sees a provider key.
• Native provider routes — call https://api.auxiliar.ai/{provider}/{native-path} with the provider’s own request shape; you just change the base URL.
• One balance — credit-metered against a single account, no per-provider subscriptions.
• Eval-backed selection — where a verb is measurable (screenshots), the Auxiliar curator fleet ranks providers on valid-image rate, latency and cost on one shared corpus, published at /evals.json and the /best/ pages.
• One-line escalation — because scripted-action scraping and full browser sessions are on the same key, the agent can start with a one-shot actions call and escalate to a stateful session only when the flow needs it, with no new signup.

First call

For scripted actions plus a capture in a single call, use Firecrawl’s native actions — click, wait, then screenshot — with your one key. Auxiliar injects the Firecrawl key server-side.

curl -X POST "https://api.auxiliar.ai/firecrawl/v1/scrape" \
  -H "Authorization: Bearer $AUXILIAR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/listing",
    "formats": ["markdown", "screenshot"],
    "actions": [
      {"type": "wait", "milliseconds": 1000},
      {"type": "click", "selector": "#load-more"},
      {"type": "screenshot"}
    ]
  }'

A successful call runs the page’s JS, performs the actions in order, and returns the rendered markdown plus a screenshot. Firecrawl scored valid image 1.00 at $0.001 / call and ~1.3 s on our screenshot corpus. For multi-step, stateful, or auth-walled flows you drive yourself, escalate to a Browserbase session — it returns a session handle you connect to over Playwright/CDP, not one-shot content.

Fallback ladder

Match the tool to the interaction. Start with one-shot scripted actions and escalate to a full session only when the flow genuinely needs state — every provider below is on the same key, so escalation is a one-line path change, not a new account. Screenshot metrics are measured by the Auxiliar curator fleet on one corpus; session drivers are qualitative by nature.

The rule of thumb: Firecrawl actions for scripted one-shot interaction and capture; Browserbase when you need to hold a session across steps; Apify when someone already built the exact flow.

Eval-backed, not marketing claims

The screenshot numbers above come from the Auxiliar curator fleet running each provider on the same corpus — a merit-only ranking, not a listicle. Session drivers are documented on their scorecards. Verify or route from the source:

• Best screenshot API — the full ranking with methodology (valid-image rate, latency, cost).
• Browserbase · Apify · Firecrawl — per-provider scorecards.
• /evals.json — the machine-readable catalog + eval endpoint your agent (or the auxiliar-mcp server) can read directly.

Optimizing for cost

Right tool first, then squeeze cost — in that order:

1. Prefer one-shot over a session. A scripted Firecrawl actions call is cheaper and simpler than spinning up a stateful browser. Reach for a session only when the flow truly needs to hold state across steps.
2. Close sessions promptly. Stateful browser time is metered; an idle session left open is pure waste. Open, drive, capture, close.
3. Capture only what you’ll use. Ask for markdown or a screenshot based on what the task consumes downstream, not both by reflex.
4. Reserve stealth for defended pages. Anti-bot screenshot modes cost and take more; escalate to Scrapfly-grade stealth only when a plain capture is actually blocked.
5. Track cost per successful flow. Measure cost ÷ completed flows per provider per target, not raw request price — that’s what reflects real spend.

Because scripted actions, full sessions, and screenshots all sit behind one key and one balance, this is routing logic in your agent — no renegotiated contracts, no new signups to change the mix.