Skip to main content
Install Webcompute, sign in, configure model access, run a browser agent against a real public site, and inspect the browser run.

Prerequisites

  • A Webcompute API key with the wc_key_ prefix.
  • A model profile or provider key for web agent.
  • A shell with curl.
API keys and provider keys are credentials. Do not paste real keys into prompts, source control, issue trackers, or shared transcripts.

Install Webcompute

curl -fsSL https://install.webcompute.dev | sh
exec "$SHELL" -l

Sign in

web login wc_key_your_key_here
web status
web login stores your Webcompute API key for CLI and MCP use. SDK code can also use WEBCOMPUTE_API_KEY.

Configure a model

Run the interactive setup:
web model setup
The wizard saves a reusable model profile. If you accept the default profile name, the examples below use --profile browsing. You can also pass model access for one command:
web agent \
  --route openrouter \
  --model openai/gpt-5.4-mini \
  --api-key-env OPENROUTER_API_KEY \
  --url https://www.sec.gov/edgar/search/ \
  --allow-domain sec.gov \
  "Find Apple's latest 10-Q filing. Return filing date, accession number, filing URL, and a one-sentence summary."
Read model setup for profiles, routes, and provider environment variables.

Run your first browser agent

web agent \
  --profile browsing \
  --url https://www.sec.gov/edgar/search/ \
  --allow-domain sec.gov \
  "Find Apple's latest 10-Q filing. Return filing date, accession number, filing URL, and a one-sentence summary."
This creates a managed browser, starts from SEC EDGAR, stays inside sec.gov, browses the public filing search, and returns a short result.
A successful run prints a final answer with filing metadata. The exact filing date and accession number depend on the live SEC site.
Expected shape:
Apple Inc. latest 10-Q filing

Form: 10-Q
Filing date: <date from SEC EDGAR>
Accession: <accession number>
URL: https://www.sec.gov/Archives/...
Summary: <one sentence based on the filing page>

What happened

The agent path is the fastest starting point, but it still uses the same browser runtime as the SDK, MCP, REST, and CDP surfaces. During the run, Webcompute can produce:
  • A final answer for humans.
  • JSON output when you use --json or --schema.
  • A browser ID and signed Debug UI URL while the CLI run is active when you opt into --debug-url.
  • Bounded observations and step summaries.
  • Status, events, recordings, files, downloads, and artifacts when the workflow creates them.
The CLI agent closes browsers it creates after the one-shot run. Use the SDK when you need persistent browser inspection, recording, or session continuity. Use choose your path when you are ready to decide whether this workflow should stay delegated, move into SDK web.agent(), become deterministic Playwright code, or run through MCP.

Get machine-readable output

Use --json when another program will read the result:
web agent \
  --json \
  --url https://www.sec.gov/edgar/search/ \
  --allow-domain sec.gov \
  "Find Apple's latest 10-Q filing. Return filing date, accession number, filing URL, and a one-sentence summary."
Use --schema ./filings.schema.json when the run must return a validated JSON shape. The JSON envelope includes the run status, final text, structured output when requested, browser metadata when available, and redacted errors when the run fails. See what Webcompute returns for the surface-by-surface shapes.

Inspect the run

Use --debug-url only when you intentionally want a signed live-browser link in the result:
web agent \
  --debug-url \
  --url https://www.sec.gov/edgar/search/ \
  --allow-domain sec.gov \
  "Find Apple's latest 10-Q filing. Return filing date, accession number, filing URL, and a one-sentence summary."
Debug UI URLs are signed bearer capabilities. Share them only with people or systems that should control the live browser.
Webcompute Debug UI showing the active browser page, recording state, browser status, readiness, and timeline for a Playwright execution The screenshot above was captured from a local Playwright execution against https://example.com. Real agent runs expose the same inspection surface while the browser is live, and recordings can preserve evidence after the browser closes. The Debug UI link is available only when the browser is still live. A one-shot web agent run closes browsers it creates after completion. Use SDK browser creation or SDK web.agent() with recording when your workflow needs longer inspection or durable replay evidence.

If the quickstart does not finish

SymptomWhat to check
web agent cannot find a model profileRun web model setup, or pass --route, --model, and --api-key-env for one command.
Provider authentication failsConfirm the provider key exists in the environment variable named by --api-key-env. Do not paste provider keys into prompts.
The SEC site changes or blocks the runRe-run with --debug-url, inspect status and page evidence, and report the blocker instead of treating it as success.
No Debug UI URL appearsAdd --debug-url; Webcompute does not print signed live-browser URLs unless you ask for them.
You need the browser to stay openMove the workflow into the SDK and create the browser explicitly.

Next steps

Choose your path

Decide whether to use CLI agent, SDK agent, direct Playwright, MCP, REST, CDP, or quick actions.

Understand returned evidence

Learn what the CLI, SDK, MCP, REST, and quick actions return.

Run tasks with web agent

Learn model profiles, domain boundaries, schemas, secrets, approvals, and live inspection.

Try a richer task

Run a browser-agent task with fields, boundaries, JSON output, and blocker guidance.

Build with the SDK

Move from a CLI proof to a product workflow with web.agent().

Inspect and debug

Use live sessions, recordings, status, events, downloads, and errors when a run needs evidence.