How to use Sakana Fugu with two signed-in websites

To compare one record across two signed-in websites with Sakana Fugu, use the fugu route from a local agent that can run Tabbit CLI. Give it the stable record ID, ask it to read the matching record on each authorized site, and request a comparison table with both source links. Keep both sites read-only and leave any mismatch in a named draft for a person to resolve.

A commenter in an early discussion of Fugu said that, for their coding work, they preferred standard Fugu to Ultra after mixed results with the slower, more expensive Ultra route. That is personal experience, not a benchmark, but it points to the right decision here: start with the baseline route for a bounded lookup and judge the actual result. Original discussion.

Key takeaways

• Sakana’s baseline API model is fugu; it is distinct from the versioned Ultra endpoints.

• A model endpoint does not carry your site login. The local client must run Tabbit CLI against the profile that is already signed in.

• Match records by a stable ID such as a ticket, order, or case number. Do not search by a person’s name if a unique ID is available.

• Ask for a read-only reconciliation table with one URL per source and an explicit “needs review” state.

• Do not let the agent update either site until a person checks both records and approves the next action.

Confirm the Fugu route and the local browser path

Sakana’s official API guide describes fugu as its everyday route and documents API access. It can route across its supported provider pool; model access and local browser access are separate decisions. Verify that the provider account actually exposes fugu. A catalog listing such as Models.dev’s Sakana directory is a useful discovery aid, but your client’s live picker is the final availability check.

Tabbit Browser gives the local agent access to pages through its CLI when the local client supports that tool. Follow the Tabbit CLI guide and connect to an existing browser profile. Do not assume the API itself can read a logged-in page or that a remote agent can reach your computer.

Use a stable ID to compare two systems

Choose a record you are authorized to inspect. A test ticket or order is safer than a customer record. Give the agent only the stable ID and the fields needed for the comparison. Ask it to use the links and visible information from the two systems, not its own guess about what the fields mean.

Do not treat two similar names as proof that records match. If a system hides the requested field, record “not visible” and link to the page. The first-task checklist covers how to keep an initial browser task small; Agent browser basics explain why read-only scope matters.

Open two task tabs and preserve the session

Before opening either site, run the installed launcher’s tabbit-cli diagnose check and confirm the local controller is running. This verifies CLI reachability; model selection, skill discovery, and each site’s login remain separate checks.

Use one Tabbit profile that is already signed in to both sites. The local agent should open a separate task tab for each destination, so the user can continue working in their existing tabs. Ask it to confirm the site and record ID in each task tab before it reads any field.

1. Open the intended Tabbit profile and verify both logins yourself.

2. Start the local Fugu-capable client and confirm fugu is selected.

3. Load the Tabbit skill using the client’s documented skills interface. Pi’s command is /skill:tabbit; some clients expose a /skills picker instead.

4. Ask Tabbit CLI to open a separate task tab for System A. Check the account name and exact record ID.

5. Repeat for System B. If either site asks for login or returns an unexpected page, stop and handle it yourself.

6. Have the agent draft a comparison. Do not grant it write actions for the first pass.

A local fixture test for the Tabbit CLI found a protected page returned 401 before a short-lived test session was set up. A second named task then read the fixture page with the session in place. That demonstrates session reuse in this test environment only; it did not call Fugu, log in to a real customer site, or verify an external model integration. To pick the browser control method, see MCP versus CLI and Codex Tabbit setup.

Request a reconciliation draft, not an update

The useful output is a compact table that makes each claim easy to check. Give the draft a name that is distinct from the source record.

Using Sakana Fugu model `fugu`, compare record ID TEST-4821 in the two authorized sites I identify. Use Tabbit CLI from this local agent and open one separate task tab per site. Read only the record with that exact ID. Create a draft called “Fugu record reconciliation” with columns: field, System A value and URL, System B value and URL, match status, and review note. Preserve exact visible wording and timestamps. If the ID is missing, duplicated, or different, stop and mark the row “needs review.” Do not edit, submit, approve, or send anything. Show me the draft before any next step.

TEST-4821 is an illustrative fixture ID, not a real record. Replace it with a value you are authorized to use. The expected draft should include direct links to both records, exact field values, and a clear mismatch marker. A short Fugu review of the table is useful, but the person who owns the workflow should check each destination before resolving a discrepancy.

This approach is intentionally narrow. A practitioner’s earlier comparison of the Fugu API logged prompt, token use, and latency separately when testing the baseline and Ultra routes. That kind of measurement can tell you whether a model choice fits a task, but it does not establish accuracy for your own records. Read the first-hand API test.

Decide whether Fugu is enough

The fugu route is a reasonable first choice for a bounded comparison when it is available and the records are easy to read. It may route work across a changing pool, so repeatability depends on the current service and task context. Use the pinned Ultra route only when the task needs a specific original release or your own trial shows the extra depth is useful.

Tabbit is useful here because both records sit behind logins already present in a local browser profile. For public pages, a search tool may be enough. For private records, the local browser route gives the agent visible page context, while a human still decides what the mismatch means. Start with one test record and a reviewable draft.

Tabbit CLI guide · existing-browser access · first browser task · MCP or CLI · web search or browser control · agentic browser basics · Codex setup · Playwright MCP setup

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.