Liquid AI released LFM2.5-24B-A2B on October 13, an open-weight reasoning model with 24 billion total parameters and 2 billion active parameters per token. The company positions it for local agents and reports strong results on several tool-use evaluations. Its context window expands to 131,072 tokens, and the release includes base and post-trained checkpoints.
The distinction between total and active parameters is important. Activating only part of a model can reduce computation per token, but the system still needs a way to store and access the full set of weights. A small active count should not be read as a promise that the model has the memory footprint of a dense model of the same active size.
Find the task that belongs on the device
A useful local-agent trial begins with a task that already has nearby data and tools. For example, an assistant might organize a directory of work documents, extract a fixed set of fields, and prepare a draft index for review. This gives the team a clear outcome without requiring the model to possess every relevant fact internally.
Test the whole loop: reading the documents, selecting tools, recovering from a malformed file, and producing the final artifact. A fast stream of tokens is only part of the experience. Slow file operations or repeated attempts can dominate the time a user waits.
Reasoning has a resource cost
Liquid describes this release as a reasoning-only model. That makes the amount of generated intermediate work relevant to latency and memory planning. A narrow task may not benefit from a lengthy reasoning process even if the model is good at more involved work.
Compare a few representative tasks with explicit completion criteria. Record total duration, output length, memory use, and the proportion that finish without repair. Include a task that should stop because information is missing. An agent that recognizes this limit can be more useful than one that spends additional time inventing a way forward.
The company’s own benchmark table shows variation across categories. That is a useful reminder to avoid turning a strong tool-use result into a blanket claim about knowledge or software engineering. A local assistant can combine a suitable model with retrieval, deterministic calculations, and a carefully chosen tool interface.
Before adoption, verify the checkpoint’s license, runtime support, and expected behavior on the intended hardware. Keep a record of the exact model and quantization used in testing. LFM2.5’s appeal is a potentially efficient local component; the practical decision is whether that component makes a specific workflow faster and more reliable within the device’s actual constraints.
Have a correction or a useful perspective?
Get in touch with the publication.
