I run Recursive’s Flint on a DGX Spark, drive it from Windows with Pi Coding Agent, and attach TypeSafe’s Jev browser loop through pi-jev-browser
. Free section: what Flint is, why I put it on Spark beside Qwen without co-loading both, why Pi is the harness, and which browser agents I considered before testing Jev. Paid section: the exact Windows→tunnel→Flint→jev_run
procedure, the two Windows patches that unblocked Chromium, and screenshots from the verified Ada Lovelace and Bing News runs.
Flint on DGX Spark— MoE coding model, headline SWE-bench Pro v2 score, Spark token speed, and why it never co-resides with Qwen.Pi Coding Agent— minimal harness, custom OpenAI-compatible providers, Windows client to local Flint.Browser agent options—agent-browser
, computer-use, and Jev; why I tested Jev for isolated web goals.Paid how-to— swap kit, Pi config, TypeSafe/OpenRouter key, Windows path/sandbox patches, measured runs with screenshots.
Recursive Flint is a coding-oriented mixture-of-experts model: about 39.8B total parameters with roughly 2.5B active per token (the rounded “40B-A2.5B” designation). It is built for agentic coding on local hardware: investigate a repo, call tools, fix bugs, write tests. Recursive’s release card reports 89.7% on SWE-bench Pro v2, 74.2% on SWE-bench Verified, and 54.9% on Terminal-Bench 2.1 (mini-swe-agent / Terminus 2, average pass@1 over at least five attempts). Those numbers put Flint in the same local coding conversation as dense models in the Qwen3.8 / 25–40B class that Recursive markets it against, while the MoE active path stays much smaller than a full dense forward.
Against the peer MoE Qwen3.6-35B-A3B comparison Recursive publishes, Flint leads on the agentic and instruction-following rows that matter for tool-using coding: Terminal-Bench 2.1 54.9% vs 44.9%, SWE-bench Pro v2 89.7% vs 73.8%, IFBench 89.2% vs 67.9%, IFEval 95.1% vs 89.6%, with LiveCodeBench v6 essentially tied (80.3% vs 80.4%). That is the reasoning and agent-coding edge I care about on Spark: better multi-step tool discipline than the Qwen3.6 MoE I already had resident, without paying dense-model decode cost.
Speed is the other half of the decision. Recursive reports more than 150 tokens/second on a 64GB NVIDIA RTX / DGX Spark class box at short contexts with its optimized engine, and more than 100 tok/s still holding around a 120k-token context in their published Spark figures. Dense 25–40B models that match coding quality on some rows decode far slower on the same memory bandwidth. On a Spark, that tok/s gap is the difference between an interactive Pi tool loop and a stalled session.
I already run a Qwen MoE on the same Spark. Dual-resident is not an option: the live Qwen container holds most of the unified memory, and Flint’s weights plus KV cache need headroom for long context. The flint-swap kit on the box therefore hard-refuses co-residence: stop Qwen before start Flint (or the reverse), wait for MemAvailable
, serve only one engine on port 8888. That leaves memory for KV cache and a usable context window instead of two half-starved models fighting UMA. Daily use is a bakeoff swap, not a simultaneous load.
Pi Coding Agent is a minimal terminal harness: tools, sessions, packages, and a models.json
provider map. It does not force a cloud vendor. You point an OpenAI-compatible baseUrl
at whatever serves completions. That is the right shape for a Spark tunnel: Flint answers on http://127.0.0.1:8888/v1
after SSH port-forward from Windows; Pi’s spark
/ flint
entry talks to that endpoint; the same Pi session can load browser packages.
I use Pi on Windows because the editor and browser work stay on the laptop, while the heavy model stays on Spark. Install is a one-liner (irm https://pi.dev/install.ps1 | iex
or npm). Provider config is a JSON file under ~/.pi/agent/
. Mid-session /model
switches are cheap. Package install (pi install npm:…
) pulls extensions into the agent tree without rewriting the harness. For local Flint that means: keep ssh spark
tunnel up, confirm /v1/models
lists flint
, launch pi --provider spark --model flint
, and let Flint select tools.
Pi is also where browser automation attaches. The coding model (Flint) chooses when to call a browser tool. A separate decision path (Jev, or the Pi model itself under another policy) chooses which page action to take. That split matters: you do not want a 40B coding MoE burning tokens on every click candidate if a System One classifier can answer a structured multiple-choice observation cheaper.
Three surfaces showed up in the same “browser agent” ask on this host:
agent-browser / pi-agent-browser— Playwright CLI attach or open. Good when you need a real profile, extensions, or an already-logged session. Prior Pi runs hit Windows path ENOENTs under Git Bash/tmp
and “do not open a new window” constraints when the goal assumed one shared Chrome.@injaneity/pi-computer-use— host desktop computer use. Correct for the active OS window, wrong for an isolated web decision loop with recorded steps.pi-jev-browser (Jev / TypeSafe System One)— isolated Chromium, structured DOM observations, one multiple-choice action per step. Jev does not consume screenshots on the decision path. Docs live onpi.devand the package README. You need a TypeSafe or OpenRouter API key for thetypesafe
policy; the defaultpi
policy can answer from the session model with no second key.
I tested Jev because the goal was a bounded public-page loop with status codes (done_unverified
, blocked
, needs_review
), step video/screenshots for verification, and no requirement to inherit daily Chrome Google login. Isolated profile is a feature for smoke tests and news retrieval; it is a limitation for Gmail. On this Windows host the Ada Lovelace Wikipedia goal returned done_unverified
/ model_done
in 4 steps and 3680 ms at https://en.wikipedia.org/wiki/Ada_Lovelace
. That is the clean proof the stack works. News sites that interpose robot gates return model_blocked
by design.
The rest of this post is the operator path: Spark swap, Pi on Windows, Windows Playwright patches, jev_run
prompts, and the screenshots from those runs.
Figure 1 is the control path after the Spark tunnel answers: Windows Pi prompts Flint; Flint selects jev_run
; Jev returns one action from a structured page observation; Playwright mutates isolated Chromium; Pi verifies from returned title, URL, and page text.
Figure 1: Pi Flint Jev control path
Figure 2 is the surface choice before the first tool call: isolated public web goals go to jev_run
; host UI goals go to computer-use; profile-bound work stays on agent-browser
.
