Open-Weight AI Model Economics: Build, Buy or Self-Host?

Open weights change who owns the model. They do not remove the cost of turning it into a reliable service. The right enterprise choice is therefore workload-specific, measured in successful tasks rather than cheap tokens, and designed to remain reversible.

The most misleading number in enterprise AI may be zero.

An organisation downloads an open model. There is no per-token invoice from a model provider, so the model appears free. A team then compares that apparent zero with a proprietary API price and concludes that self-hosting must be cheaper.

But weights are not a service. Someone still has to provide accelerators, memory, storage and networking. Someone has to configure the serving engine, absorb idle capacity, evaluate new versions, monitor failures, patch the runtime, protect data, support users, meet latency objectives and restore the service when it breaks. If a model produces more review work or costly errors, someone pays for those too.

The opposite comparison is equally weak. A managed API can look expensive by the token while being economically conservative for uncertain or intermittent demand. The provider pools capacity across customers and takes responsibility for much of the model and infrastructure lifecycle. Buying that variability may be more rational than owning an accelerator that waits for work.

The real decision is not open versus proprietary. It is which party should own each layer of cost and risk for each workload.

That produces a different executive question:

Which operating model delivers an accepted, policy-compliant task at the required quality, latency and reliability, after compute, people, controls, failure and exit are counted?

Once that is the denominator, “build or buy” stops being an ideological choice. It becomes a portfolio design problem.

The zero-price trap

Open models can create genuine economic advantages. An organisation may avoid a recurring model fee, choose its own serving stack, run a checkpoint in a controlled environment, quantise it for particular hardware or tune it for a bounded task. It may also reduce dependence on a single provider.

None of those benefits makes the production service free.

A defensible total-cost boundary includes at least:

model and licence obligations;
inference compute, host CPU and memory;
storage, networking and data transfer;
gateway and orchestration services;
retrieval infrastructure where retrieval-augmented generation, or RAG, is used;
evaluation, observability and incident response;
security, identity, privacy and audit controls;
capacity headroom, redundancy and recovery;
model onboarding, upgrades, patching and rollback;
specialist engineering, operations, validation and support;
migration and exit work; and
the expected cost of failed, rejected or manually reviewed outputs.

This list is not an argument against self-hosting. It is an argument for comparing like with like.

The acquisition cost of a checkpoint is only one line. A proprietary API transfers some other lines to a provider and bundles them into usage or commitment charges. A managed open endpoint transfers a different subset. Self-hosting returns more control and more responsibility to the customer. On-premises infrastructure adds physical placement control, but also procurement, power, cooling, capacity planning and hardware-refresh risk.

In other words, every option is a way of allocating ownership.

Four ways to buy the same capability

Most enterprise comparisons need four operating models, not two.

1. Proprietary model API

A proprietary API is a strong baseline when demand is uncertain, seasonal or bursty; when the workload needs frontier capability; or when the organisation has a thin AI platform team. Usage-based pricing converts much of the capacity cost into variable cost. Providers also absorb accelerator acquisition, much of the availability engineering and frequent base-model upgrades.

The customer still owns the application. Prompt construction, retrieval, identity, permissions, output validation, human review, usage controls and fallback remain enterprise responsibilities. Data retention, processing region and private-network options also depend on the exact feature and contract, not the word “enterprise”.

2. Managed open-model inference

Managed open inference is a meaningful middle category. The customer chooses a checkpoint, revision, instance type and often the serving engine, while a provider handles deployment, replica health and infrastructure operation.

Hugging Face’s dedicated Inference Endpoints documentation, for example, describes hourly instance pricing and provider-managed deployment. This can preserve more model choice than a closed API without requiring the customer to operate Kubernetes and GPU health. It does not remove idle exposure, portability constraints or cold-start trade-offs. The service remains a managed infrastructure dependency.

3. Self-hosted private cloud

Self-hosting becomes credible when demand is sufficiently stable and large, direct infrastructure control is important, specialised latency or throughput optimisation matters, or model customisation has strategic value.

The key phrase is “sufficiently stable”. A team with high aggregate demand can pool workloads, batch requests and keep accelerators productive. A team with sporadic traffic pays for quiet hours and may still need spare capacity for bursts and failures.

Self-hosting also needs organisational scale. Atlassian has attributed more than 60 per cent LLM infrastructure cost reduction and up to 40 per cent P90 latency improvement to migration onto its own inference engine. Yet its engineering account also describes Kubernetes, automated provisioning, GitOps, multiple serving engines, observability and safe rollouts. That is useful evidence of feasibility and prerequisites. It is not portable proof that downloading weights creates the same saving elsewhere.

