How to Use Qwen3.6-35B-A3B with a Signed-In Browser

You can use Qwen3.6-35B-A3B with a signed-in support site by serving that exact checkpoint in a local agent client, enabling its supported tool-call format, and letting Tabbit CLI read the authorized page. Save the visible ticket fields and source links to a named local Markdown draft. Do not change or reply to the ticket.

Check tool calls before giving the model a live page. One local-model user who tested several configurations reported a “higher chance of malformed tool calls interrupting an agentic process.” That report is about the author’s setup, not every runtime, but it is a good reason to start with a harmless check.

Key takeaways

• The exact open-weight checkpoint is Qwen/Qwen3.6-35B-A3B, licensed Apache-2.0 on the official model card.

• It has 35B total parameters and 3B active per token. Active parameters do not describe the full weight-memory requirement.

• The model, local agent client, and browser-control layer are three separate parts. A working model response does not prove the browser tool works.

• OpenCode can discover local vLLM models, but its documentation says vLLM discovery does not infer tool support. Enable and test that capability.

• Keep the support task read-only. Save an evidence table to a local draft, compare it with the ticket, and stop for human review.

Confirm which Qwen3.6 route you are running

The official model card lists the checkpoint and its license. It also gives separate serving notes for vLLM, SGLang, Transformers, and other runtimes. A3B means roughly three billion active parameters per token; the checkpoint still contains 35 billion total parameters. Memory use depends on weight format, context, and runtime. A third-party quantization may have its own file and license details, so verify that repository too.

Do not confuse this checkpoint with the separate Qwen3.6-27B model or Alibaba Cloud’s hosted qwen3.6-flash API. If you need a hosted API, configure that service explicitly. This article uses local weights.

Serve the model with tool calls enabled

The Qwen card’s vLLM example for tool use includes a reasoning parser and the qwen3_coder tool-call parser. It also shows an eight-way tensor-parallel setup. Treat those flags as a version-specific reference, not a one-size-fits-all hardware recipe. Follow the current card and serving-framework instructions for your machine.

vllm serve Qwen/Qwen3.6-35B-A3B \
  --port 8000 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

The official card recommends current compatible vLLM releases. Before connecting a browser, send a no-side-effect test call and confirm the server returns a structured tool call rather than plain text that only looks like one.

In OpenCode, open /models and choose the discovered local vLLM model. Its local model documentation says vLLM discovery does not infer tool support. Check the model’s tool setting and configure it explicitly if needed. The Qwen model card remains the source for parser flags; OpenCode’s model selector remains the source for what the client actually exposes. For another local tool protocol, see browser MCP versus CLI.

Install Tabbit Browser and load its local skill

1. Install and open Tabbit Browser. Sign in to the support site with an account authorized to read the ticket.

2. Restart OpenCode so it can discover Tabbit’s skill at ~/.agents/skills/tabbit/SKILL.md.

3. Use OpenCode’s skill syntax @tabbit to load it. This tells the client to read the instructions; it does not verify the browser connection.

4. Open a terminal on the same machine and run ~/.local/bin/tabbit-cli diagnose. Confirm the intended Tabbit instance and that the launcher reaches it.

5. Give the read task a clear name. The CLI owns a separate task page while the selected browser profile supplies the existing site login. You can continue working in other tabs.

The Tabbit CLI guide explains tasks, owned pages, and receipts. If the support ticket is already open, follow the existing-browser connection guide. Before accessing a real ticket, review the first-task checklist and login-session boundaries.

Read the ticket into a local draft

Keep the first run narrow. Ask for fields that are visible on the ticket page and links that open the referenced material. Do not request an answer to the customer or any ticket mutation. A local draft makes the output easy to inspect without creating a second service-side record.

@tabbit
Read the installed Tabbit skill. Use the local Tabbit CLI and create a task named "qwen-support-ticket-review".
In the signed-in Tabbit profile, open the support ticket URL I provide. Read only fields visible on the page: ticket ID, status, owner, last-updated time, issue summary, and linked source URLs.
Do not click Reply, Assign, Change status, Save, or any other control that changes the service.
Create a local Markdown draft named "Qwen-support-ticket-review.md" in the review folder I specify. Use a table with one row per field, the visible value, and the page or link that supports it. Omit customer email, phone, names, tokens, and unrelated personal details.
After saving, report the local file path and any field you could not verify. Stop for my review.

The intended workflow is only a proposal until you run it in your environment. If the agent cannot open the page or cannot produce a valid tool call, stop and fix that layer first. Do not ask it to keep trying on the live ticket. The prompt template guide has more ways to state task limits; source-checking guidance shows how to verify citations and links.

Use this checklist before accepting the draft

A local model can format the result, but you are responsible for accepting it. A Reddit user’s “Browser OS” test used the llama.cpp web UI, not a browser agent. The discussion also includes both successful and failed quantized runs. The thread is a reminder that model generation quality and signed-in site control are separate tests.

A creator’s Playwright MCP demo describes running Qwen3.6 locally and testing tool calls. It is an example of a model plus a browser-tool server, not proof of Tabbit compatibility. Use the MCP versus CLI guide to choose a bridge, and how to let an agent control your browser for the human handoff.

Where Tabbit fits

Tabbit Browser is the local browser in this workflow. Its installed skill gives a local agent a documented way to run the CLI against the selected Tabbit instance. Existing login state belongs to that browser profile; a named task gives the agent a separate owned page and task context. It does not create a separate site account or guarantee access to every page.

A project synthetic fixture confirmed that a second named CLI task could read a page after test sign-in. It did not run Qwen3.6, touch a support system, or test OpenCode end to end. Treat the recipe above as a setup guide and complete the harmless tool-call test yourself. The complete Tabbit CLI tutorial covers the task lifecycle, while the browser task prompt guide helps make a review checkpoint explicit.

Verdict

Qwen3.6-35B-A3B can be part of a signed-in browser workflow when a local serving runtime emits tool calls correctly and a local client can run Tabbit CLI. Confirm the exact checkpoint, license, parser, client tool setting, and browser connection. Read the ticket into a named local draft, verify every field, and leave any ticket change for a human-approved step.

Secholar.L

Growth & Content at Tabbit

Secholar.L writes hands-on guides about AI browsers and agent workflows, comparing tools with real research and citing verifiable sources.