The wrong first question is often “Which model is best?” A distributor needs the right product and quantity extracted from a buyer’s message. A marketing team needs a useful creative hypothesis that respects the product claims. Finance needs an explanation that reconciles to the numbers. These are different jobs. A model that sounds impressive in a chat window may be an expensive choice for any of them.
Choose the task, the evidence and the permission boundary first. Then compare models on whether they finish that task correctly, quickly and at an acceptable total cost. Decide where the model runs as a separate question. Downloadable weights, low token prices and a familiar brand each tell you something, but none tells you whether your customer will receive the correct quotation.
This is a decision framework for a business owner or technology buyer. The model examples illustrate deployment choices, not a universal ranking. Product capabilities and licences are version-specific; the linked documentation was reviewed on 14 September 2026.
A language model, explained through one order
Suppose a customer writes, “Can you send twenty cases of the usual blue gloves next week?” A language model can interpret the sentence, identify a likely request and propose structured fields. It learned patterns during training; it does not thereby know your current catalogue, this customer’s negotiated price or what the warehouse has promised elsewhere.
Think of a model as the reasoning and language component inside a larger service. The surrounding system supplies records, calls approved tools, checks results and records decisions. The model may propose that “usual” refers to a previous item. A database lookup establishes what that previous item actually was. A rule checks whether its pack size changed. A person handles a substitution the customer has not approved.
“LLM” means large language model. “LM” is the broader term. Size refers to the model, not to the size of the business it should serve. A smaller model can be a good choice for a constrained extraction task if it passes your tests. A larger one may be useful when documents conflict and several steps are needed, but it does not get a permission exemption because it reasons more fluently.
Tokens are the units the model processes. They are pieces of text rather than reliably one word each. Token volume can affect cost and speed. It is therefore useful to provide relevant evidence rather than repeatedly send an entire document archive. But deleting the facts needed to make the decision is a false saving.
Test whether required fields are extracted accurately from the source.
Check how the system handles conflicting evidence and uncertainty.
Use rules, verified calculations and permissions to control the final action.
Read the visual explanation
A practical sequence for this decision. Apply your actual records, responsibilities and acceptance criteria.
Choose models at the level of a task
A conceptual routing map, not a benchmark or a recommendation of one provider.
The terms people mix together
| Term | Plain meaning | A business decision it does not answer |
|---|---|---|
| Model | The trained component that produces outputs | Who owns an incorrect customer commitment |
| API | A way software sends a request and receives a response | Whether the response is accurate or retained |
| Open weights | Model parameters are available under stated terms | Whether every commercial use is permitted |
| Self-hosting | You operate the model-serving environment | Whether your whole system is private or reliable |
| Retrieval | Find relevant external records for a task | Whether those records are current and authorized |
| Fine-tuning | Additional training changes model behaviour | Whether today’s stock balance is included |
| Workflow | A defined sequence of work and decisions | Whether every step needs AI |
| Agent | A system in which a model can choose steps or tools | Whether it may take every available action |
Anthropic’s engineering guidance distinguishes predefined workflows from agents that decide how to use tools, and recommends starting with simpler patterns when they suffice. This is a useful architectural distinction, rather than a requirement to use its products. Building effective agents.
In the gloves example, the workflow might always check customer, item, unit, stock and price in that order. A bounded agent might choose which record to consult when the customer’s reference is incomplete. Both can be useful. The important difference is how the system controls uncertainty, not which label appears in a sales deck.
Open weights are not a complete operating system
Weights are learned numerical parameters. Having them can make it possible to operate or adapt a model yourself, subject to its licence and technical requirements. It does not automatically include the full training data, all training code, a support team or permission for every use.
The Open Source Initiative’s definition goes beyond available weights: it addresses freedoms to use, study, modify and share, alongside the information and code needed for modification. That is why “open weights” and “open source AI” should not be used interchangeably without checking the release. Open Source AI Definition 1.0.
Licensing also varies within a vendor’s portfolio. Mistral’s help page describes different terms for different releases, while its Mistral 3 announcement explicitly identifies Apache 2.0 releases. The practical procurement step is to record the exact model, licence version and intended use, rather than approve an entire vendor under the word “open.” Mistral licensing, Mistral 3 release.
A useful question for your supplier is: “If we move this deployment to another operator, which model files, configuration, tests and business records can we take with us?” The answer reveals more about independence than a logo strip.
How the choices are positioned
The market has several layers. A model developer creates models. A hosting provider runs them. A gateway can route requests among providers. An application supplies a complete user experience. A delivery partner can integrate and operate a business process. One company may occupy several layers, but the layers remain different responsibilities.
| Choice | Why a team might shortlist it | What to verify before choosing |
|---|---|---|
| Hosted model service | Fast start without operating inference hardware | Exact endpoint, retention terms, regional availability, tool behaviour and cost on your workload |
| Downloadable model release, such as a specific Qwen or Mistral release | Deployment control and adaptation options | Licence, hardware, serving stack, evaluation and operational staffing |
| Google Gemma release | An open-weight deployment option within Google’s model ecosystem | Exact version and hardware requirements; do not assume it is the same product as hosted Gemini |
| Multi-provider gateway, such as OpenRouter | A common access layer and routing choices | Provider actually used, fallback policy and data boundaries |
| Specialized application | A focused business interface and existing integrations | Whether it completes your process or still leaves exception work with your team |
Google’s Gemma documentation describes open weights and different architectures and memory requirements. Qwen’s release card documents a specific model and its configuration. These are examples of information a technical team should inspect; their existence does not establish that either will outperform a hosted alternative on your orders. Gemma model overview, Qwen release card.
OpenRouter’s routing documentation includes provider order, fallbacks, required parameters and data-handling controls. This makes another important point: a model name and the endpoint serving it are not the same thing. A permitted primary endpoint does not make every fallback permitted. Provider routing.
Instead of a permanent league table, maintain an approved shortlist by task: extraction, customer-facing drafting, difficult document interpretation and speech or image input where needed. Record which version passed which test. Replace a model when measured performance improves, not simply because a new name is trending.
Use retrieval for facts that change
Your stock, prices and customer permissions change too often to treat training as the source of truth. Retrieve them from the authoritative system at the time the decision needs them. Keep the original record, its age and the relevant permission with the result.
Fine-tuning can be considered when repeated examples could improve a stable behaviour or format. It should not be the default answer to a missing live lookup. If a team says the model “knows our business,” ask whether it can show the current source for the claim it is making.
Retrieval itself needs testing. Can the system find the right revision? Does it accidentally retrieve another customer’s documents? What happens if the stock service times out? A more capable model cannot fix an authorization filter that supplies the wrong records.
For Arabic or mixed-language work, preserve identifiers exactly. A part number, quantity and currency must survive translation. Evaluate the complete task with representative messages, including informal spelling and mixed scripts, rather than judge language quality from a polished paragraph alone.
Compare cost per accepted result
Fictional USD example. Monetary assumptions in this guide are illustrative US-dollar amounts, not quoted prices, measured results or exchange-rate conversions. The currency does not imply a US tax or legal setting.
Consider a fictional monthly batch of 10,000 extraction tasks. Route A costs USD 1 per task in model usage and needs correction on 8% of tasks. Route B costs USD 3 per task and needs correction on 2%. Assume each correction takes three minutes and the fully loaded labour rate is USD 600 an hour. These are assumptions, not vendor prices or benchmark results.
| Cost | Route A | Route B |
|---|---|---|
| Model usage | USD 10,000 | USD 30,000 |
| Corrections | 800 | 200 |
| Correction hours | 40 | 10 |
| Correction labour | USD 24,000 | USD 6,000 |
| Model plus correction cost | USD 34,000 | USD 36,000 |
If all 10,000 results are accepted after those corrections, the combined cost per accepted result is USD 3.40 for Route A and USD 3.60 for Route B. If some remain rejected, divide by the smaller accepted count instead. Route A is still slightly cheaper under those assumptions. Now suppose corrections take six minutes. Its combined cost becomes USD 58,000; Route B becomes USD 42,000. The apparently expensive model becomes cheaper to operate.
This is not enough to choose B automatically. Add latency, infrastructure, supervision, failure recovery and the consequence of errors that escape review. A wrong currency that reaches a buyer is more serious than an extra space in a description. Some failures should disqualify a route rather than be averaged into a quality score.
Self-hosting adds a different cost structure: capacity, utilization, monitoring, updates and operator time. At low volume, idle capacity can dominate. At sustained volume, a well-operated deployment may be attractive. Compare like-for-like service levels before claiming either is cheaper.
Build a test a commercial manager can understand
Collect representative historical tasks with sensitive information minimized. Include ordinary cases and deliberately difficult ones: obsolete SKU, mixed units, a cancelled order, conflicting attachments, a repeated message and an unavailable system. Keep a separate test set that is not used to adjust prompts.
Define an acceptable result before running the comparison. For an order, it might require the correct customer, exact item, unit, quantity and source references, with uncertain cases held. For a creative brief, it may require a testable hypothesis and only approved product claims. Do not ask the same model to be the sole judge of its own business correctness.
Run the whole system, including retrieval and tools. Test repeated attempts and failure recovery. A model’s extraction accuracy on a pasted paragraph is not the same as the workflow’s accuracy after a file upload, OCR, lookup and write.
Finally, make the review intelligible to the operator. Show the source, proposed result and reason for escalation. Your best safeguard is often a well-designed decision screen with a named owner, not a longer prompt hidden behind the interface.
Where Looqus fits
Looqus’s role should be scoped around the work: connect approved sources, establish acceptance rules, operate the model-and-tool sequence, resolve exceptions and measure the result. Model selection belongs inside that work. It should remain possible to explain why a particular route is being used and what happens when it fails.
If your process is already handled well by a specialist application, buying that application may be the right answer. If the challenge crosses systems and repeatedly needs someone to carry unresolved work to completion, that is the conversation worth having with Looqus.
Continue with the next decision
The open-model operations guide develops the deployment question. The enterprise examples show how operating boundaries relate to business delivery.
Sources
- Anthropic, Building effective agents, 19 December 2024.
- Open Source Initiative, Open Source AI Definition 1.0.
- Mistral, Model licensing guidance and Mistral 3 release.
- Google, Gemma model overview.
- Qwen, Qwen3-30B-A3B release card. A documented example, not a claim that this is the latest or best Qwen release.
- OpenRouter, Provider routing documentation.
For listening or reading aloud
Read the spoken companion
Written companion transcript. Audio has not been recorded.
Which AI model should your business use? Start by putting the model names aside for a moment. Imagine a customer asks for twenty cases of their usual product. The valuable result is not a fluent reply. It is the right product, in the right quantity, at a price and delivery date your business can honour.
A language model helps interpret the request. It does not automatically know your stock or the customer’s negotiated terms. Those facts need to come from your systems. This is the first distinction to remember: the model is one component. The business service also needs records, rules, tools and somebody responsible when information is missing.
The next distinction is between a model and where it runs. You can use a hosted service, where a provider operates the infrastructure. Or you can choose a release with downloadable weights and operate it yourself, subject to the licence. Open weights do not mean zero operating cost. They also do not automatically mean every possible use is allowed. Check the actual release, not just the vendor’s marketing category.
There is a third layer: routing. A gateway may offer access to several providers. That can be useful, but your data policy must apply to the backup route as well as the first choice. Knowing the model name is not the same as knowing which endpoint processed the request.
Now consider cost. In our fictional example, a cheap model costs one rupee per task and a more expensive model costs three. The cheap model needs more human corrections. With short corrections, it remains slightly cheaper overall. With longer corrections, the more expensive model costs less to operate. This is why token price alone is a poor purchasing decision.
The number to investigate is the cost of an acceptable result, with the service level you need. Include correction time, infrastructure, delays and recovery. And do not turn every error into an average. A wrong currency sent to a buyer may be unacceptable even if the system gets most other fields right.
How do you test this? Use examples from your actual work. Include the difficult ones: changed product codes, conflicting documents and a system that is temporarily unavailable. Agree what a correct result looks like before the test. Keep some examples aside so you are not just tuning to a familiar sample.
For Arabic or mixed-language work, test the numbers and identifiers as carefully as the sentences. A beautifully written answer with the wrong part number is still wrong.
The useful outcome is a shortlist by task, with evidence for each choice. You might use one route for simple extraction and another for a difficult document, while keeping pricing calculations deterministic. That is more practical than announcing one model as the winner for your whole company.
If you want to examine a task with Looqus, describe what needs to be finished and the mistake your business cannot accept. No files or preparation are needed for the first conversation. We can discuss the process and the ownership it needs. The point is to complete the work reliably, not to buy a fashionable model name.
AI does the work.We own the outcome.
Compare models within the complete business task, including tools, corrections and difficult cases, before choosing the operating setup your team will depend on.
- Agree the result
- Connect the work
- Own the follow-through