4. On-premises operation

On-premises infrastructure can be rational where hard locality, air-gap or long-lived capacity requirements dominate. It gives the organisation maximum physical placement control.

It also introduces procurement lead time, power and cooling, spares, support, multi-year depreciation, residual-value uncertainty and the risk that the model or hardware frontier moves before the accounting life ends. A three-year hardware model that assumes a stable software stack is likely to be too comfortable.

Figure 1 summarises the first-pass fit. It is a screening tool, not a procurement score. A configuration remains ineligible until its quality, controls, latency and resilience pass.

Seven-row decision matrix comparing proprietary API, managed open inference, self-hosted cloud and on-premises deployment across demand, frontier reasoning, infrastructure control, operating burden, elasticity and exit; an adjacent article table provides every result and label definition. — Start with the workload. The preferred route changes with demand stability, capability, control needs and the organisation’s ability to operate the stack.

Accessible matrix equivalent

Decision factor	Proprietary API	Managed open	Self-hosted cloud	On-premises
Low or uncertain demand	Strong	Conditional	Weak	Weak
Stable, high utilisation	Conditional	Strong	Strong	Conditional
Frontier reasoning	Strong	Model-dependent	Model-dependent	Model-dependent
Direct infrastructure control	Weak	Conditional	Strong	Strong
Low internal operating burden	Strong	Conditional	Weak	Weak
Burst elasticity	Strong	Conditional	Conditional	Weak
Exit optionality	Conditional	Conditional	Conditional	Hardware-bound

In this illustrative framework, conditional means that fit depends on the provider, contract, workload and operating design. Model-dependent means that deployment mode cannot compensate for a checkpoint that fails the task’s quality threshold. Hardware-bound means that exit is constrained by owned capacity, procurement and refresh cycles. Managed open inference can reduce infrastructure work, but the customer still owns checkpoint selection, evaluation, integration and provider governance. Self-hosted cloud can improve stack control, but exit remains conditional on substitute-model quality, portable serving components and available capacity.

The important insight is that these four models transfer different costs. A strong comparison does not ask which option is cheapest in the abstract. It asks which responsibilities the organisation is prepared to own.

Utilisation is the economic hinge

The most important self-hosting variable is often not model size. It is useful utilisation.

A reserved accelerator continues to cost money through quiet hours, low concurrency, failed requests and unused headroom. A quoted hourly rate becomes economically meaningful only when it is divided by accepted productive work.

As a dated illustration, AWS’s Capacity Blocks pricing listed a p5.4xlarge with one H100 at $5.97 per hour when checked on 22 October 2026. Multiplied by 730 hours, that is about $4,358 for a continuously reserved month.

That is not a break-even number. It is not a universal on-demand rate. It excludes the rest of the host and service boundary, including storage, networking, redundancy, platform software and people.

It is useful because it makes the denominator visible. At 10 per cent useful utilisation, each productive accelerator-hour carries roughly $59.70 of capacity charge. At 30 per cent, the figure is about $19.90. At 60 per cent, it is about $9.95. At 80 per cent, it is about $7.46.

The same monthly bill produces four very different unit economics.

Even “useful utilisation” needs care. Inference has different phases. Prefill processes the input context and can be compute-intensive. Decode generates output sequentially and can be constrained by memory bandwidth and key-value cache capacity. A workload with long documents and short answers may consume substantial capacity without producing many visible output tokens.

Batching helps by grouping work. Continuous batching admits new requests as other sequences progress. Paged cache management reduces memory fragmentation. These techniques can materially improve throughput, but their benefit depends on request length, concurrency, hardware, precision and latency objectives.

An offline batch and an interactive service are therefore different economic products. MLCommons’ inference methodology uses distinct request scenarios and metrics for this reason. A maximum-throughput result with all work available in advance cannot justify a low-latency service design.

The capacity tax

Interactive services need headroom. Queue bursts, long requests, replica startup and node failures all affect tail latency. A service promising P95 latency cannot plan against average arrival rate and then call the difference waste.

Part of under-utilised capacity is a reliability purchase.

The economic question is whether headroom is sized from measured arrivals, queue tolerance, model-load time and failure tests. Unmeasured overprovisioning is waste. Measured burst reserve and redundancy are service cost.

