Field card: LFM2.5-2.6B

What it is

LFM2.5-2.6B is a small text model from Liquid AI, built to run on your own hardware. As of 2026-08-04 it is the newest member of the LFM2.5 family. Liquid's card presents it as a model for using software tools, extracting data, and answering questions from documents supplied alongside the question, with long inputs. The card also states what it is not recommended for, in its own words: agentic coding and knowledge-heavy tasks.

The table was read from the pinned model card and configuration file on 2026-08-04. Rows that say "per the card" or "as stated" have only the card behind them; the license's full name is from Liquid's own documentation.

How new it is

The main repository was created on 2026-07-28 and its content went public in the days after: the GGUF repository on 2026-08-01, the MLX repository on 2026-08-03, and the main repository's single visible commit is dated 2026-08-04 (we saved the repository's commit listing as evidence). The release is days old. That is read from repository creation dates, which a documentation edit does not change. When checked on 2026-08-04, Hugging Face displayed about 47,000 downloads for the main repository; that is the platform's reported counter, not a count of distinct users.

One caution about what those dates mean: they date the release, not the training. The configuration file records a library version (transformers 5.2.0), but that metadata does not establish when training ended or when the weights were produced, so these notes make no claim about a training date.

The chat template preserves earlier tool calls

A sentence of background first. When a model works through a multi-step task with tools, it needs to be shown which tools it has already asked to use. The chat template is the piece of plumbing that prepares that conversation history for the model's next turn. In pinned versions of three older Liquid models we studied, the shipped template left the model's earlier tool calls out of that history, and in our recorded runs multi-step tasks broke down on exactly those routes. We measured it, built a compatibility kit around it, and submitted template changes upstream for all three on 2026-08-03: the pull requests are public (1.2B-Instruct, 24B, 1.2B-Thinking). On 2026-08-05 the maintainers merged their own template fix in all three repositories. We re-rendered our recorded failure cases against the updated templates and they pass: earlier tool calls now render on all three. That fix supersedes our pull requests, and it is the right ending: the defect is fixed at the source. Copies downloaded before the fix still carry the old template. The linked Droplet page is a snapshot from before that merge.

LFM2.5-2.6B's template includes earlier tool calls when it prepares that history. That is the behavior we were checking for, and we verified it two ways: by reading the pinned template text, and on a live serving route once we had the model running (section 08).

Liquid's card says the model reasons before answering. Consistent with that design, the pinned template begins each new assistant turn with a <think> tag. We also measured what a user actually receives when the model is served through a standard chat interface: in the 90 recorded runs of our standard test battery (90 scripted requests sent over the same interface a chat app would use; section 08 describes it) the reasoning arrived separated in its own field, and it never leaked into the answer text. That reasoning habit has a practical cost, and section 06 maps it.

The context window, measured

The model card states a context window of 131,072 tokens. The configuration file in the same pinned repository states 128,000. On our serving route, the runtime settles the disagreement itself. Asked to open a 131,072-token window, llama.cpp warns that the model was trained for 128,000 and caps every serving slot. The exact startup lines:

llama_context: n_ctx_seq (131072) > n_ctx_train (128000) -- possible training context overflow
load_model: the slot context (131072) exceeds the training context of the model (128000) - capping
load_model: initializing, n_slots = 4, n_ctx_slot = 128000, kv_unified = 'true'

Asked for 128,000 directly, the same server starts without the warning. So for this official GGUF on this runtime, the configuration file is accurate and the card's number is not: 128,000 tokens is the hard maximum. That settles capacity. It says nothing about how much of that window the model can actually use, so we measured that too.

We planted short coded facts in long filler documents and asked the model to retrieve them. Each window size used three distinct sets of planted facts; each set placed one valid codeword near 5, 25, 50, 75, and 95 percent depth, and also planted two explicitly false, superseded codewords as distractors, so the model has to tell truth from decoy, not just spot a string. Prompts were sized with the live server's own token counter and filled about 95 percent of each window. Three sets of five depths makes fifteen tries per window size. The first matrix is the controlled pass, with a fixed 512-token output allowance. Each cell is exact retrievals out of three.

Some of those misses are not retrieval failures at all. They are the output-budget failure described in section 06: the model spends its whole output allowance on hidden reasoning and returns nothing. To separate the two, every failed cell was retried with the same prompt and the same seed (the fixed random starting point that makes a run repeatable) but more output room. This is the fair matrix:

At 16K, both misses were pure budget overruns and became exact with more room: 15 of 15. At 32K, one more cell recovered; the remaining misses were substantive, including two cells that repeatedly chose the explicitly marked wrong distractor. At 65K, raising the allowance to 3,000 tokens produced no additional exact answer, and at 128K, raising it to 4,096 produced zero: the model chose distractors, claimed present facts were absent, or spent everything on hidden reasoning. Some visible wrong answers at 128K were unrelated filler terms. A separate probe that asked for two planted facts at once agreed with this picture: it passed only at 16K.

The loss is not a gentle fade in the middle of the document. Every tested depth is affected at 65K and 128K. The sharp change sits somewhere between 32K and 65K, and these runs do not locate the exact point.

One more detail, in the model's favor as far as it goes. At 128K the model does not produce gibberish. Asked to summarize the whole 128,000-token document, it completed a grammatical, on-topic summary in 878 output tokens, with no breakdown into repetitive tokens. The summary also repeated its topics, described randomly ordered archive entries as systematically organized, and gave a nonsensical numeric range. Fluent output at this length is not evidence of reliable reading.

What this test does and does not measure: planted-fact retrieval is a narrow instrument. It checks whether facts can be found and told apart from planted fakes; it does not measure every kind of long-document reasoning, and passing it does not prove good synthesis. Because our distractors make the task harder than simple spot-the-string tests, these results should not be compared against scores from the common needle-in-a-haystack tests, which plant no competing statements.

Two practical notes from the same runs. Memory is not the obstacle: on the 32 GB graphics card used for every run on this page, even the full 128,000-token window fit in under 6 GiB of total observed GPU memory (whole-board readings, desktop included: 3,967 MiB at 16K, 4,087 MiB at 32K, 4,590 MiB at 65K, 5,781 MiB at 128K, and 5,868 MiB when 131,072 was requested and capped). And overflow fails loud rather than silently: a prompt sized about five percent over the window came back as an immediate HTTP 400 naming both counts, request (17239 tokens) exceeds the available context size (16384 tokens), try increasing it, with no silent truncation and no quiet dropping of the oldest text.

Which file to download

Liquid publishes official GGUF files at several compression levels ("quants"): smaller files trade a little fidelity for less memory. We tested three rungs of that ladder, all from the official GGUF repository at its pinned revision, on the same llama.cpp build: the smallest sensible official file (Q4_0), the ordinary middle choice (Q4_K_M), and the largest quantized rung offered (Q8_0).

The battery is the 90-run test battery of section 08; it scores protocol and task structure, not answer quality. Decode speeds are end-to-end medians (completion tokens divided by wall time, nine fixed requests per file, request overhead included): a run diagnostic, not a benchmark. Prompt processing on one 479-token prompt ran roughly 23,950 to 26,520 tokens per second across the three files. Memory values are whole-board readings that include the desktop; the Q4_K_M value is the earlier ledger's observed range rather than a same-minute reload.

Q4_K_M is the best-supported choice from these runs. It matched the top battery score at ordinary size and speed, and it is the file every other number on this page was measured on unless a section says otherwise.

Q4_0 ties the score and saves only 80.6 MB, and the equal score hides a behavior change. In the scenario built around two lookalike tools, Q4_0 repeated the same search to our test driver's six-round cap in 6 of 6 records, where Q4_K_M did so in 4 of 6 and twice stopped after one call and answered. The scenario still passes because its checker asks whether the right tool was called, not whether the model stopped calling it. Same score, weaker discipline.

Q8_0 scored worse on this build, and the reason matters more than the number. Its six added failures all sit in one scenario, the one where the request insists the model call some tool of its own choosing (tool_choice: "required"). That is a different request shape from the name-this-exact-tool scenario behind the six misses all three files share (section 08). In all six records Q8_0 made no call and ran into its length cap, with each record that reports token usage showing the entire 4,096-token allowance consumed; it repeated greeting text and leaked control tags into visible output. Outside those six records its reasoning stayed cleanly separated. This llama.cpp build is known not to robustly enforce that request shape. Q8_0 moved the model's token choices just enough to expose that serving-software weakness, which the two Q4 files happened to walk past. It is evidence of an interaction between this quant and this backend, not evidence that Q8 generally damages the model.

