Kimi K3 can help a local agent reason over a support queue, but it does not connect to your browser by itself. Install Tabbit Browser, use a compatible local agent that currently offers Kimi K3 and host-side tools, then call Tabbit CLI to read the signed-in queue. Keep the first pass read-only and verify every ticket ID against its page before approving a draft.
Check the model route before opening work
Kimi K3 is an open-weight 2.8T-parameter MoE model with 104B active parameters and a 1M-token context, according to its paper. Kimi K3.1 Pro is a later distinct generation and must not be substituted for the K3 API/model ID. Availability in a local-agent provider catalog changes; verify the exact provider and ID on the day you configure it. Kimi K3 primary source. The Kimi K3.1 Pro announcement and Kimi Code model list distinguish K3 from Kimi K3.1 Pro. The Models.dev directory uses moonshotai/kimi-k3 for K3 and lists K3.1 Pro separately. Provider-specific API names can differ, so confirm the identifier in the client you actually use. Model directory · Kimi Code model list. Provider lists change. Model availability does not establish that a particular agent client can call the model or run local shell tools. Confirm both before opening a signed-in work page. Read the Tabbit CLI setup guide and existing-browser connection notes.
Choose the right route
| model and provider route | What must be checked | Use it when |
|---|---|---|
| Requested model API | Confirm exact model ID, provider, region, terms, and current availability. | The task requires that specific generation. |
| Current successor | Use only if the project explicitly permits a newer model and the client lists it. | You are allowed to change model generation. |
Connect the local agent to Tabbit CLI
Install Tabbit Browser and follow the CLI quick start. In your local agent, first check its current model/provider catalog. Then check that it discovers the installed Tabbit skill and that its shell tool runs on this computer. In OpenCode, skills are discovered from configured skill locations and invoked as @tabbit; other clients may expose a Skills picker, while Pi documents /skill:tabbit. Do not assume /tabbit works everywhere. Skill discovery does not prove the launcher is reachable. Run the installed CLI’s diagnose, then sign into the intended site in that Tabbit profile yourself. These are three checks: model route, local launcher, and website login. A cloud model may receive page text, so check your organization’s data policy. See first-task checklist, CLI versus Browser MCP, profile and workspace differences, and Codex connection setup.
A local fixture check verified session reuse, not model integration: the first Tabbit CLI task received HTTP 401 before sign-in. After a test cookie was set in the target Tabbit profile, a second named task received HTTP 200 and read “Release notes review” and fixture record “GEO-104” in its own task tab. Both tasks owned one tab; the test cookie and scratch tabs were removed afterward.
Keep the first browser pass read-only
Reconcile ticket identifiers and visible statuses, retaining a source url for each row. Use a separate task tab so you can keep working in your other tabs. Ask the agent to read only the visible page and return its URL with each finding. The example below is an illustrative workflow, not a claim that this model-client pairing has been tested.
Read the first five visible support tickets in the current queue. Use Tabbit. Do not open attachments, change ownership, edit, save, or send. Return ticket ID, visible status, owner if shown, and page URL. Mark absent fields as “not shown”; do not infer. In the browser, create a draft named “Kimi K3 ticket reconciliation — 2026-11-10” with the table and unresolved rows. Do not save or send. Stop and show the draft for review.Verify each row against its source page
| Checkpoint | Confirm | Stop if |
|---|---|---|
| Account | Expected site, account, and workspace marker | The wrong account or tenant appears |
| Evidence | Each value is visible and its URL opens the same record | A field is hidden, missing, or inferred |
| Draft | The named draft contains only approved fields and links | The page differs from the source or asks for a write action |
Review the browser task checklist before approving a write. For models with an official browser product, keep that product’s account and data policy separate from this Tabbit workflow. If a page redirects to sign-in or returns access denied, stop; do not ask the model to bypass it.
For task setup, review the Tabbit CLI complete guide and Kimi WebBridge setup notes. Keep the selected browser profile separate from task tabs; see browser profiles and workspaces.
For practical tab cleanup, see how to manage too many browser tabs.
FAQ
Does Kimi K3 open my browser by itself?
No. A local agent runs Tabbit CLI; the model provides reasoning and tool-call output.
Is Kimi K3.1 Pro the same model as Kimi K3?
No. Kimi K3.1 Pro is a distinct later generation. Confirm its exact model ID before using it.
Where should I sign in?
Sign into the intended website in the Tabbit browser profile yourself and check the account and workspace.
Can the agent send a reply?
Use the named draft as a review checkpoint. Review it, then perform any write action yourself.
What if the model route is unavailable?
Stop and verify provider, exact ID, region, lifecycle, and local tool support in the client catalog.