IBM CEO Arvind Krishna is making a consequential pitch to enterprise AI buyers: many everyday workloads no longer need the most capable, most expensive model.
Speaking on IBM’s third-quarter earnings call on October 21, 2026, Krishna said open-weight models can be about 90% as effective as frontier models while costing roughly 10–25% as much per token. IBM lists the call at 5 p.m. ET; The Register’s October 22 coverage reports his comments. The official earnings page confirms the event date.
Those percentages are IBM management’s claim, not an independently validated benchmark. Still, the argument matters beyond model pricing. If cheaper models meet an enterprise’s quality requirements, spending could shift from premium model access toward private infrastructure, deployment software and the people needed to operate it.
IBM’s Cost Claim Lacks a Reproducible Comparison
Krishna described open-weight models as “90 percent as effective,” according to The Register. His wider argument was that the capability gap has narrowed enough to change enterprise purchasing decisions.
The reported comparison supplies no named model pair, model versions, evaluation suite, hardware configuration or pricing methodology. It also leaves “effectiveness” undefined. Readers therefore cannot translate the figure into a universal quality score, a business-task success rate or a guarantee about factual accuracy.
The cost range needs equally careful handling. Paying 10–25% of a reference token cost implies a 75–90% reduction on that particular measure. It says nothing by itself about the complete cost of running an application.
Tokens are the units models process and generate from text and other inputs. A useful comparison must account for the workload’s input and output volumes, along with the conditions under which those tokens are served. A model that requires longer prompts, repeated attempts or more checking can change the economics of a completed task.
My view is that Krishna’s claim is useful as a procurement hypothesis: cheaper models deserve evaluation against actual business requirements. The headline percentages are not sufficient evidence for a purchasing decision.
Routine Workloads Make Model Routing Worth Considering
Krishna identified four examples of work he believes cheaper models can handle adequately:
- Summarizing emails.
- Examining contracts.
- Answering customer calls.
- Composing emails.
These examples, reported by The Register, span very different levels of risk. Drafting an internal message and interpreting a consequential contract clause should not share one acceptance threshold simply because both involve text.
A practical implication is model routing: assigning work to different models according to difficulty, sensitivity and required reliability. That is an analysis of Krishna’s argument, not a deployment architecture he announced on the call.
A company could evaluate a cheaper model for routine email summaries while reserving a stronger model or human review for ambiguous requests. For contract work, the acceptance test might require accurate identification of specified clauses and supporting passages. Customer-call workloads could add response-time requirements and rules about when to transfer to a person.
I’d separate these workloads before comparing prices. An aggregate quality score can conceal the exact failure that makes a particular application unacceptable.
Routing also has a governance constraint. If a request contains data that must stay inside a controlled environment, an external frontier-model fallback may be unavailable. The escalation path then needs an approved local alternative or human handling. Buying the strongest model is only one possible response to a difficult task.
Private Deployment Adds Control Beyond Open Weights
Open-weight models make model parameters available for deployment, subject to their licenses. That creates an opportunity to run inference, the process of generating responses, on infrastructure the customer selects. It does not automatically make the resulting service private or sovereign.
IBM’s separate January 15, 2026 Sovereign Core announcement provides context for its enterprise strategy. The company describes customer-operated control planes, locally governed inference, in-boundary identity and encryption keys, and local logs and telemetry. These are IBM’s product and architecture claims, not independent validation, and should not be presented as statements Krishna made on the earnings call.
Three layers matter:
| Layer | What it changes | What buyers still need to check |
|---|---|---|
| Open weights | Allows deployment of available model parameters under the applicable license | Usage rights, restrictions and deployment requirements |
| Local inference | Allows model execution within a chosen environment | Where prompts, outputs, logs and supporting services travel |
| Sovereignty controls | Governs operational authority, access and jurisdictional boundaries | Who controls administration, keys, telemetry and audit evidence |
IBM’s document makes a consequential point: sovereignty extends beyond the location of stored data. A locally running model can still depend on externally managed administration or send operational information elsewhere. IBM says its proposed architecture keeps those controls within the sovereign boundary.
That helps explain why private deployment can appeal even when it is not the cheapest option. Some buyers are purchasing operational control as well as inference capacity. Open weights make deployment choices possible; the surrounding system determines whether the organization’s privacy and sovereignty requirements are met.
Two or Three Racks Still Need an Operating Stack
Krishna expects useful enterprise AI systems to fit into two or three racks in many cases, according to The Register. That is a compact footprint compared with the enormous facilities associated with frontier-model training, but it is not a sizing specification.
Rack count leaves unanswered how much accelerator memory, compute, networking, power and redundancy a deployment contains. Workload volume, model size and response-time requirements determine whether a particular configuration is useful.
Krishna also identified operational skills enterprises may lack:
- Kernel expertise: Low-level software work that helps models use the underlying hardware efficiently.
- GPU networking: Placement and connectivity that allow accelerators working together to communicate effectively.
- Caching: Reusing suitable previously computed results to reduce repeated work and improve response times.
These requirements explain why inexpensive model access can coexist with substantial deployment costs. A model must be served reliably, connected to applications and operated under the company’s security rules before employees can depend on it.
Frequently Asked Questions
3 questions
1Is IBM’s 90% Figure an Independent Benchmark?
No. It is Krishna’s estimate. The reported comparison does not provide named models, a reproducible evaluation or a detailed cost methodology.
