The Commercial Inflection Point of Open-Source AI: From Selling Tokens to Selling Tasks

Over the past year, the pace of iteration in open-source large language models (LLMs) has been staggering. Parameter sizes, benchmark rankings, and API call volumes are constantly being broken. But looking past the technical metrics, a more fundamental question surfaces: how much actual revenue can this intensive rollout generate?

Usage metrics remain impressive. According to global AI model aggregation platforms, total global API calls in a recent week reached 188 trillion tokens. Among the top nine models called, Chinese models contributed a combined 93.54 trillion tokens, accounting for nearly half. This rising market share indicates that the rapid iteration on the technology supply side has translated into actual usage. However, a significant gap remains between “high usage” and “high profitability”—a commercial link that has yet to be fully bridged.

1. Bottlenecks of the Token Economy: Why “Selling Tokens” Is Increasingly Difficult

Token-based billing is currently the most mainstream business model for LLM services. The logic is straightforward: inputs and outputs are priced by volume, paying for what you use. In the early days of the industry, this model was highly effective because it broke down high inference costs into measurable units, lowering the barrier to entry for enterprises.

However, as open-source model capabilities converge and inference costs continue to fall, the unit price of tokens is depreciating rapidly. When the performance gap among multiple models on general tasks narrows to just a few percentage points, price wars become almost inevitable. More critically, there is a clear misalignment between token-based billing and the actual business value enterprises receive:

• Inconsistency between measurement and value units: Enterprises care about “completing a customer service dialogue,” “generating a compliance report,” or “fixing a code defect,” not about how many tokens were consumed.
• Unpredictable costs: For the exact same task, different prompt formulations can lead to a multiple-fold difference in token consumption, making budgets difficult to control.
• Decoupling of output quality and usage: Verbose but useless responses inflate the bill without improving business metrics.

In other words, the token is a measurement unit from a cost perspective, not a delivery unit from a value perspective. In an oversupplied market, continuing to focus on tokens will only trap providers in a cycle of “the more it’s used, the cheaper it gets, and the cheaper it gets, the less profitable it is.”

2. From Selling Tokens to Selling Tasks: The Core Logic of the Paradigm Shift

“Selling tasks” is not an entirely new concept. At its core, it shifts the billing anchor from resource consumption to result delivery. In this model, customers do not buy tokens; they buy a verifiable result: a successful function call, a structured data extraction, a code patch that passes tests, or a conversation that meets a satisfaction threshold.

This shift brings three fundamental changes:

First, the billing unit changes from “volume” to “occurrences.” For example, billing is based on “the number of document pages successfully parsed,” “the number of successful tool calls executed,” or “the number of unit tests successfully passed.” This unit aligns more closely with business language and makes budgeting easier to predict.

Second, quality becomes a prerequisite for billing. If a task is incomplete or the result is substandard, it should not be billed or should be heavily discounted. This forces service providers to invest in accuracy and robustness, rather than profiting off long, padded outputs.

Third, the competitive focus shifts from model capabilities to engineering capabilities. When billing is tied to results, success is determined not just by the base model’s benchmark scores, but by the entire engineering pipeline: task orchestration, tool calling, error retrying, and result validation.

3. The Three-Layer Technical Architecture Supporting “Selling Tasks”

To truly achieve task-based delivery, changes must be made across the billing, orchestration, and evaluation layers.

3.1 Billing Layer: From Counter to Ledger

Traditional token billing requires only a simple counter. Task-based billing, however, requires a task ledger that records the creation, execution, validation, and settlement status of tasks. Below is a simplified state machine illustration:

from enum import Enum
class TaskState(Enum):
    CREATED = "created"        # Task created, waiting for scheduling
    RUNNING = "running"        # Currently executing
    VALIDATING = "validating"  # Result validation in progress
    SUCCEEDED = "succeeded"    # Validation passed, billable
    FAILED = "failed"          # Execution failed, not billable
    RETRYING = "retrying"      # Retrying, temporarily not billable
# Pseudocode: Core logic for task settlement
def settle(task):
    if task.state != TaskState.SUCCEEDED:
        return 0.0  # No cost incurred if unsuccessful
    return task.unit_price * task.verified_units

The key takeaway is that the billing action occurs after validation, not after the model returns a response. This requires the system to automatically validate task results, using methods such as schema validation, unit testing, rule engines, or manual sampling reviews.

3.2 Orchestration Layer: Upgrading “A Single Call” to “A Workflow”

A single model call rarely guarantees task success. Therefore, an orchestration layer is required to combine multi-step operations: intent recognition, tool calling, result aggregation, and failure retries. A typical task orchestration flow looks like this:

def run_task(task):
    plan = planner.decompose(task.input)
    results = []
    for step in plan.steps:
        for attempt in range(MAX_RETRY):
            output = executor.run(step, context=results)
            if validator.check(step, output):
                results.append(output)
                break
        else:
            return TaskResult(state=TaskState.FAILED)
    return TaskResult(state=TaskState.SUCCEEDED, data=aggregate(results))

The value of the orchestration layer lies in locking away uncertainty. Regardless of how much the underlying model fluctuates, what the upper layer delivers is always a validated, stable result. This is the prerequisite for service providers to make promises about task quality.

3.3 Evaluation Layer: Criteria for Task Success

The biggest challenge in task-based billing is how to define acceptance criteria. Different task types require different validation strategies:

Task Type	Validation Method	Billing Unit Example
Structured Extraction	Schema validation, field completeness	Number of records successfully extracted
Code Repair	Unit test pass, static analysis	Number of test cases passed
Customer Service Dialogue	Intent fulfillment, satisfaction score	Number of successfully resolved sessions
Document Generation	Template compliance, factual consistency	Number of approved documents

The maturity of the evaluation layer directly determines whether task-based billing can scale. Without reliable automated acceptance, task billing can only remain in small-scale, custom deployment stages.

4. Practical Impact on Developers and Enterprise Users

For developers, task-based billing means API design needs to be rethought. In the past, APIs exposed “completion endpoints”; in the future, they will need to expose “task submission endpoints,” equipped with capabilities to query task status, retrieve validation results, and handle failure retries. This aligns more closely with the asynchronous task models of traditional cloud services.

For enterprise users, procurement logic will also shift. Moving from “buying X tokens” to “buying X successful tasks” links budgets directly to business metrics, making ROI easier to calculate. However, it also requires enterprises to clearly define their own acceptance criteria; otherwise, “task success” will be difficult to define.

5. The Competitive Landscape After the Inflection Point

As the billing anchor shifts from tokens to tasks, competitive barriers also transfer:

• Model capability remains foundational, but is no longer the sole deciding factor;
• The engineering pipeline becomes a core asset, including orchestration, retries, validation, and observability;
• Industry knowledge becomes a source of differentiation, because acceptance criteria are often highly specific to the business;
• Cost structures change, where inference cost is only part of the total cost, and validation and retry costs must be incorporated into the model.

It is foreseeable that the winners in the next phase will not simply be the service providers with the “cheapest tokens,” but those who can stably deliver verifiable tasks at predictable prices. Open-source models have lowered the technical barrier, but the engineering barrier for task delivery is actually higher. This is the true meaning of the commercial inflection point.

Moving from selling tokens to selling tasks is essentially a transition from “selling resources” to “selling results.” This path is not easy, but for the first time, it aligns the commercial value of large models with actual business value. For developers and enterprises, the earlier they understand and adapt to this shift, the more likely they are to gain the upper edge in the next round of competition.