Agent Computer

VC Tools

VC Tools gives agents a hosted, metered, account-scoped computer for inspecting the web, running bounded diagnostics, crawling public pages, saving proof, and following work status without borrowing the user's local machine or raw provider credentials.

VC Tools beta Agent Computer guide for Vibecodr Quick Checks, Agent Browser, hosted Computer commands, Crawl, Saved Proof, work status, and account setup.

Implementation focus

Use this when installing `@vibecodr/vc-tools`, approving `vc-tools start`, connecting an MCP-compatible agent, reading usage, or deciding whether Quick Checks, Agent Browser, hosted Computer commands, Crawl, Saved Proof, work status, and retention belong in the hosted tool service.

Expected outcomes

Understand the difference between Vibecodr CLI, MCP, and the separate `vc-tools` CLI.
Know which Quick Check, Agent Browser, hosted Computer, Crawl, Work, Proof, usage, dashboard, diagnose, and doctor commands exist.
Explain how tool credits, build minutes, crawls, Scheduled QA, and Agent Browser tasks are bounded by plan.
Set up browser-approved access first, with file/stdin credentials reserved for isolated agents and automation.
Understand where Saved Proof evidence lives and why account ownership checks guard reads and downloads.

What vc-tools is

`vc-tools` is the beta Vibecodr Agent Computer for web-aware diagnosis. The local command helps a human approve account access, then gives agents a hosted Browser, hosted Computer, Work status, Saved Proof, usage, plans, dashboard links, and doctor checks without turning the user's machine into the execution boundary.

The product is separate from the Vibecodr CLI. Use the Vibecodr CLI for ordinary Vibecodr terminal workflows, and use `vc-tools` when an agent needs page checks, runtime diagnosis, hosted command diagnostics, bounded crawls, or durable proof around a tool run.

Quick Checks render public HTTPS pages, capture screenshots, extract page text, and produce PDFs.
Agent Browser gives paid agents longer hosted browser tasks with plan caps and idle closure.
Computer commands submit bounded command or test diagnostics to the hosted service instead of running locally.
Crawl collects bounded public-site context by page, depth, and monthly limits.
Saved Proof stores screenshots, reports, logs, files, and long outputs so agents can reference evidence after a run.
Work controls let users and agents follow status or cancel confirmed stuck hosted work without making jobs the normal product language.

How plans and limits work

VC Tools is included with Vibecodr plans as its own allowance. Build minutes and tool credits are separate buckets inside the same subscription, so a busy build does not consume browser-check credits and a browser-heavy agent run does not consume build minutes.

Free keeps a small beta floor for evaluation. Creator and Pro are the paid-plan lanes meant for regular use. Current plan packaging is visible in pricing, `vc-tools plans`, and the usage screen; hosted enforcement is the final authority when a request would exceed the account's current allowance.

Free: 30 tool credits per month, 10 per day, 1 run at a time, Quick Checks only, crawl up to 10 pages per run and 25 pages per month, no Scheduled QA.
Creator: 600 tool credits per month, 90 per day, 2 runs at a time, Quick Checks plus 20-minute Agent Browser tasks, crawl up to 50 pages per run and 500 pages per month, Scheduled QA 30 times per month and as often as every 12 hours.
Pro: 3,000 tool credits per month, 400 per day, 5 runs at a time, Quick Checks plus 1-hour Agent Browser tasks, crawl up to 250 pages per run and 5,000 pages per month, Scheduled QA 300 times per month and as often as every hour.
Build limits stay separate: Free includes 30 build minutes per month, Creator includes 750, and Pro includes 4,000, with daily, job, concurrency, output size, and output file caps shown on the pricing and limits surfaces.

Set up access safely

Run `vc-tools start` as the normal setup path. It opens a browser/device approval flow, asks you to approve the matching code while signed in to Vibecodr, stores a durable account-wide credential locally, and returns the hosted connection details an agent needs.

Agents and CI that cannot use the browser flow can pass a credential by file or stdin. The CLI infers whether the value is a vc-tools grant, Clerk OAuth token, or scoped Clerk API key, then caches short-lived access and refreshes it from the durable credential when it can.