Multi-zone resilience makes the issue sharper. Active-active operation may require two warm copies. Active-passive operation can reduce normal use, but only if the passive path meets recovery time and data-consistency requirements. Managed APIs have regional limits and incidents too, so the comparison must include application-level fallback on both sides.

This is why a single “tokens per second” result is not a business case. The organisation needs a grid:

monthly and peak request volume;
input and output length distributions;
concurrency and arrival pattern;
useful-utilisation bands;
P50 and P95 latency objectives;
replicas and failure domains;
precision and serving engine;
engineering allocation; and
accepted-task and review rates.

The crossover is a region of cells in which cost, quality and controls all pass. It is not the point where a public GPU rate crosses a public API rate.

Build the TCO model by cost behaviour

Accounting categories are not enough. A useful model separates costs according to how they behave when traffic, quality requirements or service levels change.

Variable request costs move broadly with usage. They include input and output tokens, cached tokens, managed tool calls, retrieval queries, data transfer and per-request human review. They are easy to observe, but they may still be nonlinear. Long-context tiers, regional processing, quota arrangements and batch modes can change the rate. Preserve the provider, model version, region, rate card and effective date used in every scenario.

Step-fixed capacity costs rise when another replica, accelerator or failure domain is needed. They create a staircase rather than a smooth curve. A small traffic increase can push concurrency above a latency threshold and require a whole additional replica. Scale-to-zero can remove the minimum during quiet periods, but the organisation then owns the user experience during model loading, including queues, retries and timeouts.

Platform costs include the gateway, deployment automation, secrets, registry, observability, evaluation service, policy engine, data connectors, chargeback and support. Some are shared across many models and workloads. Allocating none of that cost because the team already exists hides opportunity cost. Allocating the entire platform to the first workload makes later workloads appear artificially cheap. Use a transparent allocation driver and show both marginal and replacement cost.

Change costs arrive in programmes rather than requests. Model upgrades, prompt regression, safety-policy changes, quantisation, driver patches, licence review, endpoint deprecation and revalidation all belong here. A monthly run-rate misses them. Model the decision over an annual or three-year horizon with explicit refresh events.

Risk costs include error, downtime, privacy incidents, policy breaches, concentration and failed exit. They should not be converted into false precision. Use bounded scenarios for frequency, response effort and affected volume, while keeping severe tail risks visible separately.

The annual comparison becomes:

request-variable cost + capacity steps + platform run cost + change programmes + control cost + expected operational loss

Divide that total by accepted, policy-compliant tasks. This makes review burden, fallback and invalid output economically visible.

Labour is not an embarrassing adjustment

Engineering labour is often the assumption that reverses an attractive self-host calculation. Model onboarding, runtime security, GPU scheduling, performance tuning, endpoint reliability, evaluation, incident response and user support must have owners. The work may be distributed across ML engineering, platform engineering, site reliability, security, risk and procurement, which makes it easy to omit.

Use two labour views. The incremental view asks which new roles and hours the decision creates. It is useful for near-term cash planning. The fully allocated view assigns a fair share of platform and control functions. It is useful for comparing business units and avoiding an internal service that looks free until adoption forces another capacity and staffing step.

Managed APIs carry customer labour too. The organisation still owns application engineering, evaluation, access review, usage policy, provider governance and incident handling. Remove only the responsibilities genuinely transferred to the provider.

After an internal platform is built, a second error appears: the false marginal-cost trap. A team sees spare GPU capacity and prices the next workload near zero. That may be accurate for a short period, but sustained use brings the next capacity step, support demand and opportunity cost. Chargeback should show the near-term marginal cost and the longer-run replacement cost.

Cost per successful task beats cost per token

Token prices are observable, so they attract attention. They are also an incomplete denominator.

A cheap model can become expensive if it creates more invalid outputs, manual review, retries, customer remediation or control escalation. A high-priced model can be economically superior if it reduces those downstream costs. The direction can reverse again for a simple, high-volume task that a compact model handles reliably.

A more useful metric is:

quality-adjusted cost per accepted task = total run, platform, control and expected failure cost / accepted policy-compliant tasks

The numerator should include inference, platform, labour, evaluation, security and expected operational loss. The denominator should exclude work that times out, fails validation, breaches a policy or requires rerunning.

This turns model evaluation into economic measurement.

