You can use Grok 4.3 with a signed-in browser by selecting its exact API route in a local-capable agent client and giving that client access to Tabbit CLI. Grok 4.3 supplies the model; Tabbit Browser supplies the existing website session; the local agent client connects them. For a safe first task, read an authorized page, fill a test form, and stop before submitting.
That model choice can be hard to see in the consumer app. A Reddit user wrote, “I'm not sure where to find out which model I'm currently using.” The thread is a useful reminder to distinguish an app mode from an API model ID.
Key takeaways
The verified API ID is
grok-4.3; OpenCode’s provider catalog identifies it asxai/grok-4.3.xAI Web Search and X Search run on xAI’s servers. They search public sources; they do not inherit cookies from your local Tabbit profile.
Grok Bot is another route. It uses a persistent cloud computer, which is not the local Tabbit Browser session described here.
A local agent client needs both the model connection and permission to run Tabbit’s installed local CLI.
Keep the first task read-only or stage-only. Review each field in the browser and stop before a production submit action.
Which Grok route reaches which browser?
| Route | Where it runs | What it can reach | Use it when |
|---|---|---|---|
| Grok API with Web Search or X Search | xAI servers | Public web pages or X posts found by those tools | You need current public information and citations |
| Grok Bot computer use | Persistent cloud computer | Its own browser, files, and connected apps under its permissions | You want xAI’s separate cloud-agent product and accept its cloud session boundary |
OpenCode + xai/grok-4.3 + Tabbit CLI | Local agent process and your selected Tabbit profile | Pages available to the authorized Tabbit browser session | You need a specific local login session and a reviewable form handoff |
xAI documents Web Search and X Search as server-side tools. Its current Grok Bot computer guide describes a separate persistent cloud computer. A setting that routes cloud traffic through your desktop does not make that cloud browser the same profile as Tabbit. Read web search versus browser control before choosing a route.
Confirm Grok 4.3 is the model your client will call
The xAI Grok 4.3 page still documents the exact API model name grok-4.3, even though xAI’s catalog also lists newer models. The current Models.dev xAI catalog gives the OpenCode model key as xai/grok-4.3 and marks tool calling as supported. This verifies the catalog route, not that every account or client exposes it.
In OpenCode, connect an xAI account with /connect, then open /models and select xai/grok-4.3 if it appears. OpenCode’s xAI provider guide documents subscription OAuth and API-key routes. If the exact ID is missing, stop and check provider access or current client configuration. Do not substitute a Grok website mode and assume it is 4.3.
The xAI API can also make server-side function calls. That is different from a local browser connection. A client must receive the tool call, run the local tool, and return its result. The function-calling guide explains the API side; your local agent still needs a working bridge to Tabbit.
Install Tabbit Browser and connect the local skill
Install and open the official Tabbit Browser. Sign in to the authorized site in the Tabbit profile you want to use.
Restart OpenCode after Tabbit installs its skill. OpenCode supports global skills under
~/.agents/skills/; check that~/.agents/skills/tabbit/SKILL.mdis visible.In OpenCode, invoke the skill with
@tabbit. This is OpenCode’s skill syntax. The Tabbit quick start’s/tabbitcheck is for clients that expose that slash command.In a terminal that can reach the same browser, run the installed launcher’s
diagnosecommand. On macOS the launcher is~/.local/bin/tabbit-cli.Give the browser task a name and ask the agent to use only the authorized page and test form. A named CLI task owns its own page and task state; it does not make a new website login. Keep using your other tabs while it works.
The Tabbit CLI guide shows the launcher, task names, and receipts. If the client sees the skill but the CLI cannot reach the browser, treat that as a separate connection problem. See how to connect an agent to an existing browser, the MCP versus CLI comparison, and how browser tasks reuse a login session.
Stage source data in a test form
Use a test form you are allowed to edit. Ask Grok to copy only fields that are visible on the source page. Keep email addresses, phone numbers, credentials, and unrelated customer details out of the draft unless the task requires them and you are authorized to handle them.
This prompt makes the boundary concrete:
@tabbit
Read the installed Tabbit skill and use the local Tabbit CLI.
Create a task named "grok-source-to-staging-review".
In my currently signed-in Tabbit profile, open the source page I identify and verify its visible title, date, and canonical URL.
Open the authorized test form I identify. Fill only the title, source URL, and short summary fields with values supported by the source.
Do not click Submit, Publish, Save, or any control that writes the record. Leave the form staged for review.
Return the source URL, the three staged values, and any field you could not verify. Stop for my review.The @tabbit mention asks OpenCode to load the skill. The task name tells the skill how to scope the browser run. To prepare a reusable instruction, see the browser-agent prompt template. If the source is already open in a user tab, follow the client’s supported existing-tab workflow in the first-task checklist.
Review each field before submission
| Check | Evidence to see | Stop when |
|---|---|---|
| Source identity | The visible page title and URL match the approved source | The page is a login wall, a different record, or an unexpected redirect |
| Summary | Every sentence is supported by the source; uncertain claims are marked | The agent added a date, claim, or context that is not visible |
| Staged form | Only the three authorized fields changed | A hidden or unrelated field was edited |
| Submission state | Submit/Publish remains untouched and the record is still a test draft | The form auto-saved or the destination is production |
| Evidence | You can open the source URL and compare each staged value | Any value cannot be traced to the page |
A click is not proof that a form saved, and a populated field is not approval to submit. Use the read-and-check guidance in browser-agent research with sources. If the task is a real consequential action, add a human checkpoint as described in how to let an AI agent control a browser.
A local Tabbit task is the practical bridge
The product boundary matters more than the model name. In a local project fixture, a page rejected an unsigned request and a separate named Tabbit CLI task could read the page after a short-lived test sign-in. That fixture checks Tabbit CLI session reuse only. It does not show Grok 4.3 connected to Tabbit, and it is not a result from a production site.
A creator’s YouTube demo describes a laptop setup where an agent reads and writes files through the Grok web app using MCP. It is one small creator’s architecture example, not evidence of an official xAI-to-Tabbit integration. The useful lesson is narrower: name the client, the model route, and the browser bridge separately.
Choose this local route when the task depends on an existing Tabbit login and a person should inspect a staged result. Choose xAI Web Search or X Search for public research. Choose Grok Bot only when its cloud computer is the intended workspace. For extra checks before a first run, use the browser-agent first-task checklist.
Verdict
Grok 4.3 can participate in a signed-in browser workflow through a local agent client, but the model does not automatically inherit your Tabbit session. Confirm xai/grok-4.3, confirm OpenCode can load @tabbit, confirm the installed CLI reaches the intended browser, then stage only authorized fields. Inspect the form yourself and stop before submission.
FAQ
Can I use Grok 4.3 in the Grok website?
The Grok website may choose or change the model behind its app modes. For a workflow that must use the exact API model, check the client model selector for xai/grok-4.3 and confirm the returned provider model where available.
What does Grok 4.3 need to operate a signed-in browser?
The model needs a local agent client that can run tools on the machine with Tabbit Browser. Connect the model, load the Tabbit skill, confirm the installed CLI can reach the intended browser, then test a harmless read-only task.
Does xAI Web Search use my Tabbit login?
No. Web Search and X Search are xAI server-side tools for public sources. A local Tabbit CLI task is a separate browser route that can use the authorized sign-in in the selected Tabbit profile.
Can I stage a form without submitting it?
Yes, if you authorize the source and test form, tell the agent to fill only the named fields and stop before the submit control. Review every staged value in the browser yourself.
Will a named Tabbit task log me out of my other tabs?
A task owns its task pages and task state, while website storage depends on the selected Tabbit profile. You can continue using other tabs, but tasks in the same profile can share the same login state.
Is Grok Bot the same as Grok 4.3 plus Tabbit CLI?
No. Grok Bot is a separate product with a persistent cloud computer. Its cloud browser, local-computer permissions, and model selection are distinct from an OpenCode session that calls Grok 4.3 and Tabbit CLI locally.