The blank-reply boundary did not move across the three files: on the same short question and seeds, every file returned an empty answer at a 256-token output budget and a real answer at 512. That is the same coarse boundary in the same place, not a promise about 512: section 06's wider sweep shows 512 is luck-dependent across seeds, and 1,024 is the reliable floor.

Only official GGUF files served by llama.cpp were tested. The official repository also offers BF16, F16, Q5_K_M, and Q6_K, which we have not run.

The output budget: why a working model can return an empty reply

This model reasons before it answers, by design. The card says so, and in our runs the reasoning arrives separated in its own field (section 03), so the user never sees it. The catch: that hidden reasoning is paid for out of the same output-token budget the client sets. In the recorded short-answer runs, the visible answer averaged about 180 to 205 characters (means of 181 and 203 across the two sampling arms) while the hidden reasoning averaged about 2,400 to 2,650 characters (means of 2,411 and 2,612), more than ten times the answer.

When the budget runs out during the hidden reasoning, nothing breaks loudly. The request succeeds: HTTP 200, no error, a finish_reason of length, and message content that is an empty string. A client that does not check finish_reason shows the user a blank reply, and nothing explains why. The thresholds below were measured at three seeds per cell, under both the server's default sampling and the model card's recommended settings (section 07 explains those two arms).

Three things stand out. First, short prose is reliable at a 1,024-token budget, not 512: 512 produced an answer on some seeds and a blank on others, and 256 or less reliably produced blanks. Second, tool calls are cheap. Every recorded tool call worked at a 128-token budget, because the model reasons far less before calling a tool than before writing prose. Third, long answers are the open problem: asked for about 500 words, the first complete answers appeared at a 2,048 budget, and even at 4,096 at least one seed in each arm still came back blank or cut off. No tested budget reliably completed that request; the threshold lies above 4,096.

The last table row is the agent shape, and it reproduces the most confusing failure directly. The model calls a tool, the tool works, and then the follow-up sentence to the user comes back empty because the whole budget of the second step went to hidden reasoning. From the outside, the agent looks like it worked and then said nothing. Note also that a nonempty reply can still be incomplete: several recorded answers carried real text and a finish_reason of length, meaning they were cut off mid-answer.

Sampling: what the server does versus what the card asks

Sampling settings shape how the model picks each token. llama.cpp hands its own defaults to any client that sends none, and most clients send none. Those defaults, read from the running server, are not the ones the model card recommends:

So by default, the card's recommendations are simply not in effect. And there is a trap in applying them that is worth knowing about whatever model you run: on this llama.cpp route the repetition-penalty request field is named repeat_penalty; the server's own settings listing carries only that name. The similar name many OpenAI-style clients use, repetition_penalty, is accepted and silently ignored. No error, no warning; the penalty just never applies. Our own first sweep fell into exactly this trap, which is why every number in this section comes from the corrected re-run with the field llama.cpp actually reads. A client sending the wrong name believes it has enabled the card's settings and has not.

With the correct field, the card's settings measured like this against the server defaults, on the same seeds:

• Short-prose hidden reasoning fell about 7.7 percent (a mean of 2,411 characters versus 2,612 at stable budgets). A real but modest saving; our miskeyed first sweep had suggested about a third, and the corrected measurement replaces that number.
• Search looping eased. In a test conversation deliberately built to invite repeated searching, the penalty at 1.1 produced a final answer in 3 of 5 trials versus 1 of 5 with it off, with fewer near-duplicate searches (28 of 45 versus 33 of 49). Both arms still looped heavily. Five paired trials support a mitigation, not a cure.
• One threshold got worse. Under the card's settings, the prose step right after a tool result went blank at a 128-token budget where the server defaults completed it, raising that reliable threshold from 128 to 256 (section 06's table).

The summary is not "use these settings." It is: know which settings are actually in effect on your route, apply the card's recommendations deliberately if their trade-offs fit your use, and measure rather than trust folklore, ours included.

What we ran, and what we still have not