Use `vc-tools start` first; it verifies auth, account identity, usage, hosted health, and agent connection metadata together.
Prefer `vc-tools login --credential-file vc-tools-credential.txt` or `vc-tools login --credential-stdin` over command-line secret arguments for automation.
Use `vc-tools agent status` or `vc-tools auth diagnose` when another shell or agent cannot see the expected approval.
Use `vc-tools agent connect --client codex` to get Streamable HTTP MCP connection metadata for compatible agents.
Use `vc-tools usage`, `vc-tools work list`, and `vc-tools proof list` to understand what the current account can run and what evidence already exists.

Agent Computer setup powershell

npm install -g @vibecodr/vc-tools
vc-tools start
vc-tools agent connect --client codex
vc-tools computer status
vc-tools browser screenshot https://example.com --format png

Saved Proof, storage, and isolation

Saved Proof lives in the hosted `vc-tools` evidence store by default, not in a creator's editable source capsule or normal project storage. It is meant for run evidence: screenshots, PDFs, logs, reports, command output, and other files an agent may need to inspect or save after hosted work finishes.

Proof list, metadata, and download requests are checked against the authenticated account before bytes are returned. Knowing a proof id is not enough to fetch another user's output. Retention settings decide how long proof remains available, and expired proof should be treated as unavailable even if a work record still exists.

Saved Proof counts against `vc-tools` evidence policies, not against build minutes.
Save proof locally when a user wants to move evidence into their own workspace.
Do not use `vc-tools` Saved Proof as permanent app storage, source storage, formal memory, or a public file bucket.
Use retention controls when evidence should expire sooner than the plan default.

What agents should use it for

VC Tools is strongest when an agent needs to interact with the web like a careful website tester: render a public page, compare mobile and desktop output, capture console or network evidence, produce a PDF, check metadata, run a bounded diagnostic command, crawl a small public site, and return saved proof instead of a vague guess.

It is not sold as unlimited scraping infrastructure or a long-lived browser farm. Agent Browser tasks are capped by plan while the product is in beta. Quick Checks stay the default path for screenshots, rendered-page inspection, markdown extraction, PDFs, visual checks, and most automatic QA.

Good fit: Quick Checks, Agent Browser inspections, runtime diagnosis, screenshot proof, accessibility quick scans, SEO metadata checks, visual diffs, PDFs, bounded crawls, and hosted test diagnostics.
Poor fit: bulk crawling the open internet, arbitrary web automation, long-lived browser agents, user-controlled scraping infrastructure, or platform-funded repair loops without clear user action.
Agents should reserve a run only when they have a concrete target and expected output.
When a request is denied by quota, concurrency, auth, or URL safety policy, slow down or ask the user for a safer target instead of retrying blindly.

Beta support expectations

VC Tools is available as a beta surface. Commands, quotas, and tool availability may change while the product is hardened, but the public contract should remain straightforward: account-scoped auth, hosted execution, separate usage accounting, public-safe diagnostics, and durable saved proof.

When something fails, classify it before retrying: approval or credential setup, plan limit, unsafe URL, unsupported tool, hosted work failure, proof expiry, or service health. Include command name, work id when available, proof id, status, and public error fields in support reports, but never include raw API keys, access tokens, private source bundles, or credential-bearing URLs.

Use `vc-tools doctor` for local and hosted health checks.
Use `vc-tools auth diagnose` when approval appears missing in a shell or isolated agent.
Use `vc-tools help <command>` for focused command help.
Use support diagnostics when a public error includes an `errorKey`, request id, or retry hint.

Example and read next

Example: an agent needs proof that a public launch page renders correctly on desktop and mobile. Use `vc-tools` for Quick Checks, screenshots, Saved Proof, and usage visibility instead of giving the agent local browser control or raw provider credentials.

Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.

Read next: /vc-tools
Read next: /plans
Read next: MCP & CLI
Read next: Support Diagnostics
Read next: Account & Safety Controls