Flint can participate in a signed-in browser workflow only through a host that runs the model and can call a local browser tool. Recursive describes Flint as a local coding model; its Hugging Face card documents multi-turn tool use, but Flint itself is not a browser client. For a dashboard check, run a supported Flint runtime, connect it to a local agent host, and let that host call Tabbit CLI in a separate Tabbit Browser task tab. Keep the first pass read-only and save a named draft for review. Recursive release
Key takeaways
Recursive is Flint's publisher. The model card lists an Apache 2.0 weight license and a serving kit, but license and runtime requirements are separate questions.
Tool-call support means the model can format tool requests. It does not install a browser connector or make every request safe.
Verify the checkpoint, quantization, runtime, host tool format, local CLI access, and website sign-in as separate layers.
The model card's SGLang recipe specifies a B300 or H200 per replica for its BF16 checkpoint. Check the current official setup docs for other runtimes and quantizations.
Use a read-only dashboard diff, attach the source page to each observation, and pause before export or action.
Follow the request from Flint to the page
| Part | Responsibility | Check |
|---|---|---|
| Flint checkpoint | Generate reasoning and tool-call requests | Correct revision and license; expected chat template |
| Inference runtime | Serve the local model | Hardware, memory, quantization, runtime support |
| Agent host | Interpret tool calls and invoke local tools | Flint endpoint and tool schema are supported; shell use allowed |
| Tabbit CLI + browser | Open pages in a local Tabbit task tab | Launcher reaches the selected browser profile |
| Website | Show the account-specific dashboard | Existing sign-in works and the page is in scope |
A large context setting is a capacity ceiling, not proof of reliable recall. Recursive's model card says tool-using applications must enforce their own permissions. Start with a small, read-only request and verify both the page and the tool name before extending the workflow.
Check a local host before opening the dashboard
Recursive's announcement identifies the publisher and lists supported ecosystem options, including llama.cpp, Ollama, Unsloth, LM Studio, vLLM, SGLang, and its rec engine. The model card provides the checkpoint and an SGLang kit. It says Transformers modeling code is not included yet. The specific client you choose must still support the model endpoint and the tool-call format it emits.
| Readiness check | Evidence to capture | If it fails |
|---|---|---|
| Model server is healthy | Runtime's health response and loaded checkpoint | Stop and fix model serving before browser work |
| Agent host can use Flint | Host model picker or configured local endpoint | Choose a documented host or ask for a handoff plan |
| Tool calling is enabled | A harmless test call returns the expected tool name and arguments | Do not assume text that resembles JSON was executed |
| Tabbit CLI is reachable | CLI opens a task tab in the intended profile | Diagnose launcher and instance routing |
| Site is signed in | Target dashboard loads in that profile | Sign in yourself; never pass credentials in a prompt |
A user report in r/LocalLLaMA says Flint “falls over on agentic work” in that person's benchmark, despite doing well on single input/output prompts. Another user described bugs and inaccuracies while trying to make apps and games. Those reports vary by setup and are not controlled comparisons. They are still a good reason to keep the first run small and verify every supplied tool call.
Make a read-only dashboard change log
Install Tabbit Browser and follow the Tabbit CLI quick start. In your local agent, discover the installed tabbit skill using the host's documented mechanism. Some clients expose /tabbit; Pi uses /skill:tabbit. A client slash command only loads skill instructions. The CLI launcher must separately be able to reach the Tabbit browser instance you selected. After that, confirm the dashboard is already signed in.
The Tabbit task opens a separate tab, which leaves your regular browser available. The project fixture check verified login-session reuse for a local test page only. It did not test Flint, your inference server, or the host you use.
Use the locally served Recursive Flint checkpoint only if the selected agent host confirms it is loaded.
Use the installed Tabbit skill and Tabbit CLI from this local host to read the signed-in dashboard at:
- https://workspace.example/metrics/weekly
- https://workspace.example/metrics/previous-week
Do not click controls that change data, submit forms, or export files.
Create "Flint dashboard diff — draft 01" with one row per metric: label, current value, prior value, visible date range, source URL, and a note if the comparison is unclear.
Do not infer missing values. Separate page observations from explanations.
Show the draft and source links in the browser and stop for human review.
If a tool name is missing, the page is signed out, or values disagree, list the issue and stop rather than guessing.The expected output is a short, labeled comparison with links, followed by an “Needs human review” list. A human can reopen each source page in the task tab, confirm the date range, and decide whether the change merits follow-up. Do not let the first test update the dashboard or send a report.
Troubleshoot by layer
| Symptom | Likely layer | Safe response |
|---|---|---|
| Flint endpoint unavailable | Model runtime | Check loaded revision, memory, and serving logs |
| Agent prints a tool call but nothing happens | Agent host | Confirm supported tool schema and local invocation |
| CLI opens the wrong browser or fails to connect | Launcher / browser instance | Recheck the selected Tabbit instance and CLI setup |
| Dashboard asks you to sign in | Website session | Sign in in Tabbit yourself, then rerun the read-only task |
| Two pages show different periods | Task interpretation | Record both labels and stop; do not reconcile by guess |
| Agent proposes a write | Permission boundary | Keep it out of the first run; request human approval separately |
Where Tabbit fits
Tabbit Browser with Tabbit CLI supplies the local page step. It does not host Flint, choose the checkpoint, or make remote inference reach your desktop. Read the Tabbit CLI guide, connect-agent guide, first-task checklist, and browser MCP vs CLI guide for the connector layer. The Codex setup example, OpenClaw browser setup, and DeepSeek Harness walkthrough cover different hosts and should not be treated as Flint compatibility claims. See browser tools for agents and agentic browser security before granting page access. Install instructions are at Tabbit Browser download.
If your chosen host only runs remotely, have it draft the steps and expected fields, then hand that plan to a local host or a person. Review the actual dashboard values before sharing the change log.
FAQ
FAQ
Does Flint control a browser by itself?
No. The model card documents multi-turn tool use, but an agent host must interpret those calls and connect a browser tool such as Tabbit CLI.
What hardware does Flint need?
It depends on checkpoint and runtime. The documented BF16 SGLang kit specifies one B300 or H200 per replica; check Recursive’s current docs for other options.
Does Tabbit CLI host or run Flint?
No. Flint needs its own inference runtime and host. Tabbit CLI handles the local browser task after the host can invoke it.
Can Flint use my website login?
Only through a browser profile that is already signed in and reachable from the local host. The model does not receive cookies or credentials directly.
Can I use Flint from a remote agent?
A remote agent can prepare a plan, but it cannot reach a desktop Tabbit session unless a separately supported local handoff exists. Run the browser step locally and review it.