Laguna XS 2.1 can help an agent read support tickets and prepare a review list, but the model does not reach your signed-in browser by itself. Choose a client that can run browser tools, connect it to a currently available Laguna XS 2.1 endpoint, and use Tabbit CLI to work in Tabbit Browser. The task below reads visible ticket IDs and links, returns a verification table, and stops before any reply or status change.
The first public discussion was cautious too: u/a_slay_nub wrote, “Doesn't seem to be at Qwen 3.6 on benchmarks.” (original Reddit thread) That is one user's reaction, not an independent evaluation. This matters because “open weights” and “available as an API” are separate claims. Poolside publishes weights and local serving instructions for Laguna XS 2.1. Its hosted routes can change; confirm the provider's current listing before configuring a live workflow. For this article, Laguna XS 2.1 means the specific poolside/Laguna-XS-2.1 model, not Laguna XS.2 or the larger Laguna S 2.1.
Key takeaways
Laguna XS 2.1 is a 33B total / 3B active model. Laguna S 2.1 is a separate 118B / 8B model.
Poolside lists local runtimes including Ollama, vLLM, SGLang, Transformers, and llama.cpp. Tool calling depends on the runtime version and client.
The OpenRouter model listing said it would go away on October 31, 2026; as of this research, its ID was absent from the current public model catalog API. Check again before using it.
Tabbit CLI connects a compatible local agent to the signed-in Tabbit Browser environment. It does not host the model or grant a remote runner access to your session.
For support work, ask the agent to collect ticket IDs and public URLs, then verify them in the visible page before you hand off or act.
The support-ticket workflow at a glance
| Step | Agent does | You verify |
|---|---|---|
| 1. Choose model route | Uses poolside/Laguna-XS-2.1 through a local runtime or a currently available hosted endpoint | Exact model ID, terms, endpoint status, tool-call format |
| 2. Open authenticated queue | Navigates through the connected Tabbit Browser tab | You are signed into the intended support account and queue |
| 3. Read tickets | Extracts only visible ticket IDs, titles, dates, and URLs you requested | No hidden content, unrelated customer data, or inferred fields |
| 4. Build review table | Groups rows and flags missing links or duplicate IDs | Each ID and URL matches the page |
| 5. Stop for review | Leaves the queue unchanged | No reply, assignment, status change, or send action occurred |
Verify the exact model and route first
Poolside's Laguna XS 2.1 release post dates the release to July 2, 2026. It describes a 33B Mixture-of-Experts model with 3B active parameters, lists OpenMDW-1.1, and names local runtimes and provider routes. Its Hugging Face model card includes runtime instructions, tool-call notes, and the model license. The card shows that the XS weights are not deployed by Hugging Face Inference Providers. Do not infer hosted availability from the card's presence alone.
Poolside's release post linked its API and OpenRouter. However, the OpenRouter page now says the model was scheduled to go away on October 31, 2026, and a check of the public model catalog on November 10 did not return poolside/laguna-xs-2.1. Treat that route as unavailable until its current endpoint confirms otherwise. Poolside API status should also be checked directly. For a predictable setup, follow the current local runtime instructions.
The name matters. Laguna XS.2 is the earlier April model. Laguna S 2.1 is the larger model. The Laguna S 2.1 card lists 118B total and 8B active parameters. Do not apply its deployment sizing, client settings, or hosted provider entry to XS 2.1.
Check tool calls at both ends
A model may support function calls while a client or server mishandles their format. Poolside's card documents vLLM support from version 0.21.0 and calls out a parser fix for poolside_v1; on an older build it recommends a different parser option. Follow the exact current runtime instructions rather than copying a configuration from Laguna S 2.1.
Before opening a real ticket queue, run a harmless test with the same endpoint and client. Ask the model to return a fixed tool call with a dummy ticket ID, and check the client log to confirm the tool name and arguments arrive as structured data. The endpoint accepting chat text is not enough. The agent client must execute a browser tool, and Tabbit CLI must attach it to the intended Tabbit Browser task tab.
Connect the agent to the signed-in queue
Use a local agent client that lets you select Laguna XS 2.1 and supports local browser tools. Install Tabbit Browser and Tabbit CLI, then follow the agent connection setup. Client skill discovery is its own step. Depending on the client, the Tabbit skill may be available as /tabbit, /skills, or a configured skill. Pi uses /skill:tabbit.
Finding a skill only loads instructions. It does not confirm the CLI launcher is installed, the model endpoint responds, or the support site is signed in. Check all three independently. Sign in to the support site in the Tabbit Browser environment the CLI will connect to. The agent can then use that same environment, while its task tab stays separate from the tabs you use to keep working. A cloud runner elsewhere does not inherit the login; it needs a supported local handoff.
Use a read-only ticket prompt
Start with a queue and tickets you are permitted to inspect. For the first run, use a staging workspace or a test ticket. Ask only for fields visible on the page. Keep replies, assignments, status changes, and customer messages out of scope.
In the current Tabbit Browser task tab, open the signed-in support queue.
Read only the visible tickets assigned to the test queue for today.
For each ticket, copy its visible ticket ID, title, date, and public URL.
Do not open attachments, reveal hidden fields, reply, assign, or change status.
If an ID or URL is missing or unclear, mark it for review instead of guessing.
Return a table with: ticket ID, title, date, URL, and verification note.
Stop without changing any ticket and leave the queue open for my review.This is a test workflow template, not a verified connection to a real support system. Replace “test queue” with a queue you are authorized to access. Do not paste private ticket text into an unrelated provider. The expected output is a five-column table and a stopped browser page, not a sent reply.
Review each row before handoff
| Check | Pass condition | If it fails |
|---|---|---|
| Ticket ID | Exact visible ID, unique in the table | Reopen the row and copy it; do not merge similar IDs |
| URL | Opens the same ticket in the signed-in queue | Mark for review; do not substitute a search result URL |
| Title and date | Match the current visible page | Refresh the row and note if the page changed |
| Scope | Only requested tickets and fields appear | Remove unrelated fields and rerun on a smaller set |
| Actions | No reply, assignment, or status change | Stop and inspect the event history before continuing |
Give the handoff a clear name, such as Support queue / daily triage / review. Leave the Tabbit task tab at the queue and keep the review table beside it. Confirm IDs and links manually before copying the table into a ticketing note or taking any action. A first browser-agent checklist gives a broader preflight.
If the run loops or returns malformed output
Do not keep retrying against the live queue. First reproduce the issue with one dummy ticket. Check the endpoint model ID, tool parser and client logs. Then reduce the page to one record and ask for one structured row. In the same Reddit thread, u/spyingwind said it “actually completes tasks and uses tools correctly” for coding, but may try command-line deletion when stuck. That feedback concerns a coding setup, not support browsing, but it is a good reason to keep the allowed actions narrow and the browser visible.
If the model returns prose instead of a structured tool call, confirm the endpoint is actually serving XS 2.1 and that the runtime parser version matches the model card. The MCP vs CLI comparison can help choose a browser connection method; the complete Tabbit CLI guide covers the launcher and session connection.
Related setup guides
For the client-specific path, see Codex and Tabbit CLI. If you need a spreadsheet handoff, use the guide to move browser data into CSV; if a control does not respond, check browser-agent click failures. Keep page context small with these token-use practices.
Decide based on your constraints
| Your constraint | Use this route | Boundary |
|---|---|---|
| Need local inference and control over data flow | Download official XS 2.1 weights and use a listed local runtime | Size, hardware, and runtime setup are your responsibility |
| Need a hosted endpoint | Check Poolside's live API status and terms before configuring the client | Do not rely on an expired or stale provider listing |
| Already run Laguna S 2.1 | Configure XS 2.1 by its own model ID and card | S 2.1 is larger and has a different deployment profile |
| Need to update customer tickets | Let the model prepare a review table, then stop | A person verifies and performs the write action |
Laguna XS 2.1 can be one part of a browser workflow when a compatible local agent client and model route are available. Tabbit Browser supplies the signed-in environment; Tabbit CLI connects the local agent. Keep the queue visible, review the ticket IDs and links, and hand off a named draft before any customer-facing change.
FAQ
Can Laguna XS 2.1 access a signed-in browser by itself?
No. The model needs an agent client that can call browser tools. The client, model endpoint, Tabbit CLI connection, and website login are separate parts of the setup.
Is Laguna XS 2.1 the same as Laguna S 2.1?
No. XS 2.1 is a 33B total, 3B active model. S 2.1 is a larger 118B total, 8B active model. Their deployment requirements and available providers differ.
Where can I run Laguna XS 2.1?
Poolside documents local use with Ollama, vLLM, SGLang, Transformers, and llama.cpp, and its launch post lists its API and OpenRouter. Check current hosted availability before relying on a provider.
Does Laguna XS 2.1 support tool calls?
Poolside documents tool calling and publishes runtime-specific guidance. For local vLLM, follow the model card's version and parser notes; the agent client must also support the tool format.
How do I stop the agent from changing support tickets?
Ask it to produce a review table and stop before updating or replying. Keep the ticket page visible and do not grant write actions for the first run.
Will Tabbit CLI reuse the site's login?
It can use the signed-in Tabbit Browser environment to which it is connected. A remote agent running elsewhere does not automatically inherit that browser session.