A 1.1 GB model that does not chat. Obsessive-1.7B, derived from LFM3-1.7B, takes a factual question, calls web_search once, and returns a short answer, a word-for-word quote, and the URL. If the search results do not contain the answer, it says "Not found in the search results." It is not meant to be a conversational model: it runs as a subagent under a larger model.

The base LFM model surprised its developer in its ability to handle tool calls and extract information. The reported example is Barbara Liskov: answer, verbatim quote, and Wikipedia link.

The trade-off between coverage and predictability

In a fixed-results benchmark (131 held-out SimpleQA questions, with the answer removed from results in 29 of them), the base model finds the answer when present 50% of the time, Obsessive 94%. When the answer is absent, the base says "not found" 0% of the time; Obsessive 100%. Invented answers drop from 10% to 0%. Median time per question on an RTX 4060 laptop falls from 5.1 to 2.0 seconds.

On live Wikipedia search (120 questions plus 40 multi-fact requests, using a search backend the model never trained on), the base model returns any reply 38% of the time, Obsessive 100%. On raw correct answers in replies, the base wins: 37/120 versus 24/120. The reason is stated: the base keeps searching and writes long replies, so the answer appears more often; however, 62% of the time it runs out of turns and returns nothing. Obsessive searches once and states only what it can quote. For invented fact values, the live comparison is 4 out of 4 for the base and 3 out of 52 for Obsessive.

Here a structural point emerges. In an automated system, a component that returns nothing 62% of the time is an operational black hole: the orchestrator does not know whether to retry, move on, or stop. A subagent that always returns an answer, with a quote and a URL, offers a stricter operational contract. It pays in raw coverage: it says "not found" for about one in ten answers that are actually in the results, and it sometimes quotes a neighboring fact, like a winner from the wrong year. But the architecture enables downstream verification: the quote is there, ready to be checked.

The training setup is equally interesting. LoRA rank 16, about 9,000 tool-calling conversations, an RTX 4060 laptop. Search results come from Wikipedia and FineWeb pages, with every answer and quote checked to appear verbatim; about a quarter of the data teaches the "not found" response. The model is served with llama-server, a GGUF file, a 16,384-token context window, and temperature 0: a self-hosted configuration, not a cloud one. The known problems fit the constraint: one question per conversation, multi-turn chats confuse it, English only, and it tends to report claims as facts ("X says it solved Y" can become "Yes").

A local 1.1 GB model acting as a subagent shifts incentives for those evaluating on-premise pipelines. You do not need a data center to run specialized components: fine-tuning can happen on a laptop, data can stay in-house, and distribution works through existing GGUF tooling. The comparison is no longer between big and generic versus small and useless; it is between statistical coverage and operational predictability. For teams weighing on-premise deployment, AI-RADAR offers analytical frameworks at /llm-onpremise to evaluate these trade-offs.