refactor(opencode): normalize legacy pricing into tiers

[opencode-agent]

Summary

• keep all existing config, API, plugin, and SDK pricing contracts unchanged
• normalize models.dev/config context_over_200k into an internal 200k context tier only when no explicit tiers exist
• prefer explicit model and mode tiers when both forms are present, preserving model-specific thresholds
• make session cost calculation read only internal cost.tiers
• preserve catalog tiers when provider configuration overlays a model
• derive the existing experimentalOver200K compatibility output only at the public projection boundary

Compatibility

No external schema changes. Existing config continues to accept context_over_200k, and API/SDK consumers continue to receive the existing compatibility field. Internal provider/session pricing uses tiers exclusively.

Scope

Only packages/opencode runtime and tests. No packages/core, models.dev, config-schema, SDK, or OpenAPI changes.

Testing

• config compatibility and provider tier-preservation tests
• models.dev legacy normalization and explicit-tier precedence tests
• internal-vs-public compatibility projection test
• session tier-selection tests
• SDK typecheck against the unchanged external contract

Requested by: @rekram1-node (Aiden via Slack)

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

Consolidating on tiers and deleting the two parallel legacy paths is the right direction — one pricing mechanism, one fallback rule, and the updated tests now document the new semantics explicitly. A few things worth nailing down before merge:

1. Silent cost regression for models that only had legacy >200k pricing. After this change, getUsage (packages/opencode/src/session/session.ts, ~lines 380–383) falls back to base cost when no context tier matches. Two sources of models previously covered by the legacy fields:

   • User configs still containing context_over_200k: with the field gone from ConfigProviderV1.Model (packages/core/src/v1/config/provider.ts), please confirm whether decoding strips it silently or fails validation — a hard error would break existing setups, a silent strip quietly re-prices long-context requests at base rates. If it's the latter, a deprecation warning during config load would soften the landing.
   • Upstream models.dev data: if any catalog entry still carries only context_over_200k (not tiers), the conversion in packages/core/src/plugin/models-dev.ts now drops it entirely. Worth verifying upstream has fully migrated those entries to tiers before this ships, or accepting the temporary regression knowingly.

2. Overlay asymmetry between base cost and tiers. The new preservation line (packages/opencode/src/provider/provider.ts, ~line 1514) keeps catalog tiers when user config overlays a model — good for the empty-override case in the new test. But the inverse has no escape hatch: config can replace base input/output yet can neither supply its own tiers nor clear inherited ones. A user pointing a model at a flat-rate proxy ends up with custom base pricing above 200k switching back to catalog tier rates mid-request. Consider allowing tiers in config cost, or an explicit way to reset them.

3. Test nit (packages/opencode/test/provider/provider.test.ts, "model config preserves catalog cost tiers"): asserting exact tier literals pins the test to today's catalog numbers. More robust: fetch the un-overlaid catalog model first and assert the overlaid one's tiers deep-equal it — same guarantee, zero churn when models.dev updates.

Otherwise the removals are consistent across schemas, conversions, OpenAPI, and SDK types — nice, thorough sweep.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.