For a classification workload, the organisation might measure per-class precision and recall, calibration, abstention, schema validity, latency, cost and reviewer minutes. For extraction, it might use field-level correctness and invalid-structure rate. For cross-document reasoning, it might score evidence recall, citation support, unsupported assertion rate, expert-review outcome and time saved.

Public leaderboards remain useful discovery evidence. They are not procurement evidence. The decision suite should come from representative enterprise traffic, include rare high-cost failures and preserve a hidden holdout. Every model, prompt, retrieval index, quantisation setting and serving-engine change should create a new versioned result.

A hypothetical review-cost sensitivity

Consider a batch of 20 million records. Suppose 2 per cent of model outputs require five minutes of manual review. That creates 400,000 review events, or about 33,333 reviewer hours.

If a more expensive model cuts the review rate to 0.5 per cent, the workload creates 100,000 events, or about 8,333 hours. The difference is 25,000 reviewer hours.

These figures are intentionally hypothetical. They show why equal token volume does not mean equal economics. An organisation must substitute its own observed exception rate, handling time and loaded labour cost. High-severity failures should remain visible as separate scenarios rather than being hidden inside an average.

The correct metric is not the cost of attempting the task. It is the cost of completing it to the required standard.

Optimisation moves the curve, it does not remove it

The open-model discussion often treats technical optimisations as interchangeable discounts. They solve different problems and move different lines of the cost model.

RAG: current knowledge with an infrastructure bill

RAG is useful when knowledge changes and provenance matters. Instead of encoding every fact in model weights, the application retrieves relevant material at run time.

The economic benefit may include shorter prompts, more current answers and better evidence. The cost includes connectors, parsing, chunking, embeddings, index storage, incremental updates, access-control propagation, retrieval evaluation, citations and deletion. A retrieval failure can matter more than a small difference in generator quality.

Use RAG when the observed problem is missing or changing knowledge. Measure evidence recall, citation entailment, stale-document rate and unauthorised-retrieval tests. A small static knowledge base may be cheaper to handle with a curated prompt or deterministic lookup.

Fine-tuning: behaviour with a lifecycle

Fine-tuning can improve format adherence, classification boundaries, style or domain behaviour. It may reduce prompt length or allow a smaller model to perform a bounded task.

Its cost includes labelled examples, privacy and rights review, training experiments, registry, storage, serving compatibility, rollback and revalidation. It should answer a measured behavioural deficit, not compensate for missing current facts.

Quantisation: less memory, conditional quality

Lower-precision weights can fit a model on fewer or cheaper accelerators and raise concurrency. Primary research on AWQ, a hardware-friendly low-bit weight-only method, and QLoRA, which fine-tunes adapters through a frozen 4-bit base model, demonstrates important mechanisms. Production economics still depend on the exact checkpoint, kernel support, hardware, activation and cache behaviour, sequence mix and target-task quality.

The correct experiment compares cost per accepted task at the same quality threshold. Aggregate scores are not enough if a critical class regresses.

Serving software: same weights, different frontier

Serving engines can improve cache utilisation, batching and concurrency without changing the checkpoint. The PagedAttention paper describes block-based management of the key-value cache in vLLM to reduce memory waste. This is one reason raw parameter count does not determine service cost, but published throughput results remain configuration-specific rather than a production guarantee.

The model configuration should therefore include checkpoint, licence, precision, engine, prompt, retrieval corpus and evaluation result. Otherwise an apparent model comparison is an uncontrolled bundle.

Smaller models and distillation: bounded work first

Compact or specialised models are strongest where task boundaries and labels are stable. Classification, extraction and fixed-schema transformation are better candidates than ambiguous cross-document reasoning.

Distillation can transfer behaviour from a stronger teacher to a cheaper student, but teacher calls, data filtering, rights review, training and drift monitoring still cost money. An abstention path and a stronger fallback remain essential because distribution shift moves cases outside the student’s competence.

The recurring principle is simple: optimisation is evidence, not a promise. Test the exact workload and configuration.

The portfolio case: buy variability, build repeatability

For a heterogeneous enterprise, the durable answer is often a portfolio behind a common control plane.

A gateway can centralise identity, quotas, data-class policy, redaction, version pins, telemetry, cost attribution, response validation and fallback. It can expose a familiar application interface while preserving model-specific capability and control metadata.

Uber’s GenAI Gateway account describes a unified route to external and internally hosted models, with security review and central usage management. The strongest evidence is organisational. Teams do not each rebuild provider integrations, access policy and cost controls.

