You can use DeepSeek V4 Pro for the reasoning in a browser task, but the model does not operate a signed-in website by itself. Connect a currently available route to a local agent that supports tool calls, then use Tabbit CLI with the signed-in Tabbit Browser. The assigned task is reading an approved preview page and returning its title and status. Verify model route, local runtime, browser session, and site permission separately.
A commenter in the launch thread said, “The important bit was that it’s working.” That is a useful reminder to verify a visible result and then review it, not to assume the model has browser access. (Original Reddit thread)
Key takeaways
DeepSeek's current docs list
deepseek-v4-proas V4-Pro-0813 anddeepseek-flashas V4.1-Flash-1017. The legacydeepseek-v4-flashroute is served by the newer Flash model.Tool calling lets the model request an action. A local agent executes it. Tabbit CLI connects to the local Tabbit Browser session; the website still enforces its own permissions.
Keep the first task read-only. Save a named handoff for a person instead of letting the agent publish.
Check the model version before setup
DeepSeek announced V4 Preview on April 24, 2026. Pro had 1.6T total parameters and 49B active; Flash had 284B total and 13B active. Pro GA followed on August 13. The official V4-Pro-0813 card says it supersedes the preview, lists an MIT license, and shows an 865 GB repository. Flash then had a 0731 checkpoint, V4.1 Flash, and the October 17 Flash-1017 update. Current docs list the hosted API IDs and versions. Check the preview release, Pro GA note, Flash-1017 note, and live model list immediately before configuring a client.
| Name | What it identifies | Current use |
|---|---|---|
| DeepSeek-V4-Pro preview | April 24 checkpoint | Historical open-weight release; not the current Pro API version |
| DeepSeek-V4-Pro-0813 | Pro GA checkpoint | Open weights under MIT; official local inference paths use vLLM/SGLang and substantial hardware |
deepseek-v4-pro | Hosted API route | Current docs map it to V4-Pro-0813; tool calls are supported |
deepseek-flash | Hosted Flash route | Current docs map it to V4.1-Flash-1017, not April Flash preview |
The first and second rows are not interchangeable with the API aliases. A third-party inference host can expose a different model name, checkpoint, tool-call format, and data policy. Verify all four before you make it part of a browser workflow.
OpenRouter lists the April checkpoint as DeepSeek V4 Pro 0423 under deepseek/deepseek-v4-pro. DeepSeek’s own API uses a different model mapping. If you need the original release, pin a verified provider route or serve the original weights and confirm the client can call tools. OpenRouter model entry, Official API mappings
Separate the three systems
| Part | Responsibility | What to verify |
|---|---|---|
| DeepSeek model | Understand the request and emit a tool call | Exact model ID/version and provider's tool-call support |
| Local agent client | Decide whether to call a tool and pass its result back | Client can reach the selected provider and load the Tabbit skill |
| Tabbit CLI + Browser | Open the permitted page in a separate task tab | Correct Tabbit instance, working launcher, visible signed-in page |
DeepSeek's tool-call guide says the integrating application supplies and executes the function. The model does not gain browser access by itself. The Responses API exposes function_call items, but your agent must implement the execution loop. Loading /tabbit is also separate from CLI reachability and website login. Pi uses /skill:tabbit; some clients use /skills. Follow the exact skill discovery syntax documented by the client you run.
Run the assigned task without writing to the page
Read an authorized release preview and record the visible title, URL, status, and workspace. Use a separate Tabbit task tab and keep the page open for a reviewer.
Install Tabbit Browser and set up Tabbit CLI on this computer. Tabbit CLI quick start
Sign in to the target website yourself in Tabbit Browser.
Start a separate local agent task. Run
tabbit-cli diagnosewith the installed launcher and confirm the intended Tabbit instance. Do not acquire unrelated tabs.Load the Tabbit skill using the selected agent's documented command. Check that the CLI can see the browser. This check does not prove the model route or site permission.
Ask the agent to read only the named page or materials. Return exact visible fields and stop on an unexpected account, workspace, or denied state.
Review the output in the browser and create the named handoff. Do not save, send, or publish without human approval.
This environment's parent task tested session reuse with a localhost fixture: a pre-login read returned 401; after a test sign-in, a second named CLI task read the expected fixture title and record. That verifies Tabbit CLI session reuse here. It does not verify a DeepSeek model/client pairing.
A prompt with a review checkpoint
Use the installed Tabbit skill through this local agent. In a separate task tab, open [approved preview URL]. Do not change the page. Return its title, URL, visible status, and whether this account can read it. Create a review note named Release preview check with those values, the source URL, and any uncertainty. Stop if the page or account is unexpected. Do not save or publish.verify a preview page
Ask the agent to read the preview rather than infer which release is active. Record the visible page title, release/status label, URL, and the time you checked it. If the page says preview, do not call it general availability. If a release label is missing, record “not shown” and ask the owner.
Recheck a signed-in board using the same profile. Read the visible change dates, record IDs, and unresolved rows into the review note. Leave the board unchanged.
Decide whether the handoff is ready
| Review item | Ready when | Stop when |
|---|---|---|
| Model route | The exact API ID and mapped version are recorded | An alias is treated as the April preview weights |
| Browser page | Account, workspace, and page match the request | Login is missing, access is denied, or the page differs |
| Evidence | Each returned status is visible on the page | The agent fills gaps by guessing |
| Handoff | Named note has a source URL and unresolved items | The agent saves or publishes without review |
A Reddit commenter discussing the launch said a simple prototype worked but looked rough; another replied that getting the feature to work mattered most. This is a personal coding-agent report, not proof of browser integration or quality for your task. (Original thread)
Related setup guides
Tabbit CLI guide · connect an agent to an existing browser · first-task checklist · MCP vs CLI · Codex setup · DeepSeek Harness integration · OpenClaw browser setup · agent browser CLI tutorial
Human review handoff
Named draft: Release preview check. Confirm the account, permission, model version, and source links before anyone edits or publishes. This remains an editorial draft.
FAQ
Can it use my signed-in Tabbit session?
Tabbit CLI can use its connected local browser session when you have signed in and the page permits access. The model itself does not receive cookies or control the browser.
Is the API route the April checkpoint?
No. The API ID is a hosted route. April preview weights, later open checkpoints, and current hosted versions are separate; check the model list before a run.
Does tool calling mean the model can click a page?
No. The model requests a tool call. A local agent must execute the approved Tabbit CLI action and return the result.
Can I run the weights locally?
The repositories are MIT-licensed, but the Pro repository alone is shown at about 865 GB. Local use requires supported inference software and suitable hardware.
What should the first task do?
Return the page title, URL, visible status, and only the permitted fields needed. Stop if the account, workspace, or target differs.
Should the agent publish its draft?
No. Keep a named draft and ask a person to check sources, access, and wording before saving or publishing.