The agent that does the work and asks first.
VxComputer plans, runs commands, edits files, calls your cloud and drives a real browser, on a node that belongs to you. Every action passes a policy gate, risky ones wait for your approval, and every step is sealed into a ledger you can verify.
Already have an account? Open VxComputer in Chat
It does the work
Runs commands, edits files, calls cloud CLIs and drives a real browser, then answers from what actually came back.
It asks before it acts
Every action is risk-classified. Anything that changes state waits for an approval bound to that exact command.
It remembers and learns
Durable conversation memory, facts you ask it to keep, and skills it can learn from a run it just finished.
It leaves a provable trail
Each decision, tool call and approval is sealed into a hash-chained ledger on your node that you can replay.
Watch it work · simulated runs
Five requests, start to finish
Pick a request and watch the run unfold the way it does in Chat: routing, the plan, each tool call with its risk tier, the reflection after every step, then a streamed answer. When a step needs sign-off, the run waits for you.
Four tool families
Real hands, not just a chat window
The planner can only use what is in this catalog, one operation per call, and every call goes through the same policy gate.
terminal
Any shell command on your node: git, docker, kubectl, builds, tests, package managers. Read-only inspection runs straight away; the rest asks.
workspace
File operations with full-content writes and patches you can review. Writes to system, credential and shell-profile paths are blocked outright.
cloud
Provider CLIs with your workspace credentials injected by the tool. Arguments are passed literally, with no shell, so nothing can be piped or chained.
browser
A real browser, either the node’s own or your logged-in tab through the Companion extension. Reading is free; clicking and typing are approval-gated.
Architecture
One loop, one gate, one ledger, on your node
The control plane signs you in and binds a node to your workspace. Everything that acts runs on that node: the orchestrator, the policy guard, the tools and the state they leave behind. Click a box, or trace a request end to end.
Policy gate
It asks before it acts, and some things it never does
One guard sits between the planner and every tool. It decides from the command itself, not from what the model says the command does.
- Three risk tiers. Low runs; medium and high stop for approval.
- Fails toward asking. A command the rules do not recognise is treated as medium.
- Command-bound approvals. HMAC-signed tokens tied to the SHA-256 of one exact command, for one step, for 15 minutes.
- A hard floor. Wiping the root filesystem, raw-disk writes, opening the firewall, fork bombs and credential exfiltration are refused, approval or not.
- Skills only narrow. A skill can remove tools and steps from a run. It can never loosen policy, approvals or funding.
The run halts with a pending approval. A signed token is minted for the SHA-256 of this exact command and step, with a 15-minute default lifetime. Change one character and the token no longer applies.
A browser port of part of the node's rule set, for illustration. The node runs the complete rules on every shell command, and checks file writes and browser actions with their own rules.
Tamper-evident audit
A record nobody can quietly edit
Each record on the node’s ledger carries the SHA-256 of the record before it. The hashes below are computed in your browser the same way, so you can try to rewrite history and watch the replay catch it.
Rewrite record #4184 so the patch looks read-only, then verify the ledger.
sealing records…Models and cost
Your model, your bill, and no surprises
Pick who pays and which model answers, per conversation. VxComputer spends the expensive model where it matters and tells you exactly what each stage used.
Use VxCloud’s hosted models, drawn from your plan’s AI credits.
Anthropic, OpenAI or Gemini keys, held in your workspace’s Vault.
Ollama on the node. No per-token cost and nothing leaves the machine.
Claude Code or Codex CLI, running headless on the node.
- Cost tiering. The router, the most frequent call in a run, can run on a local model.
- Honest fallback. If your model is unavailable the run falls back, and the footer names the model that really answered.
- Metered per stage. Retries are counted, and prompt-cache reads are kept apart from fresh input because they bill at a fraction of it.
| stage | model | in | cached | out |
|---|---|---|---|---|
| router | ollama:qwen2.5:7b | 412 | — | 3 |
| planner | claude-sonnet-5-5 | 1,304 | 1,601 | 188 |
| executor | claude-sonnet-5-5 | 733 | 1,601 | 142 |
| reflector | claude-sonnet-5-5 | 410 | 1,601 | 64 |
| answer | claude-sonnet-5-5 | 1,047 | 1,601 | 345 |
Skills and memory
Teach it once. It remembers.
A skill is a SKILL.md: when to use it, which tools it may touch, how many steps it may take, and how to answer. Write one by hand, or let VxComputer draft one from a run it just completed.
- Six built-in skills: web research, evidence research, page screenshot, site check, server health, log triage
- Workspace skills are versioned and immutable; pin name@3 when you need repeatability
- /skills learn grants exactly the tools a run used, and no more
- Conversations persist on the node across restarts; /remember keeps facts for later sessions
- Secrets are redacted before anything is written to memory
1---2name: server-health3version: 14description: Read-only health check of this node: load, memory,5 disk, failed services, listening ports and top processes.6triggers: [server health, node health, disk space, memory usage]7allowed_tools:8 - tool: terminal9 actions: [run_command]10max_steps: 511---12Goal: a health snapshot of THIS node from real command output.13Inspect only; change nothing.14 151. Load and memory: uptime; nproc; free -m162. Disk: df -h -x tmpfs -x devtmpfs -x squashfs; df -i /173. Services: systemctl list-units --state=failed --no-pager184. Processes: ps aux --sort=-%cpu | head -619 20Answer: a one-line verdict, then | Area | Status | Evidence |,21then "### Next steps". Restarts and cleanups need the user's go-ahead.Skills only narrow
A skill can take tools and steps away from a run. It never changes policy, approvals or who pays.
Everywhere you work
One agent, six ways in
The VxComputer tab on vxcloud.io/chat, with streaming answers, approval cards and a model picker.
The side panel on every dashboard page: same agent, same commands, same model choice.
One-shot runs, a live streaming REPL, approvals, audit replay and scheduled objectives from your terminal.
A side panel for Chrome and Firefox that lets the agent work in the tab you pin, with a visible cursor.
Mention @vxai in a room to summarise a thread or answer a question in place.
REST and WebSocket on your node, plus an MCP server so Claude or Codex can call VxComputer as a tool.
Type / or @ in any chat surface
Commands are handled on the node, so they behave the same in Chat, the dashboard panel and vxcli. @-mentions hand one turn to a specialist; /agent keeps one on the conversation.
For developers
Drive it from your terminal, your code or another agent
Everything in Chat is available on your node: a REST call for one run, a WebSocket that streams every event, the vxcli commands that wrap both, and an MCP server for other agents.
- Halted runs resume from their checkpoint with the approved command
- The WebSocket accepts a cancel frame to stop a run in flight
- run_complete names the model that actually served the run
- Full reference in the vxcli docs
1# One run of the Plan → Act → Reflect loop on your node2vxcli vxcomputer run "Why is this node slow?"3 4# Ask the policy how it would treat a command, without running it5vxcli vxcomputer classify docker restart api6 7# A step paused for sign-off: approve that exact command, then8# resume the same run. No replanning, completed steps are not re-run.9vxcli vxcomputer approve --run <run_id> --command "docker restart api"10vxcli vxcomputer run --resume <run_id> --approval 'docker restart api::<token>'11 12# Live streaming REPL, and a replay of the audit ledger13vxcli vxcomputer chat14vxcli vxcomputer audit-verify15 16# Schedule an objective on the platform scheduler17vxcli vxcomputer cron add "Health sweep" --every 30Approvals survive the hand-off
An MCP client or a script gets the same gate as Chat: anything that changes state still waits for an approval token.
Questions
Before you hand it the keys
Give it a real task. Keep the final say.
Start a workspace, pick your model, and ask VxComputer for something you would normally open a terminal for. It will show you the plan, ask before it changes anything, and keep the receipt.