That does not mean every enterprise needs a learned router. Deterministic policy is the right starting point:

workload class;
data sensitivity;
required tools or modalities;
latency tier;
approved regions and retention modes;
maximum cost; and
materiality and review requirements.

A learned quality router should come later, once representative preference or correctness labels exist. RouteLLM reported more than twofold cost reduction in certain benchmark cases without quality loss. That is promising research, not a universal production discount. Routers can drift, add latency and misclassify the hardest cases.

Treat the router as a model. Version it, test it, record reason codes, monitor quality by route and define a fail-safe fallback.

Reversibility is an economic asset

A gateway reduces interface switching cost, but only part of it. Changing models also creates semantic cost, control cost and capacity cost. Prompts, tool schemas, context behaviour, refusals, retention eligibility and available quota can all differ.

An alternative route has option value only after it has been exercised.

Quarterly, an enterprise can shadow a representative traffic sample against a substitute model. It can verify legal deployability, capacity, data controls, task quality and operational runbooks. It can time the configuration change, rollback and any cache or index consequences. The measurable result is the fraction of traffic that can move within a defined period without unacceptable rework.

A provider name in an architecture diagram is not resilience.

This leads to a useful sourcing principle:

Buy variability, build repeatability and route uncertainty.

Buy managed capacity for workloads whose demand or capability needs change faster than the organisation can optimise infrastructure. Build or dedicate capacity for stable, high-volume work that passes a clear operating threshold. Route the uncertain middle, but pay for the evaluation and controls that make routing real.

A portfolio is not free. Multiple model paths create duplicated evaluation, contracts, observability and incident procedures. For a small number of homogeneous workloads, one approved provider may be rational. Portfolio architecture earns its cost when workloads differ materially, pooled demand improves utilisation or concentration and exit risk have measurable value.

The strongest counterarguments

The case for workload-level portfolios should survive the best arguments against it.

“APIs will always win because model prices keep falling.” Providers can pool accelerators efficiently, amortise operations and improve capabilities quickly. Falling token prices are real advantages. They do not settle every workload because control requirements, specialised latency, provider concentration and switching risk still matter. The practical response is not to predict a permanent winner. It is to refresh the comparison and keep application coupling low.

“Self-hosting always wins once volume is large.” Scale is necessary but not sufficient. Long contexts, uneven arrivals, multi-zone redundancy, tail-latency headroom, platform labour and quality differences can erase compute savings. Large pooled demand creates an opportunity to win, not a guarantee.

“Open weights guarantee transparency and sovereignty.” They improve deployability and inspectability, but training data and methods may remain opaque. Licences differ. Empirical behaviour still needs testing. Cloud self-hosting still depends on a third-party infrastructure provider. Sovereignty is a verified control map covering data flow, identity, logging, keys, retention, recovery and operators, not a label attached to the checkpoint.

“One frontier model is simpler to govern.” One provider reduces integration count and can be rational for a small, homogeneous workload set. It also concentrates dependency and makes simple work pay the frontier premium. A portfolio adds evaluation and incident paths. Its value depends on workload diversity and the materiality of exit.

“Routing complexity defeats the savings.” Sometimes it does. If routes cannot share a control plane, if traffic is too small to segment or if substitute models repeatedly fail the task suite, a single route is the better design. Routing should earn its place through measured savings, resilience or control value. It is not an architectural virtue by itself.

These counterarguments lead to a more disciplined conclusion. The portfolio is not the default because variety is fashionable. It is justified only when the economic and resilience value of workload-specific choice exceeds the recurring cost of operating that choice.

What this means for FX analytics

“FX” is not a useful model-selection category. Trade classification, liquidity analytics and complex investigation have different data, latency, materiality and failure costs.

Trade classification and enrichment

High-volume classification is the strongest candidate for deterministic rules or a compact model.

Begin with stable product, currency, venue and lifecycle mappings. Use a model where free text or ambiguity defeats the rules. Build a labelled set stratified by product, currency pair, desk, source system and rare exception. Measure per-class precision and recall, calibration, abstention, schema validity and reviewer minutes.

Batch enrichment can keep capacity productive and may favour managed open or self-hosted infrastructure. Interactive booking assistance has a different arrival pattern and latency requirement. It may favour a warm managed service or API even at the same monthly volume.

Where a field affects reporting, confirmation, settlement or risk, define whether the output is advisory or authoritative. Preserve the source text, model version and review outcome.

Liquidity analytics

