How Companies Use Small, Open-Weight and Task-Specific Models
Small models are doing real work across a lot of industries. Insurers and title companies pull fields out of claims and property records, banks check onboarding documents and screen the news about their borrowers, law firms review contracts, hospitals read faxed referrals and clinical notes, retailers rank search results and sort returns, manufacturers read the paperwork that comes with parts and shipments, and security and SRE teams triage alerts and logs. Most of these are one kind of reading or sorting, repeated many times a day, which is what makes them a good fit.
Here are four of them in more detail. A title insurer’s data team pulls transaction and entity data out of property records, more than a million files a day. A security company scans its customers’ code for leaked passwords and keys. An error tracker decides whether two crash reports are the same bug, and a mental-health app screens every message a user sends. Those are the jobs, and the companies doing them (First American, Wiz, Sentry and Sword Health) are each on record, in their own posts or their vendors’ case studies, as having built them on a small open model they adapted themselves. Sentry, Sword and First American run theirs in production; Wiz’s detector is in private preview.
For Superlinked’s industry pages I collected 36 published examples like these, each checked against its source. The bar for getting in was that a company that leads in its field says, in its own words, that it runs, trains or fine-tunes a named open model, and the newer the better. That’s a sample picked to show what’s possible, so it tells you nothing about how common any of this is. Many of the 36 are also vendor case studies (Databricks, Predibase, Anyscale, Nebius, Meta) or the company’s own engineering blog, which means the numbers are self-reported.
What interested me more than the models was why these companies went this way, because the reasons aren’t all the same. Some wanted open weights so their customers’ data never reached someone else’s API. Some fine-tuned on data nobody else has, to build an advantage a competitor can’t buy. Some went as far as training and hosting their own models on their own servers. And cost comes up often, and it’s the one reason that still holds if you don’t care about the rest.
I’ll start with the jobs these companies gave to small models and say what I mean by “small”. Then I go through the cases they make, one at a time: open weights or a closed API, fine-tuning (often with LoRA) or using a model as it ships, building an advantage on your own data, training and hosting your own models, and cost at scale. After that I show what this looks like in code with three recipes from the SIE cookbook: two workflows, and one agent that uses one of those workflows as its tool. The post ends with how I’d pick your first job. Every quote and figure links to its source.
The Jobs Companies Give to Small Models
When I put all 36 side by side, what I got was the same handful of jobs repeated with different documents: read a document and pull out the fields, put a message in a bucket, rank search results, and, in a few cases, write a short, well-defined piece of text. The jobs whose output you can check move first. Wiz can say its secret detector reaches “86% precision and 82% recall” because a secret in code is either there or it isn’t, and once you can score a job like that you can try a smaller model and see whether it holds up.
Reading documents has the biggest volumes. First American says it uses LLMs “to process one million+ files daily for extracting transaction and entity data from property records” (Databricks, April 2025), and Meta’s case study names the model, Llama 3.1 8B fine-tuned on First American’s own data, with “an average F1 (pseudo accuracy) score of 90% on critical data fields”. Bevaya, an insurance document company, went one step lower and fine-tuned Qwen2.5-VL at 3B and 7B into its own OCR model, GutenOCR, which its Labs page says “Powers Document Intelligence inside the Bevaya Platform at production scale today”. Lockheed Martin put Llama into LMText Navigator, which “can process large quantities of data from a variety of sources securely and on premises” and which more than 40,000 of its employees already use (November 2024).
Classifying and screening uses the smallest models. Wiz fine-tuned Llama 3.2 1B for its secret detector (June 2025). Cloudflare put Llama Guard 3 into Firewall for AI to block unsafe prompts (August 2025). Sword Health fine-tuned its mental-health safety classifiers, MindGuard, from Qwen3Guard-Gen at 4B and 8B, and Nebius’s customer story says MindGuard screens every user message in Sword’s Dawn product. Marsh McLennan’s fine-tuned Llama-3.1-8B-instruct picks the intent and the tool inside LenAI, its assistant for staff (Predibase, March 2025). And LexisNexis “mostly relies on a fine-tuned Mistral model”, in VentureBeat’s story (March 2025), where its CTO Jeff Reihl put the reasoning in one line: “You don’t need GPT-4o to do the assessment of a query, so we use it for more sophisticated work, and we switch models out.”
Searching, ranking and grouping move because every shopper’s keystroke is a call. Target chose e5-small-v2 as its base encoder for product search “since it gives strong retrieval quality at much lower latency” (September 2026). Instacart fine-tuned an open-source Llama-3 8B with LoRA to understand queries in real time, and says it’s “reducing user complaints related to poor search results for tail queries by 50%” (November 2025). Grouping uses the same embeddings as search, to find reports that are close to each other instead of close to a query: Sentry trained modernbert-embed-large on labeled stacktrace pairs, and AI issue grouping is now on by default for all its customers (June 2026). Meta fine-tuned Llama 2 (7B) on past investigations to rank the code changes that might have caused an incident, and put the root cause in its top five suggestions 42% of the time (June 2024).
Writing jobs moved down a size are the newest group. Cisco’s Splunk AI Assistant in Security now runs its summary skill on a custom-tuned Foundation-Sec-8B-1.1-Instruct, “replacing previous Llama‑3.1‑70B model calls” (February 2026). Shopify fine-tuned Qwen3-32B into a tool-calling agent that writes Flow automations from a merchant’s plain-language request (April 2026). Datadog built Scout 1.0, the model behind its AI SRE, on GLM-5.3 Flash (October 2026). And the legal teams are heading the same way with bigger models: Harvey with a Qwen3.8-27B model trained with Engram, Thomson Reuters with its own model, Thomson, and Latham & Watkins fine-tuning Nemotron 3 open-weight models in-house.
The work that needs a model to read a lot and reason over it is where the large models stay, and some of those are open too. Bridgewater chose Qwen3-235B as its base model to replicate expert judgment in financial tasks (June 2026). R1 post-trained Nemotron 3.5 Super VL 120B for long-context medical reasoning to help reduce claim denials (October 2026, research results on synthetic cases). Siemens is extending its chip and circuit board design workflows with Nemotron 3 Ultra, a reasoning model “designed for complex, long-running agents” (July 2026).
What “Small” Means Here
By small I mean the task models in the low single-digit billions, from about 1B to 8B parameters. The fine-tunes at Wiz (1B), Sword Health (4B and 8B), Instacart and First American (8B) are all in that range, and an 8B model takes about 16 GB in BF16, so it fits on a single 24 GB L4 GPU. The encoders, rerankers, extractors and decision models that each do one job are smaller still.
Models from 27B to 32B, like Harvey’s 27B, Shopify’s 32B and the Qwen3.8-27B some of the cookbook recipes use, are on the verge of large. They’re built on open base models and still much cheaper to run than a frontier model, but I wouldn’t call them small. And a few open models in this post are large by any measure: R1’s is 120B, Bridgewater’s is 235B, and GLM-5.3 Flash, the base of Datadog’s Scout, is listed in SIE’s compatibility matrix for eight H100s. These are still smaller than the frontier models they replace, and that matters for cost. What all of them share with the small ones is open weights and the control that comes with them.
Open Weights or a Closed API
The first case is about who gets to see your data and who decides when your model changes. With a closed model behind an API, every input leaves your systems, and the model you call next month may not be the one you tested this month. With open weights you can run the model wherever the data already sits, and nothing changes until you change it.
Several of the companies say the data part out loud. Wiz says its customers “are explicitly unwilling to share proprietary code with external LLM services”. Latham & Watkins’ CIO put it more plainly: “we don’t want to put it to any cloud vendor”. In regulated businesses that preference has rules behind it (client consent in law, where health records may be stored, export control for defense data), and the legal, healthcare, finance and manufacturing pages go through the ones that apply in each. The control part comes up just as often. Capital One customized Llama for its Chat Concierge “to meet our high performance, risk, and governance thresholds”, and eBay, which adapted Llama to e-commerce, says that “relying on third-party models introduces data security risks and limits fine-tuning capabilities based on proprietary data.”
That doesn’t mean the closed models are gone. The most useful examples mix the two in one product. FurtherAI’s October 2026 post says “Claude Opus 5.5 handles complex claims and census extraction” while “GLM-5.3 reviews the extracted output for completeness”. Marsh McLennan’s small model picks the intent and the tool, while LenAI itself runs on privately hosted OpenAI models, as Insurance Business reported in August 2026. Bloomberg’s Wayne Barlow describes ASKB as “some commercial models, some open-weight LLMs, some smaller, custom language models that we build ourselves” (April 2026). The cookbook’s own agent recipes run their loops on Claude too.
In those stacks the small open models take the volume underneath: picking the intent at Marsh McLennan, reviewing the extracted output at FurtherAI, reading every page and every message. The large model reads a lot, weighs it and decides. I prefer open weights for the jobs that touch the raw data and run on every item, and I’m happy to keep a large hosted model on top to read a lot and decide, as long as what it sees is allowed to leave.
Off the Shelf or Fine-Tuned
Open weights also let you change the model, and most of the teams in these examples trained or adapted their own, with their own data and their own GPUs. Cloudflare is the clear exception, since it used Llama Guard 3 as Meta released it. The cookbook recipes go the same way as Cloudflare: none of them fine-tunes anything, and they use SIE catalog models as they ship, with lookups and Python rules around them. I think both are reasonable, and which one you need depends on what you’re asking the model to decide.
Fine-tuning doesn’t have to mean training the whole model. A LoRA adapter is a small set of extra weights trained on your data and loaded on top of the base model, so one base model can carry several of them. Instacart’s query model is a Llama-3 8B with LoRA, and Mirakl, which runs marketplaces for retailers, routes “up to 90% of catalog traffic to LLaMA 3.1 8B” with fine-tuned LoRA adapters, according to Anyscale’s case study.
Superlinked’s own studies show how far an off-the-shelf model falls behind a fine-tuned one when it has to decide on its own. On LexGLUE’s unfair Terms of Service clauses, GLiNER2.5-Decide out of the box scored an F1 of 0.20 on the unfair class. A hosted decision API given the lawyers’ annotation guidelines got 0.62, and ModernBERT-large fine-tuned on 5,532 labeled clauses got 0.84. On BANKING77, flagging possible fraud, Qwen3 1.7B with a LoRA adapter kept 98.8% recall at 95% precision, against 77.1% for GPT-6 Luna and 64.2% for the OpenAI Decisions API; a plain TF-IDF classifier trained on the same labels reached 92.1%. Much of that lead comes from having labels at all.
Fine-tuning is a trade, though, and it can cost you something you wanted. In SIE’s train-a-router example, a small model (the Laya router) decides which questions can go to a cheap model and which need the expensive one. On 975 held-out questions, the unchanged router sent 68.6% of them to the right model and saved 39.4% of the cost. With a LoRA adapter it reached 78.3%, and the saving fell to 18.2%, because the better router sent more questions to the expensive model. In Superlinked’s German legal retrieval experiment, an adapter trained in 41 minutes on one L4 lifted in-domain retrieval by 18.1% but lowered general German retrieval by 2.1%. Mixing legal and general training data 2:1 kept most of the gain and did less damage.
Here is how I decide. Off the shelf plus rules is enough when the model’s job is to point at something and code makes the decision: a span your code checks against the source text, a field it compares with the claim or the purchase order, a score that only routes work to a person. I’d fine-tune when the model itself has to decide (“is this clause unfair?”, “is this message fraud?”) and the out-of-the-box score on your data isn’t good enough. You probably already have the labels, in past reviews, analyst verdicts or closed tickets. Before you fine-tune anything, train a classical classifier on those labels, because 92.1% from TF-IDF is a high bar for the effort. And if every model you try gets the same cases wrong, the fault is probably in how the model is wired up, so look there first (Improve the Agent System Before You Fine-Tune the Model goes through that).
Your Own Data as the Advantage
Fine-tuning gets more interesting when the data you train on is something nobody else has. Shopify says it best: Flow “now runs on a model we trained, on infrastructure we own, improving from data only we have”. A competitor calling the same frontier API doesn’t get any of that data. Bridgewater’s trained model “makes 29.8% fewer mistakes than the best frontier model we evaluated” on its own financial tasks, which is a result you can only get from Bridgewater’s own expert judgments.
This works from both sides of a market. If you’re the newer company, going up against incumbents that are slow to move, a model fine-tuned on your own task lets you compete on technology. Harvey, which sells AI to law firms, reports that its 27B model “completes tasks competitively with leading frontier models while reducing cost per query by 90%” (August 2026, research results). Bevaya built its own OCR model instead of using someone else’s, and put the weights on Hugging Face. If you’re the incumbent, you already sit on the data, and the question is whether you use it before someone else catches up. Thomson Reuters says its model, Thomson, “starts from a strong open-source foundation” and is “trained and is run at a fraction of the cost of comparable frontier models” (press release, August 2026), and CoCounsel’s Tabular Analysis “also runs by default on Thomson”. LexisNexis distills its own models, First American fine-tuned on its own property files, and Bloomberg builds its own small custom models next to the commercial ones.
Interestingly, Bloomberg is also the cautionary tale. Barlow says BloombergGPT, the big model it trained on its own financial data, “was a research model and is actually not used at all in any of our products”. What lasted was the data, and the habit of building smaller models on it.
If you plan to train on your data someday, the text your teams write with AI today becomes part of that data, and whether you’re allowed to train on it depends on which model wrote it. I wrote that up separately in Who Owns the Tokens?.
Training and Hosting Your Own Models
Some of these companies went all the way and run the models on their own hardware. Latham & Watkins bought its own Nvidia servers and is fine-tuning Nemotron 3 open-weight models in-house (Financial Times, September 2026). Lockheed’s LMText Navigator runs on premises. Rockwell picked Nemotron-Nano-9B-v2 for edge and air-gapped plants, and Foxconn (its first LLM, on Llama 3.1), CrowdStrike (security models on Nemotron) and PayPal (agentic commerce on Nemotron) all build on open base models.
That’s a real investment, more in people and operations than in GPU hours, and most teams can get a long way before it. Training happens on your data and your GPUs; SIE serves models and doesn’t train them. If you’d like help with that part, Superlinked’s Native Inference team can evaluate models with you and post-train one. A fine-tuned model or a LoRA adapter you trained (the way Instacart and Mirakl did) runs on your own SIE Cluster or SIE Local deployment, declared in the model’s profile, while SIE Serverless runs only the catalog models.
Hosting your own also takes a little setup before the data really stays in: SIE Serverless sends your inputs to Superlinked, and on your own server, sie-server versions before 0.13.0 send anonymous usage telemetry by default, so you turn it off (SIE_TELEMETRY_DISABLED=1) and pre-load the model weights it would otherwise download from Hugging Face on first call. What it costs you depends on how much of the day a GPU is busy, which Choosing Where Small Models Run goes through.
Cost at Scale
Even if you don’t care about owning the model or training on your data, cost is reason enough, and it comes up again and again in these examples. Shopify’s Flow agent is “faster, cheaper, and more accurate than the frontier model it replaced”, “at 68% lower cost”. Bridgewater’s model is “vastly cheaper due to its smaller size: a 13.8x reduction in inference costs per task”. First American scaled to a million files a day “without the need to manage a large and expensive GPU fleet”. Etsy fine-tuned Qwen 3 VL 4B to grade its search results, processing “millions of query-listing pairs daily at a very low cost”, and did it “To reduce cost while maintaining quality”. Cisco got “better latency and more consistent results” from going 70B to 8B on the same job.
The cost argument isn’t only about the bill. Datadog post-trained Scout because it wanted investigations “cheap enough to run an order of magnitude more often and earlier in an incident’s lifecycle”. Sword’s classifier screens every message, and a check that runs on all of your traffic has to be cheap and quick, or it ends up running on a sample. A cheaper model lets you do the job more often, or on everything, instead of only where you could afford it.
Superlinked’s own task pages measure this too. Across the 14 task-page comparisons that also measured GPT-6.1 Sol, the open models score a median 98% of what it scores, at 3% of its cost (launch post).
Workflows and an Agent From the Cookbook
Most of the companies above run the model as one step in a process they wrote down, like First American’s field extraction, Sentry’s issue grouping or Mirakl’s catalog traffic. Shopify’s Flow agent and Datadog’s Scout are the exceptions. The recipes in the SIE cookbook are the same. Most are workflows: Python picks every step and calls a small model where a step needs one, so the same input takes the same steps, the cost per item is known up front, and a batch of thousands runs overnight with nobody watching. A few are agents: a model picks its next step in a loop (in the cookbook, a large one; at Shopify, a fine-tuned 32B), calling tools as it goes, because nobody could write the steps down in advance.
Here are two workflows and one agent. How to decide which one your job needs, and when a mix of the two is right, is in When to Use a Workflow and When to Use an Agent.
A Workflow: Checking a Repair Invoice Against the Claim
The first example is a repair invoice. A claims handler gets one as a PDF, a scan or a phone photo, opens it on one screen and the claim on the other, and checks it by eye: is this our claim, is it from the shop on the claim, do the lines add up, is the date after the loss, and is the total inside what the adjuster authorized? Most invoices are fine, which is the trouble, because after the fortieth clean one the forty-first gets the same quick look.
The insurance recipe splits that into steps. The claim number, the insured, the vendor and the authorized amount come from the claims system, and no model touches them. LightOnOCR-3-4B reads the invoice, and gliner2-large-v1 points at the fields, where a value only counts if it’s in the text on the line with its label. Then plain Python does every check, starting with whether the invoice belongs to this claim at all. Each invoice lands either in the handler’s payment queue with the fields ready to key in, or in the exceptions queue with the reason. Nothing is paid automatically.
On the live run, 9 of 10 invoices came out as expected, and the miss is the one I’d want you to remember. One invoice had a blank tax line. The OCR model wrote “$76.20” into it, exactly 6% of the subtotal, and the arithmetic check agreed with itself, because every number it compared came from the same OCR output. The near miss it did catch, an invoice from the right shop for exactly the authorized amount but billed to a different customer, was caught because the check compared the invoice with the claim, which the model didn’t produce. That’s the habit I’d take from this recipe: check what the model read against data it didn’t produce.
A Workflow: Search Results That Keep the Shopper’s Filters
The second example is product search. It’s the job Target and Instacart moved to small models, and for the same reason: it runs on every search. A shopper types “i want a warm jacket with a hood and that is waterproof and black or dark coloured like navy”, picks black and navy in the filters, and expects the first row to be what they asked for. Asking a model to rank everything lets it trade a filter for relevance, and a size 8 search that shows a size 8.5 costs trust faster than a bad order does.
So in the e-commerce recipe the filters stay in Python and the model only orders what passed. Python walks down the keyword hits 20 at a time, checking color against the catalog and size and stock against the inventory feed, and Qwen3-Reranker-4B orders the products that passed. A product with missing data (no color in the catalog, not in the stock feed) is never shown and goes on a list for whoever owns the catalog.
On the live run, 8 of the 10 test cases came out the way the recipe’s README says they should. There are eight test queries, and the README counts one of them as three cases, because it checks two shoes the filters should drop as well as the order of what’s left. The waterproof hooded jacket came first at 0.982, which keyword ranking got wrong, and a search for black running shoes found the one shoe that fits at keyword hit 31, which a filter applied after cutting to the top 20 would have thrown away. The two misses were the same miss twice: for “women s black tennis shoes size 8”, and for a typo’d search for toddler size 9 black tennis shoes, the filters did their job, and the reranker didn’t call any of the shoes left a match, so the shopper saw related items instead.
An Agent: Looking Across One Repair Shop’s Claims
The insurance workflow is done when each invoice is checked. A few times a month, the special investigations unit (SIU) gets a different job: someone refers a repair shop, and an analyst pulls every claim the shop worked that year, opens each invoice next to its claim, and builds a spreadsheet by hand before reading across the rows for patterns. For a shop with forty claims that’s two or three days, and most of it is retyping what the invoice check already read. Which patterns to look for depends on what turns up (an invoice number seen twice, the same total on two jobs), and the next referral will ask something else, so nobody can write the steps down. That’s why it’s an agent.
Claude Opus 5.5 runs the loop with four tools: one lists the shop’s claims for the year, one opens a claim, one ends the loop with a report, and one is the invoice workflow above, called as it is. So the same two small models read the invoices, and the agent gets exactly the answer the nightly run would. After the loop, code checks the report against what the tools returned and never against the agent’s own account of it: every open claim on the list was checked, every quote is a real value from the workflow’s results, and anything the agent calls a finding (which accuses the shop) rests on a check that actually failed. Anything wrong goes back to the agent once, and then the SIU analyst reads the report either way.
On five runs, the agent found the same invoice filed on two claims and wrote it up as a finding every time. Two neighbours with the same total, from the same storm with a flat-rate line, stayed a question for the adjuster every time. On one run it read the workflow refusing to check a closed claim as a failed check against the shop, and the code sent it back. And on three runs it brought up “220 Millrace Road”, once as a question across all seven claims. That’s the shop’s own address, printed on its letterhead. The code can’t tell a useful question from a noisy one, so the analyst spends a minute on it. Claude added about $0.09 a job on top of the workflow’s own SIE calls.
How to Pick Your First Job
Pick a job you do hundreds or thousands of times a week, where you can tell whether an answer is right because a person already checks it, or because a field has to match something already in your systems, like the purchase order in your ERP or the claim in your claims system. If two jobs fit, I’d start with the one whose data has a rule about where it can go, because that’s the one where a model in your own cloud answers your compliance team as well as cutting the bill.
Many of these jobs already have open models trained for them, which is what SIE is for. It serves a catalog of open, task-specific models behind one API, and the task pages show each job with its models, a measured comparison and a request you can run: OCR, extracting fields from documents, classifying text, redacting PII, reranking results and speech to text. On SIE Serverless you call them per request with an API key and no GPUs to run, and when the data has to stay put, the same model ids mostly run on SIE Cluster in your own cloud or SIE Local on your machine (check the cookbook’s compatibility table first, since one embedding model needs a swap and 29 of its 46 recipes need SIE Cluster to run on your own GPUs). I’d start there, with a cookbook recipe close to your job and a few of your own documents swapped in.
The industry posts walk through more of these recipes on sample data, misses included: legal, insurance, finance, healthcare, e-commerce, retail, manufacturing, security and SRE.
Conclusion
The companies in these examples moved real work to small, open-weight and task-specific models for different reasons. Some needed the data to stay with them, some fine-tuned on data nobody else has and turned it into an advantage, and some went as far as running their own models on their own servers. Most of them also say it cost less, and that alone is a good enough reason to try. In code, most of this is a workflow, with a small model reading or sorting and Python checking what it read against your own systems, and an agent on top for the jobs nobody can write the steps down for.
If you’ve moved a job like this to a small model, or you’re trying to work out which of your jobs to start with, I’d love to hear about it. Until next time.