CoBuddy cannot operate a signed-in browser on its own. First confirm a provider route for the Baidu Qianfan model, then choose an agent client that can run local tools. In this workflow, the client invokes the installed tabbit skill or Tabbit CLI against a named Tabbit Browser session; CoBuddy supplies the plan, while the local browser performs the page read. I could not verify a Baidu-owned public API page for this exact model ID. Novita AI currently offers a hosted CoBuddy API with model ID baidu/cobuddy; that is a third-party route, not a Baidu-direct endpoint. The Novita CoBuddy page documents the route, and Models.dev lists Novita AI as a provider. Baidu’s Qianfan developer center documents API development generally.
Key takeaways
CoBuddy is a model entry associated with Baidu Qianfan, not a browser client or a Tabbit feature.
A model endpoint and a local browser tool are separate capabilities. Your host needs both.
Use the route currently shown by your provider, then confirm the exact model ID in the client before starting.
Sign in to the website yourself in the target Tabbit Browser environment. The agent should stop at login, CAPTCHA, or a permission prompt.
Ask for a read-only ticket checklist, then inspect each result in the page before using it.
Before setup: which part does what?
| Layer | What to verify | A pass looks like | If it fails |
|---|---|---|---|
| Model route | Provider lists baidu/cobuddy and grants your account access | A harmless request works through the chosen route | No direct Baidu endpoint is verified; confirm a third-party route and access |
| Agent client | Client supports that provider and local command/tool execution | It discovers the tabbit skill or can run Tabbit CLI | Install/discover the skill separately; model access alone is not tool access |
| Browser session | The intended website is open in the intended Tabbit profile | A permitted page shows the expected signed-in account | Sign in yourself or ask an admin to grant page access |
| Result check | Ticket number, title, status, and page link are visible | Each output row matches the page | Mark uncertain rows unverified; never infer missing fields |
This separation matters because “CoBuddy supports tools” does not mean a provider client has enabled the tools, and installing a skill does not prove the model endpoint works. Compare interfaces in browser MCP vs CLI. For the local-browser side, see the Tabbit CLI complete guide and Codex setup.
Connect CoBuddy to a local Tabbit browser
Install Tabbit Browser and set up Tabbit CLI on this computer. Tabbit CLI quick start
Check the provider route. Open your chosen provider’s model list and confirm the CoBuddy ID and whether the route is currently callable. The currently listed public route can change; this guide does not promise price, rate limits, or ongoing availability.
Check the client separately. Confirm your agent client can select the provider and has permission to execute local tools. If the client supports named skills, discover and invoke the installed
tabbitskill. Do not assume a/tabbitslash command exists in every client.Launch a separate task. Use a fresh, named task tab or group so you can keep using your other browser tabs. The first-task checklist gives a low-risk read to confirm the connection.
Reuse the intended login. Open the support queue in the Tabbit Browser environment the local CLI can reach. Confirm the account and workspace yourself. A login in a different browser, profile, machine, or remote runner is not automatically shared.
Read, then verify. Ask the agent to return only fields visible on screen. Reopen the ticket row or direct page link and confirm the ticket number and status before acting.
The local agent-browser CLI tutorial shows the difference between client instructions and CLI execution. If your client is remote, you need a separately supported local handoff. A model API call on a cloud host cannot see a browser on your laptop by itself. For a specific client boundary, see Claude Code browser permissions.
A CoBuddy prompt for a support-queue read
Use this only after the client can call CoBuddy and run local Tabbit tools. This is a draft workflow prompt, not a claim that CoBuddy natively integrates with Tabbit.
Task name: CoBuddy support queue audit
Use the installed `tabbit` skill or documented Tabbit CLI in this local agent client. First confirm the intended Tabbit Browser tab is open and shows the support workspace I am authorized to access. Do not log in, handle CAPTCHA, change permissions, or submit anything. If the page is signed out or access is unclear, stop and tell me what I need to check.
Read the visible open-ticket list only. Return a Markdown table with ticket number, visible title, visible status, and direct page URL. Include one source row per ticket. Do not infer hidden fields or search outside the visible queue. Then list any rows that could not be read and why. Save the response as a draft named “CoBuddy support queue audit” and pause for my review before any follow-up action.The expected output is a small table tied to visible ticket rows, followed by explicit gaps. It should not contain customer messages, email addresses, or data copied from unrelated pages. A support agent tab workflow is useful when your local client must reuse an existing login. If the site redirects to sign-in, stop and let the account owner refresh the session.
What to verify before trusting the ticket table
| Check | Evidence to compare | Accept when | Stop when |
|---|---|---|---|
| Account and workspace | Account switcher, workspace label, target page URL | They match the user’s authorized queue | Account or workspace differs |
| Ticket identity | Visible ticket number and title | Both match the direct ticket page | Number or title is missing or ambiguous |
| Status | Status label on list and ticket detail | Both show the same current state | Values disagree or page is still loading |
| Scope | Visible filters and result count | The requested filter is active | Queue is truncated, filtered differently, or not fully rendered |
| Action boundary | Draft name and review checkpoint | Output is saved as “CoBuddy support queue audit” for review | Client tries to update or submit tickets |
A Reddit thread about CoBuddy reported limited early use and minor wording glitches, not a benchmark or a browser test. Another commenter said it handled a long project prompt reasonably well. Those posts justify checking the actual task output; they do not prove browser reliability. See the CoBuddy discussion. For model identity and general API practice, use the provider’s current listing, not old launch descriptions.
When this workflow fits
Use it for a small support-queue read when the provider, local client, browser session, and viewer permissions all pass their checks. Do not use it to bypass role restrictions, solve a CAPTCHA, bulk-export private tickets, or make changes without a human review. The route’s availability and the site’s session state are independent; recheck both after a sign-in interruption.
If you want a reliable first run, start with one ticket you are allowed to view. Confirm that the client used the expected provider, the local Tabbit task used the right browser tab, and the draft has a review checkpoint. Then expand the queue only if the page itself gives you a complete, visible result set.
See also: connect an agent to an existing browser; browser agent first-task checklist; browser MCP vs CLI; Tabbit CLI complete guide; Codex and Tabbit CLI setup; agent-browser CLI tutorial; Claude Code browser permissions; GPT-5.5 overview.
FAQ
Is CoBuddy a browser agent?
No. CoBuddy is listed as a Baidu model, not as a browser or standalone agent client. A separate host must expose the model and run local browser tools.
Can I call CoBuddy directly through Baidu Qianfan?
I could not verify a Baidu-owned public API page for this exact model ID. Novita AI currently offers `baidu/cobuddy` through its hosted API, which is a third-party route rather than a Baidu-direct endpoint. Confirm the live route and your account access before configuring a client.
Does Tabbit pass my website login to CoBuddy?
The model does not receive your password or browser cookies through this workflow. A local agent client runs Tabbit CLI against the selected Tabbit browser session; the website login remains in that browser context.
What should CoBuddy return for a ticket check?
Ask for the visible ticket number, title, status, and page URL. Require a source row for every result and a separate list of items it could not verify.
What if the ticket page redirects to sign-in?
Stop and sign in yourself in the target Tabbit browser, then rerun a read-only check. Do not send credentials or session cookies in a prompt.
Can I use the same setup in a remote agent runner?
Only if that runner has a documented local handoff to this machine and permission to use Tabbit CLI. A cloud model endpoint by itself cannot see a local browser.