Flint Ships a Model, an Engine and Several Different Speed Claims

Flint's most useful promise is not that every developer can replace a hosted coding model with a laptop. It is that an open model, a specialized inference engine and an existing agent harness can be evaluated as a working system. Recursive's October 21 launch, independently reported by TechCrunch, gives builders several ways to try that proposition. The catch is that those ways have different hardware requirements, performance measurements and operational responsibilities. Treating them as one product with one speed number would obscure the deployment decision.

Recursive says a small team of humans and agents developed Flint in under four months, with its Eureka system contributing to research. The company also describes specialized kernels and quantization work behind the release. These are claims about how the model was produced, not evidence that an autonomous research loop can keep improving itself indefinitely. A buyer does not need to settle that larger ambition to evaluate the artifact now available. The useful questions concern what it can run, what it can finish and what the operator must supply.

The model card lists 39.8 billion total parameters and approximately 2.5 billion active parameters, including the output head. Its sparse design limits the parameters involved in each step; it does not make the full checkpoint a 2.5-billion-parameter download. Of 49 layers, 35 use a 513-token sliding attention window and 14 use full attention. That mixture matters because the implementation must handle both recent local context and longer-range attention. It is a particular architecture to serve, not a generic promise that every runtime will behave identically.

Context length already illustrates the need to read the artifacts separately. The launch page claims a maximum of 512,000 tokens while recommending 256,000 for best results. The model card documents 262,144 tokens shared between prompt and output. Ollama lists a 256K context. Builders should use the supported limit of their chosen checkpoint and runtime, leaving room for generation, rather than treating the largest launch-page figure as a universal setting. This edition has not independently tested the model's accuracy or speed at any of those lengths.

The Mac route is unusually specific. The rec engine documents support for M4 Pro, M5 Pro and M5 Max machines with at least 48GB of unified memory and roughly 30GB of disk space. It is optimized for a single session. That makes it a candidate for an individual developer's workstation, but those requirements are not a claim of compatibility with every recent laptop. Before comparing local inference with an API bill, establish whether the machine already on the desk is actually one of the supported configurations.

Even on that route, the comparison needs its footnotes. The rec repository reports 1.4 to 2.6 times llama.cpp's token throughput on an M4 Pro with 48GB of memory, using four-bit models. The test spans prompts from 1K to 252K tokens, generates 1,024 tokens and averages five runs at each context length. Prompt processing is excluded. This is a useful comparison of generation under stated conditions. It is not a measurement of the time required to inspect a repository, modify files, run tests and deliver an acceptable patch.

Recursive separately advertises more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 on a 64GB RTX Spark at short contexts. Those numbers should remain attached to their stated conditions. They cannot be combined with a long-context result from another machine to imply that one setup achieves both. For a team building an internal evaluation, the practical lesson is to preserve the workload alongside the speed measurement, including prompt length, output length and the number of simultaneous requests.

The GPU-server result answers a different question. A vLLM engineering report, coauthored by Inferact and Recursive, describes approximately 485 tokens per second during batch-one decoding at a 100K context on one GB200. It reports reducing the kernel count from 1,096 to 346. Its specialized path targets a single Blackwell GPU, tensor parallelism of one and a BF16 cache, with fallback behavior outside those conditions. That is a carefully bounded implementation result from the organizations involved, not an independent replication or a throughput promise for an arbitrary GPU server.

Kernel-level work is significant because a model's theoretical arithmetic is not the whole execution path. The vLLM report makes the serving implementation part of the performance claim. The operational implication is to retain the runtime build and configuration with any benchmark result. If a proposed deployment uses a different precision, device layout or serving path, ask for a measurement of that configuration. Portability of weights is valuable, but it should not be confused with portability of a particular optimization or its measured benefit.

The SGLang serving kit makes the distinction even harder to miss. Its documented setup requires one GPU with at least 141GB of memory per replica; 80GB devices are not supported. B300 and H200 are the validated devices. The download and image requirements are roughly 80GB for weights and 50GB for the container image. Multiple replicas are independent, while several alternative parallelism and quantization arrangements remain unvalidated. These are requirements for that serving package, not a contradiction of the separately documented quantized Mac route.

