Viv Fast can help interpret a page result, but it cannot open your signed-in browser on its own. Choose a client that can run Vivgrid's viv-fast model, then use its local Tabbit skill and CLI to inspect the authorized page. Diagnose the model route, skill discovery, CLI connection, and website login as four separate checks. A recent browser-automation discussion asked what breaks most and listed session loss among the routine failures. That is a general automation concern, not a Viv Fast test. Read the original thread.
Key takeaways
Vivgrid documents
viv-fastfor Chat Completions and Responses, and shows an OpenCode setup. Verify the model in your own account before using it.The model, local agent, Tabbit CLI, and signed-in website are different layers. A pass at one layer does not prove the next one works.
For access troubleshooting, ask the browser task for the page title, visible status, and exact URL. Keep the first pass read-only.
Tabbit Browser keeps the site login in the browser environment. A separate named task tab lets the agent inspect a page while you keep other tabs open.
Check each access layer
| Layer | What to verify | Evidence to save | If it fails |
|---|---|---|---|
| Model route | viv-fast is selectable through your Vivgrid account and client | Provider name, model ID, request status | Fix provider setup before blaming browser access |
| Client skill | The local agent discovers the installed Tabbit skill | Skill name and the client's actual invocation syntax | Use the client's documented skill mechanism; do not assume /tabbit |
| CLI launcher | ~/.local/bin/tabbit-cli diagnose reaches the intended Tabbit instance | Browser identity and task-owned tab count | Recheck launcher path and browser instance |
| Website session | The target page is signed in inside that Tabbit environment | Page title, URL, and expected visible account state | Sign in yourself in Tabbit Browser, then retry read-only |
Vivgrid's Viv Fast model page currently documents the model ID viv-fast, image input, function calling, and both Chat Completions and Responses endpoints. It also documents OpenCode selection through /models and model configurations for Codex and Pi. These sources establish the model route, not a native connection between Viv Fast and Tabbit. Check the provider's current account picker and your agent client's tool-call support before setting up a workflow.
Separate a login failure from a model failure
Start with a harmless preview or account page that you are authorized to read. Ask the local agent to open it in Tabbit Browser, return the page title and visible status, and include the exact URL. If the title is a login page, the task did not verify the target record. If the CLI diagnoses a browser but the page is logged out, the launcher works and the website session does not. Keep that distinction in the report.
This is useful for release preview checks, internal dashboards, and support consoles where the same page may show a login screen, permission error, or real content. Do not ask the model to infer an account state from a screenshot or a stale public URL. When the browser cannot reach the required page, stop and report the failed layer.
Use a short prompt that returns checkable evidence
The following example is an illustrative workflow. It does not claim a tested Viv Fast-to-Tabbit integration. The expected result is a short read-only report with one status per check.
Use the installed Tabbit skill from this local agent. Open the authorized preview page in a separate Tabbit task tab. Do not change the page.
Return: page title, exact URL, visible status text, and whether the page appears to be a login screen, permission error, or expected preview.
Save a report named "Viv Fast preview access check, draft 01". Include four separate checks: model route, skill discovery, Tabbit CLI connection, website login. Mark each pass, fail, or not checked and include the evidence. Stop before clicking submit, save, or publish.Expected output: the exact page URL, its visible title and status, and a four-row layer check. A screenshot alone is weaker evidence when the page text or account state can be read directly. Do not include passwords, cookies, customer names, or account identifiers in the report.
A practical option: Tabbit Browser and a local agent
Install Tabbit Browser, sign in to the target site yourself, and use a local agent that can discover the installed Tabbit skill and run ~/.local/bin/tabbit-cli. OpenCode documents the @tabbit skill syntax; other clients may expose a skill list or a different invocation. The installed skill file is at ~/.agents/skills/tabbit/SKILL.md. Do not assume a universal /tabbit command.
Skill discovery, launcher reachability, and website login are separate checks. A local test in this Tabbit environment verified that a second named CLI task could read a short-lived signed-in test page while owning its separate task tab. That confirms session reuse for the tested setup; it does not establish native Viv Fast integration. You can keep your other browser tabs open while the task runs. For setup details, see the Tabbit CLI guide, connecting an agent to an existing browser, the first-task checklist, and browser MCP versus CLI. Installation instructions are on the Tabbit Browser download page.
Decide what to do with the result
| Browser result | Likely meaning | Next step |
|---|---|---|
| Expected preview title and status | The selected page was readable | Reopen the URL and compare the visible status yourself |
| Login page | The site session is missing or expired | Sign in in Tabbit Browser; rerun read-only |
| Permission message | The current account may lack access | Ask an authorized owner to verify access; do not retry with another person's account |
| Unexpected title or host | The task may have reached the wrong environment | Stop and confirm the hostname and account before proceeding |
| No clear text or evidence | The result is inconclusive | Save it as unresolved and ask a person to inspect the page |
For other setup questions, read how to connect an agent to an existing browser, check a first browser-agent task, reuse a login session, choose between browser MCP and CLI, and install Tabbit Browser. The browser-agent security guide explains why a page-reading task should not inherit permission to submit or publish.
For tab ownership and client setup, also see browser profiles and task tabs and the Codex Tabbit CLI setup example.
Frequently asked questions
Does Viv Fast control browser tabs?
No. Viv Fast is the model. A local agent and browser connector perform the tab actions and send results to the model.
Does the Vivgrid model page guarantee it is enabled for my account?
No. The model documentation lists an API route, but you should confirm account access and the model picker in your provider console.
Is OpenCode's /models the same as the Tabbit skill?
No. /models selects the model provider. OpenCode's documented @tabbit invocation discovers the browser skill, which then calls the local CLI.
What if Tabbit CLI works but the page still shows sign in?
The browser connection works, but the website session is not authenticated for that page. Sign in yourself inside the Tabbit Browser profile the CLI reaches.
Can a cloud agent inspect my local Tabbit session?
Not automatically. It needs a separately supported local handoff, or you can run the browser task locally and share a minimized report.
Should the agent retry after a permission error?
No. Record the exact URL and visible message, then ask an authorized person to check the account's access. Do not work around a permission boundary.
FAQ
Can Viv Fast open a signed-in page by itself?
No. Viv Fast is the model route. A local agent must connect to a browser tool such as Tabbit CLI and pass the page result to the model. Check the client, launcher, and site login separately.
Which provider lists Viv Fast?
Vivgrid documents the model ID `viv-fast` and shows it on its Chat Completions and Responses surfaces. Check your current provider account and client configuration before relying on that route.
Can I use Viv Fast in OpenCode?
Vivgrid documents a built-in OpenCode provider flow: open `/models`, choose Vivgrid, and select `viv-fast`. That configures the model route; it does not by itself connect OpenCode to a signed-in browser.
Why does a browser task say a page is unavailable?
The client may not have discovered its Tabbit skill, the launcher may reach another browser instance, or the site may not be signed in there. Record which layer failed instead of treating every failure as a model problem.
Can a remote Viv Fast agent reuse my local login?
Only if the remote service has a separately supported local handoff. A hosted model API or remote runner cannot reach a local Tabbit profile just because it can answer prompts.
What should the first Viv Fast browser run do?
Use a page you are allowed to inspect, ask for its heading and visible status, and save the evidence with the page URL. Stop before submitting forms or changing records.