To draft a team document from signed-in workspace pages with Solar Pro 4, connect the model through Upstage's API to a compatible local agent, then use Tabbit CLI to read the pages in Tabbit Browser. The API provides the model route; Tabbit provides access to the browser session. Keep the task read-only until the agent has recorded source URLs and a named document draft for a person to check. Upstage API setup · Tabbit CLI quick start
In a Reddit thread about Solar Pro 4 in Cline, one commenter said it worked well with a few bugs; another challenged the comparison benchmarks as outdated. These are individual comments, not API or browser evidence. They are a useful reminder to keep source URLs beside claims and verify the current pages yourself. Original thread
Verify the model route and local tool separately
| Layer | What to verify | Evidence you need |
|---|---|---|
| Provider | Use Upstage's documented API base URL and solar-pro4 model ID | A harmless API request succeeds in your own account |
| Agent client | It supports the Upstage route and can run a local browser skill | A tool call reaches a local test page |
| Tabbit CLI | The installed launcher can reach your intended Tabbit Browser | The agent returns a visible heading from a page you opened |
| Workspace | You signed into the correct team account and can read the source pages | The account and page titles match your manual check |
Upstage documents solar-pro4 and solar-pro4-260806 for its Chat API, and describes OpenAI-compatible API setup at https://api.upstage.ai/v1. Its tool-calling documentation supports function tools, but this does not prove that a particular third-party agent client exposes them or can call Tabbit. Check the client and account independently. The Responses API is stateless and text-only, so verify how your client carries conversation context and whether that endpoint fits the task.
Build a source list before drafting
In Tabbit Browser, open the workspace and source pages yourself. Sign in with the account that has permission to read them. Then use the local agent's actual skill discovery method. Pi documents /skill:tabbit; other clients may use /skills or automatic skill loading. Verify the installed tabbit-cli launcher separately. Skill discovery, local launcher reachability, and site login are not interchangeable checks.
Give the agent a narrow output contract. It should record each page URL, visible title, date or version label, and a short claim supported by that page. Ask it to mark missing dates and inaccessible pages as unknown, not to fill them from memory. Open a separate task tab so you can keep working in the source workspace. The existing browser connection guide explains how that browser session is selected; the first task checklist covers a safe initial read.
Draft the shared document without publishing
After checking the source list, ask the agent to create a named draft in the intended workspace. Use only sources the agent actually opened. Keep claims and citations paired so a reviewer can check each paragraph. Leave the document unpublished and avoid pasting private content that the requested summary does not need.
Use the installed Tabbit skill from this local agent. In a new task tab, inspect only the team pages I have already opened and can access. For each page, record its URL, visible title, date/version label, and one claim relevant to the release handoff. Do not edit the source pages or follow unrelated links. Mark unavailable details as unknown.
Create a draft named "Solar Pro 4 release handoff — GEO-085" in the selected shared workspace. Include a short summary, a source table with one row per page, and open questions. Keep every claim next to its source URL. Do not send, publish, or change permissions. Show me the draft for review.
Expected output: draft link, workspace name, source URLs, and any unknown or inaccessible fields.GEO-085 is an illustrative draft name, not a real workspace record. Check the draft's workspace, source links, and account before saving. A model-generated citation is not evidence until the linked page opens and supports the claim.
Choose the next step by the visible result
| Result | Next action |
|---|---|
| All expected source pages are visible | Compare each claim with its linked page, then review the named draft |
| A page asks for login or shows the wrong workspace | Stop and sign in yourself in the correct Tabbit profile |
| A date or version is missing | Mark it unknown and ask a person to confirm it |
| API call works but no local tool runs | Check skill discovery and launcher reachability in the local client |
| Agent runs remotely without local handoff | Use a local client or prepare a manual source checklist |
For connection details, read the Tabbit CLI complete guide, MCP vs CLI comparison, and Codex Tabbit CLI setup. For client selection and safe browser use, see the browser agent setup guide, browser automation overview, the Codex browser vs Tabbit CLI guide, and browser agent security notes. These cover the browser handoff; they do not claim a Solar Pro 4 client integration has been tested.
FAQ
Can Solar Pro 4 access my signed-in browser directly?
No. Solar Pro 4 is an API model. A compatible local agent must run the model and call a local browser tool such as Tabbit CLI. The API route does not provide your browser session.
Which Solar Pro 4 model ID should I use?
Upstage documents `solar-pro4` and the snapshot `solar-pro4-260806`. Confirm that your account and client can use the selected API route before configuring the browser workflow.
Can the agent edit a shared document automatically?
It can only use actions exposed by the local agent and browser setup. For a first run, ask it to collect visible sources and prepare a named draft, then have a person verify citations, workspace, and permissions before saving.
Does the shared browser task keep my login?
Tabbit CLI can work in the selected Tabbit Browser environment where you signed in, subject to site access. Keep credentials in the browser and stop if the page asks the task to authenticate.
What if my agent client runs remotely?
A remote runner cannot reach your local Tabbit session unless that client has a supported local handoff. Use a compatible local agent or prepare a checklist for a person to run locally.