Shared Foundation, Tiered Delivery: How Frontier LLMs Are Shipped Through a Dual-Track Model

Background: When Capabilities Go Live, the Weights Are the Easy Part

In June 2026, a frontier model lab publicly released a new generation of models, developed internally under the codename Capybara. The models were delivered in two forms:

• a public version open to consumers and enterprises, positioned at the time as the most capable model available to the general public;
• a restricted version for specific institutions that have passed vetting, with looser safety limits.

This capability tiering is known in the industry as “Mythos-class” tiers.

Developers should care less about the version names than about the engineering reality they expose: how capability is supplied is changing from “ship a model” to “ship a policy-driven capability channel built on a shared foundation.” A single set of weights is wrapped in different safety layers to create a public track and a controlled track. As a result, what model adopters have to handle has grown from “calling an inference API” into four concerns at once: choosing the right track, designing the policy layer, controlling costs, and meeting data retention requirements.

This article looks at the approach from four angles:

• what the dual-track model really is;
• how to read benchmark scores correctly;
• how to run long-horizon software engineering tasks in practice;
• how enterprises integrate and govern these models.

How the Dual-Track Model Works: One Base, Two Layers

A Shared Base

The public and restricted versions run on the same underlying model. In engineering terms:

• Same ceiling. Reasoning ability, coding ability, and context-processing specifications come from the same pretraining and post-training pipeline. The public version is not a cut-down model.
• The difference is in the inference path. System prompts, refusal policies, content filters, the set of available tools, and whether the raw model can be deployed in a customer’s own environment set the two versions apart.
• Evaluation carries over. Prompt engineering, tool orchestration, and evaluation sets built for the public version usually transfer directly to the restricted version. The only adjustment typically needed is recalibrating refusal thresholds.

Common Forms of Safety Guardrail

Spelling out what “stricter” and “looser” safety limits mean, they usually come down to a handful of controls:

1. Refusal policy: the threshold for refusing high-risk requests, such as weapons, malicious code, and mass surveillance.
2. Capability gating: restrictions on advanced capabilities that can be invoked externally, such as long autonomous runs and unsupervised tool calls.
3. Tool and permission allowlists: the restricted version can be connected to more external actions, such as running a shell, modifying repositories, and calling internal systems.
4. Deployment form: the public version is available only through a hosted API, while the restricted version can be deployed privately so that data stays within the organization’s perimeter.
5. Identity and audit: institution vetting, access approval, and end-to-end logging that is retained and traceable.

Why Gate Capabilities Instead of Shipping a Weaker Model

A common misconception is that the safety-constrained version is simply a less capable model. In practice, risk management moves from the weights to runtime. The upside is that only one base model has to be maintained, which keeps iteration costs low. The downside is that the policy layer becomes a new attack surface and a new operational responsibility, so it needs its own audit and canary-release mechanisms.

How to Read the Benchmark: What 80.3% Actually Means

According to public information, this model family reaches an 80.3% resolution rate on mainstream software engineering benchmarks. The tasks are bug fixes in real code repositories, and the model has to produce a patch that passes the tests. This number deserves careful interpretation.

Three Discounts on Leaderboard Scores

• Contaminated evaluation sets. Problem descriptions and reference patches from public benchmarks may already be in the training data, so inflated scores are common. The industry-standard safeguard is a second round of validation on a privately constructed task set.
• One sample vs. many attempts. Allowing multiple tries and keeping the best result (pass@k) can score more than 10 percentage points higher than single-shot generation that must pass on the first attempt (pass@1).
• High verification cost. When 80% of tasks pass the tests, the remaining 20% are usually the hardest. They most often need human judgment and involve architecture-level changes rather than local fixes.

Error Decay in Long-Horizon Tasks

What truly separates models in software engineering is long-horizon work: tasks that take tens to hundreds of steps, span multiple files, and depend on feedback from the environment. These tasks follow one unforgiving rule:

Single-step success rate p = 0.99 -> 100 consecutive steps without error: 0.99^100 ≈ 0.366
Single-step success rate p = 0.95 -> 100 consecutive steps without error: 0.95^100 ≈ 0.0059

A single benchmark score therefore cannot predict end-to-end task completion. To measure long-horizon reliability, you need end-to-end metrics: task completion rate, average number of human interventions, and rollback rate.

Building an Internal Eval Suite: The Minimum

