Recursive Flint is a coding model with 39.8 billion total parameters and about 2.5 billion active per token. Ollama lists a 23 GB distribution, while Recursive’s Rec engine requires at least 48 GB unified memory on supported Macs. Those figures describe different things: download size and a documented runtime requirement.

The official model card describes text generation, reasoning and multi-turn tool use under Apache 2.0. It is a practical candidate for local coding agents, provided the selected inference engine supports the architecture and the machine has room for its weights, context state and operating system.

Choose a runtime before downloading weights

Rec’s published requirements name M4 Pro, M5 Pro and M5 Max Macs, at least 48 GB unified memory and approximately 30 GB free disk. Node.js 22 and npm are required for pi. Treat that as Rec’s supported starting point; the model name alone does not establish compatibility with every Apple Silicon computer.

The separate MLX INT4 repository uses group-64 affine INT4 for projections and experts, with INT8 embeddings. Summing its five published Safetensors files gives 22,568,912,600 bytes: 22.57 GB or 21.02 GiB. This calculation excludes auxiliary files and is not a peak-memory measurement.

Distribution / enginePublished size or requirementPlanning meaning
Ollama flint:40b23 GB listingDownload size; runtime allocations are additional.
Official MLX INT4 shards22.57 GB / 21.02 GiBCalculated tensor-file total, excluding auxiliary files.
Rec on supported Apple SiliconAt least 48 GB unified memoryDocumented engine requirement; about 30 GB free disk.
BF16 tensor index79.57 GB / 74.11 GiBUnquantized tensor storage before cache and runtime.

The BF16 tensor index totals 79,570,574,912 bytes, about 74.11 GiB, before inference allocations. The 2.5B active-parameter figure describes computation per token; it does not turn the full resident checkpoint into a 2.5B model.

Do not plan around the smallest number in the table. A download that occupies roughly 23 GB can still need substantially more system memory once loaded. Different quantizations, engines and context limits also make the formats unsuitable as interchangeable memory estimates.

Start with Ollama or the supported Rec path

The Ollama library publishes the flint:40b tag. With an Ollama build that supports Flint installed, the entry point is:

ollama run flint:40b

If the runtime rejects the architecture or model, record its version and check current support before changing hardware settings. A model being listed in the registry does not upgrade the installed executable. Start with a short prompt and confirm ordinary text generation before connecting an agent.

For Rec, follow the repository’s installation instructions, then check the machine and launch one harness:

rec doctor
rec launch pi

rec launch opencode is the documented alternative. The first launch downloads the model and harness; the server can remain running after the terminal closes. Use rec status to inspect it and rec stop to shut it down. Rec is optimized for a single session, so a successful interactive run should not be treated as evidence of multi-agent capacity.

For an existing client, rec serve exposes an OpenAI-compatible API at http://127.0.0.1:11500/v1 using model name flint. Obtain its local key through rec auth token and enter it in the client’s private provider settings. Do not assume that copying a URL also copies the runtime’s tool or reasoning conventions.

Context has a measurable memory cost

Flint’s configuration combines sliding-window and full-attention layers. vLLM’s implementation report identifies 14 full-attention layers and a 28 KiB-per-token long-context KV component with BF16 cache.

Using that published rate, 100,000 tokens × 28 KiB = approximately 2.67 GiB. At 262,144 tokens, the same component reaches 7 GiB. These calculations exclude sliding-window storage, other runtime state and workspaces. They describe that cache representation, rather than a universal overhead for Rec, Ollama or every quantization.

This is why a short-context baseline helps. Record the exact artifact, runtime version, configured context, memory consumption and whether the engine offloads work. Increase prompt length separately from concurrent sessions. Otherwise, a slowdown can be wrongly blamed on the model when the changed condition is memory pressure.

Read speed and coding scores in their stated conditions

vLLM reports roughly 485 output tokens/s for batch-one decoding at 100K context on a GB200. Its dedicated Flint image and optimized kernels matter to that result. The figure does not establish the speed of a laptop, an older GPU or an arbitrary vLLM release.

The model card reports 74.2% SWE-bench Verified and 54.9% Terminal-Bench 2.1 in Recursive’s release evaluation. Keep the named harness, sampling settings and reasoning budget with any comparison. These are publisher results, not EyesTech tests.

A useful local acceptance check is one small repository task with a recorded starting revision, requested change, tool trace and independently checked result. Count the entire elapsed time and any retries. That provides a decision about the user’s machine and workflow without turning a fast token stream into an assumed coding success rate.

Reporting note: Primary-source reporting with AI assistance. Artifact sums and memory arithmetic were checked from published metadata; EyesTech did not run Flint or benchmark local coding. Cover: original AI-generated editorial illustration.

Last Update: October 22, 2026