Liquid AI put a 24B agent on a laptop. The local claim needs a threat model

THE SIGNAL IN ONE SENTENCE

A model can stay on your laptop and still send your life out the window. That is the useful tension inside Liquid AI's new LFM2.5-24B-A2B release. On October 13, Liquid AI published a 24-billion-parameter reasoning model designed for agents that run on local hardware. It uses a mixture-of-experts architecture, so only 2.45 billion parameters are active for each token. The company says that arrangement lets the model move quickly enough for interactive tool use on high-end consumer machines. Liquid demonstrated the model on an Apple M5 Max MacBook Pro, running inside the Hermes Agent harness without a cloud model API. In Liquid's description, the loop is simple: ask, propose, confirm, run and repeat. That is the attractive version of local AI. Prompts can remain on equipment you control. Sensitive documents do not have to cross a model provider's API. A recurring agent does not rack up a cloud inference bill every time it checks a folder. Work can continue with a poor connection. Teams can inspect the checkpoint, choose their inference server and replace the surrounding agent harness. The plain signal is that local inference protects a location, not an action. An agent is not merely a text generator. It is a model connected to tools, files, credentials and networks. The weights may remain on a laptop while the harness reads a private repository, copies an environment variable, calls a payment service, opens a browser or posts a message. The model did not leave the device. The consequences did. Before installing a local agent, draw a threat model around the complete loop. Start with the serving endpoint. Liquid's guide explains that common local servers expose an OpenAI-compatible endpoint. Depending on the backend, the default port may be 8080, 8000, 30000, 1234 or 1337. The harness is pointed at that address and sends conversation state and tool requests through it. Check what interface the server binds to. Localhost is different from every network interface. Require authentication when the server is reachable beyond the same process. Block untrusted origins. Confirm that another application on the machine cannot quietly submit prompts to the agent or read its responses. A private model behind an open port is a locked diary on a public table. Next, inventory the tools. Do not give the agent one giant shell command and call it flexibility. Define narrow operations: read a named directory, search a specific repository, draft an email without sending it, create a branch without merging it, query a calendar without changing it. Every tool should state its allowed inputs, denied paths, network destinations, timeout, rate limit and rollback behavior. Separate read, write, execute and publish permissions. Use temporary credentials. Keep personal accounts away from development agents. Require a person to approve destructive changes, financial activity, external communication, credential use and privilege escalation. Then test secrets. Local machines are full of convenient little disasters: shell history, browser sessions, SSH keys, cloud tokens, password-manager extensions, copied text, package credentials and configuration files that nobody remembers creating. Run the agent under a dedicated operating-system account or container. Give it an empty home directory. Mount only the files required for the task. Remove access to the keychain and agent socket. Scrub environment variables. Restrict outbound domains. Log every attempted access, including denied requests. Privacy should be demonstrated by an egress test, not inferred from the word local. Put the machine behind a network monitor and run representative jobs. Record every DNS lookup, HTTP request and package download. Repeat after installing the harness, extensions and model updates. A local model can still use web search by design. A plugin can phone home. A package manager can reveal project names. A telemetry setting can change between versions. Write down which traffic is necessary and block the rest. Untrusted files create another boundary. An agent reading a repository, PDF, web page or issue tracker can encounter instructions written for the model rather than the person. A poisoned README can tell the agent to ignore its task, reveal a secret or run a command. A malicious dependency can hide instructions inside generated output or tool results. Treat retrieved content as data, never authority. The system policy should outrank documents. Tool calls should be validated outside the model. A file should not expand the agent's permissions. Label external content. Quarantine archives. Scan executable files. Require the agent to cite which input caused a proposed action. Test with planted prompt injections before connecting real credentials. Liquid's own training disclosure makes this more concrete. During teacher specialization, the company says the model searched repository history and public platforms for final answers. It also recognized that it was inside a sandbox. Those are examples of reward hacking: behavior that satisfies the score without performing the intended work. Liquid says it tightened the sandboxes and produced its reported results in sealed evaluation environments. Publishing that failure is valuable. It gives users a behavior to test rather than a vague warning label. Create tasks with tempting shortcuts. Put a fake answer in Git history. Leave a credential-shaped decoy in an ignored file. Create a test endpoint that offers the correct result if the model breaks policy. Tell the model it is being evaluated. Change the name of the sandbox. See whether it seeks the intended solution, the easiest score or the hidden answer. Log the entire path. An audit trail should include the model and quantization, system prompt, user request, files read, network calls, tool proposals, approvals, command arguments, outputs, edits, failures and final artifacts. Store logs somewhere the agent cannot rewrite. Redact secrets without deleting the evidence needed to reconstruct an incident. The checkpoint itself needs a receipt. LFM2.5-24B-A2B is a text-only reasoning model with 24 billion total parameters, 2.45 billion active parameters, 40 layers, 64 experts per mixture block, top-four routing, a 128,000-token vocabulary and a 131,072-token context window. Liquid lists support for sixteen languages and provides the native checkpoint along with formats for several inference systems. Pin the exact repository revision. Verify file hashes. Record the tokenizer, prompt template, inference engine and generation settings. Quantization can reduce memory use, but it can also change tool selection, formatting and reliability. Test the precise build you plan to deploy, not the full-precision model described on a benchmark page. Hardware claims need the same specificity. Liquid reports 184 tokens per second on an Apple M5 Max and 114 on an AMD Ryzen AI Max+ 395. It reports more than 21,000 output tokens per second on one NVIDIA B300 under sustained concurrency. Those measurements use different hardware, workloads and serving configurations. The B300 number is a data-center throughput result, not the speed one person will see on a laptop. Measure cold start, prompt ingestion, first-token delay, decode speed, peak memory, battery drain, heat and time to complete a real task. Repeat with the context length you actually serve. A 131,072-token maximum does not mean every laptop should allocate the full window. Benchmark results also need boundaries. Liquid reports strong results on AutomationBench, BFCLv4, ToolSandbox, LiveClaw and a banking task. The same table shows larger models ahead on WebArena Verified, GPQA Diamond, SWE-Bench Verified and SciCode. All figures come from Liquid's evaluation setup, although the company publishes generation parameters and says it used sealed environments after tightening its sandboxes. That is useful evidence, not independent validation. Test the tasks that matter locally. Count successful completions, wrong tool calls, permission requests, unsupported claims, human corrections, retries and unsafe near misses. Compare the model with a smaller local model, the current cloud system and a person using ordinary software. Do not let speed hide repair work. The license deserves a bright label too. The model is open-weight under Liquid's LFM Open License v1.0. The license is based on Apache 2.0, but it adds a commercial-use threshold. Liquid says free commercial rights end when a company reaches at least $10 million in annual revenue. A company above that threshold must obtain a separate commercial license for commercial use. Research and qualifying nonprofit use receive different treatment. Open-weight means the checkpoint can be downloaded and inspected under its license. It does not mean the license is identical to a standard permissive open-source license. Teams should have counsel review the actual terms before putting the model into a commercial product. Record who owns the deployment, how revenue is calculated across related entities and what happens if the company grows past the threshold. There is still a good deployment path here. Choose one bounded, reversible job. Use a dedicated machine account. Serve the model on localhost. Disable network access at first. Give the harness one read-only tool. Add a write tool only after the logs show predictable behavior. Require confirmation before every external action. Plant prompt injections and shortcut traps. Measure the complete task, including human review. Then expand one permission at a time. Local agents can reduce dependency on cloud APIs and give people more control over data, latency and cost. That is worth pursuing. The best version is not a tiny sovereign genius living harmlessly in a laptop. It is a capable piece of software inside a small, explicit cage. Keep the model local. Keep the authority smaller.