# eval-suite.yaml: structure of an internal software engineering eval suite
suite: repo-migration-v1
tasks:
  - id: migrate-http-client
    type: api-replacement          # replace an API
    repo_snapshot: sha256:9f2c...  # pin the repository snapshot for reproducibility
    acceptance:
      unit_tests: pass
      integration_tests: pass
      forbidden_files_changed: 0   # constrain the scope of changes
    scoring:
      pass@1: true
      max_attempts: 3
    isolation:
      network: disabled
      toolchain: pinned            # pin dependency versions to rule out environment drift
metrics:
  - task_success_rate
  - avg_human_interventions
  - token_cost_per_task
  - rollback_rate

The key design choices are a pinned repository snapshot, a locked toolchain, networking disabled, and clear acceptance criteria. Without them, results cannot be reproduced or compared across versions in a regression check.

Running Long-Horizon Software Engineering: A Repository Migration Case

One notable capability claim from the original information is a repository migration that would have taken a team about two months, completed by this class of model in a single day. Such a case has more engineering value than a leaderboard score because it translates directly into measurable cost savings. Reproducing this kind of result consistently requires breaking the work down as an engineering process.

Why Migrations Are the Ideal Proving Ground

Repository migrations have four characteristics that fit the long-horizon strengths of large models:

• Highly repetitive patterns: thousands of similar changes that are tedious and error-prone for people.
• Objective acceptance criteria: it compiles, tests pass, behavior is unchanged.
• Divisible work: progress can proceed in batches by module, directory, or dependency layer.
• Manageable risk: changes can be merged incrementally and rolled back at any time.

A Five-Step Engineering Process

1. Define machine-verifiable goals. Write the post-migration contract tests or type constraints first, then let the model change the code. Acceptance criteria have to be executable assertions, not “looks right.”
2. Order work by dependency topology. Migrate the foundational layers that other code depends on first, then the callers above them. This avoids widespread build failures halfway through.
3. Work in small batches on separate branches. Each batch gets its own branch, its own review, and its own CI run, so a failure affects only a small part of the codebase.
4. Make the human-machine division clear. The model handles bulk replacements and boilerplate. People handle architecture decisions, boundary semantics, and final sign-off.
5. Review by sampling, not line by line. Combine sampled review, static checks, and a coverage threshold to keep the review cost of highly repetitive changes under control.

Comparing Real Cost With Engineering Hours

“Two months for the team vs. one day for the model” counts only the gross savings. The real balance sheet looks like this:

Net benefit = labor cost saved
            - model inference cost (token-based billing)
            - verification cost (CI time, compute)
            - manual review and rework cost
            - expected loss from defects introduced by the migration

The “manual review and rework” line is routinely underestimated. A common rule of thumb is to budget 20%–30% of total engineering time for reviewing automated changes. For high-risk semantic-equivalence changes such as concurrency, serialization, and time handling, require a full human review.

Assigning Migration Tasks: A Sketch

# Migration orchestration skeleton: batching + verification + rollback
def run_migration(module_list, agent, verify, max_attempts=3):
    results = []
    for module in topo_sort(module_list):          # process in dependency order
        branch = create_branch(f"migrate/{module}")
        for attempt in range(1, max_attempts + 1):
            diff = agent.propose(module, branch)   # model produces the patch
            if verify(diff):                       # build + tests + static checks
                merge(branch)
                results.append((module, "ok", attempt))
                break
        else:
            results.append((module, "needs_human", max_attempts))
            open_review_request(module, branch)    # escalate to a human as a fallback
    return results

The key rule is that a failure goes to a human automatically instead of triggering endless retries. In long-horizon work, unbounded retries become a black hole for cost.

Integration and Governance: Model Gateway and Policy Layer

For enterprises, the standard way to adopt a dual-track model is to build their own model gateway that centralizes track selection, policy enforcement, and audit logging in one place.

Four Responsibilities of the Gateway

• Routing: pick the public or restricted version based on how risky the task is. High-risk or confidential work goes through the private deployment channel.
• Rate limiting and quotas: allocate token quotas by team or project so a single job cannot use up all the capacity.
• Data boundaries: track which request content is allowed to leave the corporate network. Sensitive data must be redacted or processed locally first.
• Audit trail: log request metadata, policy decisions, and model versions in full, so activity can be traced after the fact and compared across versions.

A Sketch Implementation