Ollama's listing, by contrast, shows a 23GB model with thinking and tool support. File size is not a complete memory budget for a running workload. Nor does a lower download size establish equivalent performance to a different serving package. A selection process should name the exact artifact first, then measure the resources needed for the intended context and concurrency. Otherwise, a comparison can accidentally pair one route's convenient download with another route's performance and a third route's hardware assumptions.

Quality measurements deserve the same discipline. Ollama reproduces publisher-reported scores of 54.9 on Terminal-Bench 2.1, 89.7 on SWE-bench Pro V2 and 74.2 on SWE-bench Verified. These are separate evaluations, not percentages that should be averaged into a general reliability score. They provide leads for testing, not a substitute for it. A builder whose work involves an unfamiliar repository, particular test infrastructure or strict change constraints should check those conditions directly before treating a public benchmark result as a purchasing decision.

The agent harness is the next boundary. OpenHands says it tested Flint as a launch partner and supports local and hosted ways to use it. That endorsement is useful integration information, but it is not an independent reproduction of every performance claim. Inference supplies model responses; the harness supplies the surrounding workflow and execution environment. A local model can therefore participate in an established coding workflow without making the workflow's tool configuration, permissions or acceptance criteria disappear.

Recursive's getting-started guidance suggests beginning with a small, familiar repository: ask for a function explanation, a focused test, a fix and a review. That is a sensible starting sequence because the developer already has a basis for judging the result. Our recommendation is to retain the original task, generated diff, test output and review decision. A fluent explanation can be useful without establishing that a later edit is correct. Progress through the sequence should depend on evidence from the repository, not on the apparent confidence of the response.

Generation settings add another source of avoidable differences. Recursive recommends temperature 1, top_p 0.95 and top_k 20. Its documentation notes that top_k is an extension rather than a standard field in the OpenAI-compatible chat interface. It also stresses matching the chat template and tool parser to the model. An endpoint accepting a familiar request shape is therefore not sufficient proof that every setting has the same meaning or effect. Record what the endpoint actually supports before attributing a failed run to model quality.

Reasoning and output budgets also need explicit handling. The generation guide warns that length termination can leave an incomplete answer, and tool schemas and results consume context. An evaluation should distinguish an incorrect completed answer from a run cut off by its configured limit. Increasing a limit may be appropriate within the supported context, but it changes the workload and potentially the waiting time. Report that change instead of quietly giving one configuration more room and comparing the resulting score as though nothing changed.

Local inference is not, by itself, a containment policy. The SGLang kit warns that its server can listen without authentication and calls for restricted access or an API key. It also documents parser edge cases. These details argue for testing the serving boundary and tool behavior, not merely confirming that a chat response appears. Our recommendation is to use narrowly scoped credentials, restricted execution environments and explicit review of changes. Model output should not acquire authority simply because the model generating it runs on hardware the organization owns.

The route to the model changes the data path as well. Recursive's release resources list hosted alternatives while limiting its direct API to selected partners. OpenHands also describes local and hosted use. A team choosing a hosted endpoint should review that provider's terms and handling of submitted material. A team choosing local inference should inspect the harness's other network activity and tools. These are separate checks: controlling where inference occurs does not automatically answer where every repository fragment, tool result or diagnostic may travel.

The economics should be measured around accepted work. For a representative set of tasks, record prompt processing, generation, tool execution, tests, retries and review time. Keep hardware acquisition, power and setup effort separate from recurring provider charges. These are proposed evaluation categories, not measured costs for Flint. A fast local run that needs substantial repair may be less useful than a slower alternative that meets the task's constraints. Equally, an existing supported workstation may make local experimentation attractive even before a broader fleet decision is justified.

Flint's Apache 2.0 weights give builders an artifact they can inspect and deploy through several documented routes. The release does not collapse those routes into one operational model. The strongest next step is a bounded trial with a named checkpoint, runtime, harness and task set, followed by a review of accepted results and actual resource use. That makes the decision falsifiable. If the complete system improves the team's work, adopt it on that evidence. The launch's ambition and its fastest decoding number do not have to carry the entire argument.

LaunchPad positionChoose the checkpoint, runtime and harness together. Compare accepted coding tasks under recorded hardware, context and permission settings, not isolated decoding speeds.