Test a 23GB Flint coding agent before routing real work

You have a workstation or a single accelerator, and a quantized coding agent is asking for a slice of your real work. The test question is whether it survives your repo, your latency tolerance, and your definition of a correct patch. A bounded local test should be small enough to run today and strict enough to catch a bad environment.

Flint, from Recursive, was released on October 21, 2026 under Apache 2.0, with 39.8 billion total parameters and about 2.5 billion active per token. The active-parameter count is why a workstation conversation is plausible. In a 128K session, Flint produced about 47 to 70 tokens per second, while Dense Qwen3.8 27B managed roughly 11 and beat it on four of six benchmarks. If your current agent is slower, a patch that arrives in seconds may change your workflow even when the accuracy is close. The speed gap is the reason a local test has to be stricter than a demo.

Memory is the first gate

Weights are only part of the footprint. The quantized route is less about raw compute and more about headroom. Context, the operating system, and your editor need room while the model runs. A machine that can load the weights may still stutter when the session grows, so the first checklist item is a memory check, not a benchmark score. The quantized route and the full-precision route are different tests, so do not compare them as if they were the same workload. A workstation run is a memory-headroom test; a BF16 run is a serving-stack test.

Run the local gate before the score

Use the list as the local gate. Each item is a quick configuration or measurement, and each one protects a different part of the verdict. Keep the notes next to the model card, because the environment is part of the result. Use the same repo for every attempt and the same timeout.

• Confirm the hardware requirements: the 4-bit build takes about 23 GB, Recursive suggests 48 GB of system memory, and the BF16 checkpoint needs about 80 GB, so a single B300 or H200 can host one replica under the bundled SGLang setup; note whether the process stays within the recommended memory.
• Record the inference stack, sampling settings, and output budget before the first prompt.
• Time a short prompt and record tokens per second, then compare that decode speed against your current agent on the same prompt.
• Set the harness to score pass@1 over at least five attempts.
• Count any solution that depends on web retrieval as a failure; Recursive's Terminal-Bench evaluation marks those solutions as failures.
• Note benchmark caveats before quoting SWE-bench numbers.

The first items protect the run, the middle items make timing comparable, and the last items make the score honest. Treat the list as a stop rule, not a scorecard. If an item fails, stop and fix the environment before judging the model. A patch that passes in a tuned sandbox may still fail in your repo.

Kernels can change the speed

Speed matters because a coding agent is only useful if you can wait for it. Recursive's Eureka Machine created kernels that made Flint generate text 55% faster on NVIDIA RTX Spark while leaving the weights unchanged. A slow first run can be a kernel problem, not a model problem, so check the serving layer before blaming the checkpoint. A kernel change can matter more than a small weight tweak.

Score repeated attempts with web retrieval as failure

Flint's reported anchors are 74.2% on SWE-bench Verified, 89.7% on SWE-bench Pro v2, and 54.9% on Terminal-Bench 2.1, with each figure averaged across a minimum of five runs. Those are useful anchors, not a substitute for your own task set. When your harness lets the model copy a solution from the web, you are testing a different product. Score the patch, not the explanation.

Keep the checklist next to your eval notes. Route work only when the environment, the speed, and the score all point the same way.