What it does
One tier of Vision runs the official Claude Code tool on my subscription instead of the API. It answers only messages I send myself with an explicit command, and it is the one exception to the rule that every model call passes the gateway.
Because it is a full agent tool rather than a single model call, it runs inside several layers: its own network, a fresh workspace for every call, a check of what it actually loaded, and the same read-only tools as the strong model. This page names those layers and why each exists; the exact configuration stays private.
Why this way
Decision 01
Read the terms first, then set limits
Before building anything I read the consumer terms, the usage policy, the tool’s documentation on authentication and running without a screen, and the support articles, and wrote down the passages that apply. They didn’t settle whether a personal assistant that passes on its owner’s own requests counts as ordinary, individual use, so I took the narrow reading. The worker runs only for requests I send myself, never on a schedule or in the background. It uses the official tool with the sign-in that tool creates itself, never a copied or forwarded credential. And it stops at the first warning or unusual throttling, and then I decide how to go on.
Rejected: scheduled runs on the subscription
A weekly research digest, for example, runs on the API through the gateway instead.
Decision 02
The strong model is the default; the worker is a command
My first design sent every complex message to the worker. Once I had prepaid API credits I turned that around: complex messages go to smart through the gateway, where budgets, chat history and evals apply. The worker answers only a command I type in my private chat. It gets the message as a task, without the chat history, and makes at most 30 calls a day. If it is off, at its cap, cooling down or failing, smart answers, and the reply says so.
Rejected: the worker as the default for complex messages
It would answer outside every budget, eval and chat history that the strong model has.
Decision 03
Isolated by layers
The worker sits on its own network, with no route to the database, the gateway’s model endpoints, my home network or the internet. A filtering proxy is its only way out, and it lets through only the provider’s API and the gateway’s tool endpoint. Every call starts in a fresh, empty workspace that is deleted afterwards, with no project files or settings brought in and no session kept. Its only credential is the subscription sign-in, and it refuses to start if any other way to reach a model is present. Its tools are the same read-only knowledge, file and homelab tools as smart, under the same rules: at most 6 calls, every result marked as untrusted data, and anything that runs code, writes files or fetches from the web refused outright.
Rejected: putting the gateway on the worker’s network
Every gateway endpoint would then be one step away from the worker.
Decision 04
Check what actually loaded, on every call
At startup the tool reports what it loaded: how it signed in, and its tools, servers, plugins, skills and memory. The worker compares that report with the exact expected set on every call, and anything extra, or any sign-in other than the subscription, discards the call. It also watches the stream: a tool result that arrives without its untrusted-data marking ends the call. The tool’s own settings alone weren’t enough, as the first lesson below shows.
Decision 05
Fall back, or switch off and say so
An ordinary failure, such as the worker being off, at its cap, busy, too slow or returning something unusable, falls back to smart in the same run. Hitting a usage limit adds a cool-down. A sign-in problem, a refusal, an unexpected load or any unknown error switches the worker off until restart; the reply says so in one sentence, and the switch-off is its own step in the run record.
How it's tested
Tests with the real tool, offline
The tests run the real tool against a fake model API, a fake gateway and the real proxy, so they cost nothing. With the safety hooks removed, the call is refused; with an extra tool on the gateway, the startup check catches it. The proxy’s rules have 39 test cases of their own.
The cap, the sender, and files that are never read
The daily cap counts failed calls too, and every reply shows the day’s count. Only signed messages from my private chat can reach the worker; since the signed sender, the IDs inside a request alone are no longer enough. Instruction and configuration files planted near the workspace are never loaded, in a test.
The same recipe against Vision’s own harness
On 46 read-only cases, run twice each, both on the API through the gateway and with the same model, the Claude Code recipe and Vision’s own harness each solved 92 of 92. Claude Code cost $0.0235 per solved case and Vision $0.0131. The gap came from Claude Code’s larger prompt, about 7,000 more tokens per solved case, and its lower share of cache reads. With no quality difference on these cases, there was nothing to adopt yet.
| What | Value | n | Date |
|---|---|---|---|
| Benchmark solved vision | 1.0 | 92 | 2026-11-12 |
What I learned
Case 01
Plugins the settings didn’t stop
What happened
A dry run of the pinned tool showed two built-in plugins in its startup report, loaded despite the settings meant to keep them out, and one of them would have read instruction files from the folders around the workspace. When I later switched skills on, 15 bundled skills appeared next to mine.
What I changed
Both are now switched off explicitly, and the startup check requires exactly the expected plugin and skills.
Result
The worker runs only what I meant it to run, and the lesson stuck: verify what a tool loaded, not what you asked it to load.
Case 02
A bound that wasn’t there
What happened
I planned to limit each call through a setting of the tool, but the pinned version didn’t offer it.
What I changed
I use only what the pinned version documents, so the bound became three things I control: the hook that counts tool calls, the stream check, and a timeout.
Result
Every call is bounded, by layers I can test, not by a setting I hoped was there.
Case 03
The terms didn’t answer the question
What happened
The pages I read left the key question open: whether a personal assistant passing on its owner’s requests is ordinary, individual use.
What I changed
I wrote down both readings, with the arguments for and against each, and chose the narrow scope: my own requests, a command I type, no automation.
Result
The worker stays inside a reading I can defend, and every limit on this page follows from it.