POLICY = {
    "public_tier": {
        "deny_topics": ["weapons", "malware", "mass_surveillance"],
        "max_context": 200_000,
        "data_retention_days": 30,       # gated models usually require retention; zero retention is not supported
    },
    "restricted_tier": {
        "deny_topics": [],
        "require_approval": True,
        "deploy_mode": "private",        # customer's own environment
    },
}
def dispatch(request):
    tier = "restricted_tier" if request.data_class in ("secret", "pii") else "public_tier"
    cfg = POLICY[tier]
    hit = guard.scan(request.prompt, cfg["deny_topics"])
    if hit:
        return reject(request, reason=hit)           # policy blocks the request up front
    if request.data_class in ("secret", "pii"):
        request = redact(request)                    # redact before data leaves the network
    return client.call(request, context_limit=cfg["max_context"], tier=tier)

The gateway also has another important job: pinning every version to an evaluation gate. Each time the base model is upgraded, run a regression check against the offline evaluation suite first. Roll out gradually only after the metrics meet the bar. This prevents “upgrade equals incident.”

Four Levers for Cost Governance

Under token-based usage pricing, cost governance has to be designed in advance rather than reviewed after the bill arrives:

1. Context trimming: inject only relevant snippets through retrieval instead of stuffing in whole documents.
2. Prompt caching: reuse cached stable content such as system prompts and long document prefixes, which cuts repeated charges significantly.
3. Tiered model routing: send routine batch tasks to smaller models and reserve flagship models for complex reasoning.
4. Offline batching: run non-real-time jobs through an asynchronous queue so they consume capacity during off-peak hours.

On cloud platforms such as Baidu AI Cloud, these capabilities are typically provided by general-purpose components. Object storage holds corpora and outputs, message queues absorb spikes in offline jobs, and logging services together with monitoring and alerting handle audit trails and cost dashboards. On the model side, the platform mainly handles capacity elasticity and billing. Teams do not need to build the entire infrastructure stack themselves.

Commercialization and Compliance: Metered Billing and Retention Limits

Two operational details from the original information are worth looking at more closely, because they directly affect architecture choices.

Metered billing. Compared with a monthly subscription, usage-based billing ties the cost of batch migration work directly to actual consumption. The downside is that costs fluctuate and there is no built-in budget cap. Engineering countermeasures:

• set hard per-project token budgets;
• automatically fall back to smaller models when a budget is exceeded;
• require approval for overspending jobs.

Once capacity is in place, moving back to a subscription is a common path for high-end models of this kind. Subscriptions suit a stable baseline workload, and metered billing suits burst batch processing, so the two can be combined.

Retention and compliance constraints. This class of model is designated a “gated model” that requires 30 days of data retention, and zero-retention configurations are not supported. This constraint overturns several common design assumptions:

• You cannot assume requests are discarded on arrival. Sensitive data must be redacted before it leaves your network rather than relying on the service provider not storing it.
• Audit, forensics, and compliance checks need log archiving and search built around a 30-day window.
• Scenarios that involve data under strict regulation should use the private deployment channel, so the retention boundary stays in the enterprise’s own hands.

Recommended Rollout Path

1. Build the eval set before choosing a model. Choosing a model without a private evaluation set is a shot in the dark. Cover at least three task types: local bug fixes, cross-file refactoring, and long-horizon migrations.
2. Validate one task first. Start with a pilot that is highly repetitive and has objective acceptance criteria, such as a migration task. Collect real end-to-end data on completion rates and human interventions.
3. Put the gateway in place first. Have policy enforcement, redaction, rate limiting, and audit logging ready on day one of integration. Don’t add them after traffic starts.
4. Launch cost dashboards and budget guardrails at the same time. Break token consumption down by project and team, and set hard limits and fallback policies.
5. Keep human sign-off authority. Architecture-level changes, semantic-equivalence decisions, and security-related code must be confirmed by a person.

Conclusion

Sharing one base model while delivering capabilities in a public tier and a controlled tier moves risk management from the model weights to a runtime policy layer. For developers, this leads to three conclusions:

• Benchmark scores are only an entry ticket. End-to-end long-horizon reliability is the metric that matters in production.
• The bottleneck for putting capabilities to work is usually acceptance criteria and engineering process, not the model itself.
• Non-model factors such as billing, data retention, and capability gating deserve the same seriousness as model selection.

Get evaluation, the gateway, cost, and compliance right, and frontier capabilities can genuinely turn into sustainable engineering output.