On release day we served the official GGUF copy of the model (4-bit Q4_K_M, from the official GGUF repository at its own pinned revision, byte count and hash verified against the repository's records) with llama.cpp, and put it through the same recorded battery we used on its siblings. Three results, each with its run ledger on disk:

• Our automated route check-up (we call it the doctor) found the route healthy. No intervention needed, and two advisory warnings, neither attributed to the model. The template observation in section 03 was also confirmed on the live serving route, not just in the template text.
• 84 of 90 recorded runs passed across 15 scenarios: single calls, four-step chains, parallel calls, history restore, argument types, error recovery, and more, each run three times in both streaming modes. All six misses come from one scenario that tests a known defect in the serving software itself (it silently ignores a request to force one specific named tool), the same defect we measured with sibling models on the same build. Not one miss in the battery was attributed to the model. The battery scores protocol and task structure, not answer quality.
• Our three-task verify suite passed on the direct route, including a four-step tool chain completed in exact order with a correct, grounded final answer. This is the first model in this project to pass that strict gate with its shipped template and no repair layer.

Four more recorded sessions the same day grew those notes into this card:

• The context runs of section 04: 131 recorded completion requests across four served window sizes, every request and response kept.
• The download-file comparison of section 05: the full 90-run battery repeated on Q4_0 and Q8_0, with a budget sweep on each.
• The budget map of section 06: a 144-cell recorded grid across four request shapes, six budgets, two sampling arms, and three seeds, plus a ten-trial search-looping fixture.
• An earlier 54-call budget-and-sampling sweep, kept in the record and corrected by the grid above on one point (the misnamed penalty field described in section 07).

One recorded contrast from those battery records is worth stating in its exact terms. The call-some-tool scenario that Q8_0 tripped over in section 05 (the shape that requires a tool call without naming one; not the named-tool scenario behind this battery's six misses) has also been run on a larger sibling, LFM2.5-8B-A1B, on the same llama.cpp build, with the same driver and settings. In that recorded run the 8B made no tool call in any of six cases and spent its full 4,096-token allowance each time; the 2.6B passed the same scenario six of six, calling a tool immediately and using 58 completion tokens. The serving software's weak enforcement of that request shape is present in both cases; whether it bites depends on the model's habits, and this model's call-immediately habit walks past it. That is two recorded measurements of one backend defect, not a quality ranking.

Still not verified, stated plainly:

• Everything on this page is one backend, one build, one machine: llama.cpp build b1-5f55650 on a single 32 GB graphics card. There is no Ollama result, no vLLM or LM Studio result, no concurrency result, and no full-precision (safetensors) result in our records for this model.
• The battery's 84 of 90 scores protocol and task structure, not answer quality. A record can pass while its answer is poor; that caveat travels with the number wherever it appears.
• The exact retrieval breakpoint between 32K and 65K is unlocated. These runs establish that the boundary lies in that range, and no more.
• No budget that reliably completes a roughly 500-word answer is known; at three seeds it lies above 4,096 output tokens.
• The card carries Liquid's own benchmark table and speed figures. We have not reproduced any of them, so none of those numbers appear here.
• The card's 131,072-token context claim was tested only on this runtime, which enforces the training limit recorded in the GGUF. A runtime that ignores or overrides that limit was not tested.

Sources

• The model repository: huggingface.co/LiquidAI/LFM2.5-2.6B, read at pinned revision dca18258 on 2026-08-04.
• Repository dates, exact version identifiers, and the download counter: retrieved directly from Hugging Face on 2026-08-04 and saved with the project evidence.
• The chat template and the configuration file: pinned copies fetched from the repository at that same revision. Checksums (sha256): template ea663864…3b1bef, configuration d0b71d2a…019947. The repository's commit listing was saved the same day.
• The served files: the official GGUF repository at pinned revision b22e29ebf6249a8c9fcdda36914743e9980595c4, each file verified byte-for-byte against the repository's declared sizes and hashes (sha256: Q4_K_M 79fdf003…bfee14, Q4_0 91ad0c31…7c3a2b, Q8_0 36587fdf…bdb757), served by llama.cpp build b1-5f55650 on loopback.
• Every number on this page stands on a dated evidence document with raw run records behind it: the run ledger LEDGER_2026-08-04.md (sections 03 and 08: the pins, the doctor run, the 90-run battery, the verify suite, and the recorded 8B contrast), FINDINGS_context_truth_2026-08-04.md (section 04), FINDINGS_quant_ladder_2026-08-04.md (section 05), and FINDINGS_budget_extended_2026-08-04.md with its corrected predecessor FINDINGS_budget_and_sampling_2026-08-04.md (sections 06 and 07). Each names the raw record files, which keep full requests, responses, finish reasons, and timings.

The project records retain the exact source copies and checksums used for this page. The evidence documents named above are project records rather than public files today; they are named here so that every number on this page has a dated, recorded home that can be produced if questioned.