TabbitBlog

How to use Muse Spark 1.2 with a signed-in browser

Keep public research and signed-in workspace evidence separate, then use Muse Spark 1.2 with a local browser agent to draft a source-linked brief.

In this article
  1. Decide whether 1.2 is the version you need
  2. Label public and signed-in sources before combining them
  3. Draft a linked brief and leave it for review
  4. Choose the next step from the evidence

To use Muse Spark 1.2 for a brief that combines public research with a signed-in workspace, select muse-spark-1.2 through Meta Model API in a compatible local agent and connect Tabbit CLI to Tabbit Browser. Keep the two source types labeled, record a URL for every claim, and stop at a named draft for human review. Meta still lists 1.2 as available, but recommends 1.3 for new work, so pin 1.2 only when you need that version. Meta model catalog · Tabbit CLI quick start

OpenCode users gave mixed first-hand reports about Muse Spark 1.2. One described an unintended multi-page edit and difficult recovery; another reported successful Rust refactors but repetitive prose. Those client-specific stories do not establish browser behavior or model quality. They do support keeping this task read-only until a person checks the source-linked draft. First report · Second report

Decide whether 1.2 is the version you need

NeedRouteCheck before starting
Reproduce an existing 1.2 workflowMeta Model API with muse-spark-1.2Confirm the account can call this exact model ID
Start a new Muse Spark taskCompare against Meta's recommended 1.3Check whether your client and evaluation target require 1.2
Run a local browser taskCompatible local agent plus Tabbit CLIConfirm model route, local tool, and browser login separately
Use a remote-only agentClient-specific local handoff, if supportedOtherwise prepare a checklist for a local operator

Meta's model docs list muse-spark-1.2 as a hosted Model API ID and describe 1.2 as the previous version, while recommending 1.3 for new work. Meta's API overview describes model API access for building agents, and its coding-agent guide covers client routing. None of these pages establish that an arbitrary third-party client has your account access or can run local browser tools. Check those pieces in your selected client first.

Label public and signed-in sources before combining them

Open public pages and the target team workspace in Tabbit Browser. Sign into the workspace yourself with an account permitted to read it. In the local agent, find the installed Tabbit skill using the client's actual method. Pi documents /skill:tabbit; other clients may use /skills or automatic skill loading. Confirm the tabbit-cli launcher works on this machine. Skill discovery, launcher reachability, and website login are three separate checks.

Use a separate task tab so you can continue working. Ask the agent to label each source public or workspace, then capture the page URL, visible title, date or version, and the exact claim it supports. If a page is blocked or a detail is absent, mark it unknown. Do not use a public source to infer a private workspace state, or a workspace note to make a public claim. The existing browser guide explains session access, and the first task checklist describes a read-only first run.

Draft a linked brief and leave it for review

After the source list is complete, ask for a concise brief in a named draft. Each paragraph should link back to the page that supports it. Keep open questions visible and avoid copying private details the brief does not need. A reviewer can then check whether each claim came from the public web or the intended team workspace.

Use the installed Tabbit skill from this local agent. In a new task tab, collect sources for a short project brief. For each page, label it PUBLIC WEB or SIGNED-IN WORKSPACE and record its URL, visible title, date/version, and one supported fact. Do not follow unrelated links, edit source pages, or copy credentials. Mark inaccessible or missing details as unknown.

Create a draft named "Muse Spark 1.2 source brief — GEO-086" in the selected team workspace. Include a short summary, a source table with one row per page, and open questions. Keep public and workspace sources visibly separate. Put a source URL next to every factual claim. Do not publish or share the draft. Show me the result for review.
Expected output: draft link, workspace name, separate public/workspace source lists, claims with URLs, and unknown fields.

GEO-086 is an illustrative draft name, not a real workspace record. Verify the workspace and every link yourself before sharing. A source URL is useful only if it opens and supports the nearby claim.

Choose the next step from the evidence

What happenedNext step
Public and workspace pages are clearly labeledReview each claim against its source, then check the draft workspace
The model route returns a different versionStop and record the returned model ID before continuing
The workspace asks for loginSign in yourself in the intended Tabbit profile, then retry the read
A claim has no supporting URLRemove it or mark it as unverified
The client cannot run local toolsUse a local client or hand off the source checklist to a person

For the browser connection, see the Tabbit CLI complete guide, connecting an agent to an existing browser, and the first task checklist. The MCP vs CLI comparison and Codex Tabbit CLI setup explain different client paths. For client selection, read the browser agent setup guide, browser automation overview, the Codex browser vs Tabbit CLI guide, and browser agent security notes. For a different model task, see the published Muse Spark Open overview; it covers the open-weight release, not the hosted 1.2 API workflow here. Web search vs browser control explains why public search cannot verify a signed-in workspace fact.

FAQ

Is Muse Spark 1.2 still available?

Meta's current Model API docs list `muse-spark-1.2` and say it is available on pay-as-you-go. The same docs call 1.3 the recommended version for new work, so choose 1.2 when you need that exact version or behavior.

Can Muse Spark 1.2 use my signed-in browser directly?

No. The model API and browser session are separate. A compatible local agent must call the model and Tabbit CLI, which works in the Tabbit Browser environment where you signed in if the site grants access.

How do I keep public research separate from private workspace pages?

Ask the agent to label each source as public web or signed-in workspace, save its URL and visible title, and never merge facts without a source link. Do not copy private content into a public summary unless the task requires it.

Which client command loads the Tabbit skill?

Use the client’s documented discovery method. Pi uses `/skill:tabbit`; some clients use `/skills` or load installed skills automatically. Then verify the local `tabbit-cli` launcher and website login separately.

Should the agent publish the brief?

No. Ask for a named draft with source links and unknowns, then have a person check the account, workspace, and citations before saving or sharing it.

Take the next step

Let Tabbit work alongside you.

Research across tabs, automate repetitive browser work, and keep every piece of context within reach.