anomalyco / anomalyco/opencode

[FEATURE]: Publish exact model versions/checkpoints for Go plan models (e.g. whether deepseek-v4-flash serves 0731)

Open
#41,969 1 comment 0 reactions 1 assignee View on GitHub

@fwang is already working on this.

Since Aug 12, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
Avg merge
7h 2m
Merged PRs (30d)
384

Description

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Please document the exact model version/checkpoint that each model in the Go plan serves on the official site (https://opencode.ai/go and https://opencode.ai/docs/go/), and keep it up to date when a model is rolled forward.

Background

Today the Go plan pages only list model names like "DeepSeek V4 Flash" with no version information. But DeepSeek updated the same model ID deepseek-v4-flash from the initial preview to a new checkpoint DeepSeek-V4-Flash-0731 (formal version, 2026-07-31) without any public rollout notice from OpenCode's side. Users of opencode-go/deepseek-v4-flash currently have no way to tell which checkpoint they are being served and billed for, and behavior changes silently:

Request
  1. On the Go plan page / docs, show the exact served version for each model, e.g. DeepSeek V4 Flash — checkpoint DeepSeek-V4-Flash-0731 (released 2026-07-31).
  2. Add a version history / changelog per model so silent rollouts become visible (e.g. deepseek-v4-flash: preview → 0731 on 2026-08-XX).
  3. Ideally expose the served checkpoint programmatically (model metadata in /models or via the API) so it can be verified with a simple request instead of guesswork.
Benefits
  • Transparency: users know exactly what they are paying for, which matters for billing and quality expectations.
  • Easier bug triage: version info helps users report issues accurately and helps maintainers repro.
  • Avoids the repeated confusion seen in #39823 / #40409 / #40346.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.