Keep prices, spreads, depth, exposure and time-series calculations in validated analytical code. A language model can retrieve a methodology, explain a chart, compare documented definitions or investigate an exception. It should cite evidence and preserve the measurement window and product scope.

The BIS reported average OTC FX turnover of $9.6 trillion per day in April 2025. That establishes market scale. It does not establish an institution’s internal AI workload or return on investment.

Use permission-aware retrieval for policies and definitions. Evaluate evidence recall, numerical consistency, citation support and data entitlement. Do not ask a language model to substitute for the numerical engine.

Complex cross-document reasoning

A low-volume investigation may combine a policy, venue rule, trade history and market event. Strong reasoning capability may justify a frontier API or managed endpoint because dedicated capacity is difficult to keep productive.

The output should separate facts from inference, cite evidence, expose missing documents and route material conclusions to a human. Test conflicting policies, stale sources, long context, absent evidence and misleading user instructions.

Sensitive data or an established pooled platform can reverse the sourcing decision. That is precisely why the unit of analysis must remain the workload, not the department.

Governance survives the deployment choice

Self-hosting is not automatically compliant, and buying an API does not outsource accountability.

Managed providers document training, retention and network controls, but eligibility and exceptions vary by feature and contract. Self-hosting creates direct infrastructure control, while transferring patching, access, abuse monitoring, incident response and model lineage to the customer.

For specified in-scope UK firms, the current PRA SS1/23 applies model-risk principles across internally developed and external/vendor models. It does not follow that every LLM-assisted FX workflow is automatically a model under the statement. The organisation must classify the actual use.

The Bank of England and FCA’s 2024 survey provides the strategic counterweight. A third of reported AI use cases were third-party implementations, while the top three reported providers accounted for 73 per cent of cloud, 44 per cent of model and 33 per cent of data providers. The survey is UK-specific and self-reported, but it makes concentration and incomplete understanding visible.

The conclusion is not “build everything”. It is to put governance, validation, continuity and tested exit into every option’s economics.

A decision process executives can defend

A credible model-sourcing decision can be run as an eight-step exercise.

1. Define the workload boundary

Specify the task, users, input and output, materiality, data classes, arrival pattern and service level. Do not start with a preferred model.

2. Build a versioned evaluation set

Use representative traffic, labelled outcomes and rare high-cost failures. Define quality, latency, abstention, review and control thresholds before testing.

3. Establish a managed baseline

Test a proprietary API because it is usually the fastest way to observe real request shape and quality. Include application, evaluation and governance work that remains customer-owned.

4. Test one managed open and one self-hosted path

Use the same workload and quality threshold. Record checkpoint, precision, engine, hardware, region, batch policy and software version.

5. Build the TCO grid

Vary volume, useful utilisation, replicas, reliability, labour allocation, review rate and failure cost. Preserve both an incremental labour view and a fully allocated view. Report advantage regions rather than one break-even point.

6. Validate controls and operating ownership

Map data flow, retention, identity, logging, incident response, upgrade and rollback. Name the service owner, model owner, risk reviewer and finance owner. Stop if the organisation cannot assign the operating responsibilities implied by the option.

7. Shadow and rehearse the alternative

Route representative traffic without affecting production decisions. Verify capacity, controls and runbooks. Time failover and rollback. A substitute that cannot pass the task suite is not an exit option.

8. Approve workload-configuration pairs

Approve the specific workload, checkpoint, provider, precision, engine, retrieval corpus and policy. Re-evaluate when any material component changes.

The outputs should be concrete: a workload and data classification, a labelled evaluation set, a cost-and-control scorecard, and an operating runbook for abstention, escalation, incident and rollback.

The answer is a portfolio with proof

Open weights matter. They expand model choice, make some forms of optimisation possible and can shift control towards the enterprise. But they do not repeal the economics of infrastructure or the need for accountable operation.

The right answer may be a proprietary API for intermittent complex reasoning, managed open inference for a controlled checkpoint, self-hosting for stable high-volume classification and deterministic code for numerical analytics. A gateway can make those choices composable, provided the organisation is willing to govern the routes and test its fallbacks.

The economic winner is not the model with the lowest visible price. It is the operating model that delivers the required task at acceptable quality and risk, with an ownership structure the organisation can sustain.

Part 1 of this series established the changing open-model landscape. This second part has treated model choice as an economic allocation problem. Part 3 will address the harder consequence: once enterprises can mix providers, weights and routes, who is accountable for the system that results?