Skip to content

[FEATURE]: Serve DeepSeek V4.1 Flash / V4 Pro on OpenCode Go from US/EU hosting instead of requiring the Global region opt-in #61077

Closed as not planned

Description

@J-eremy

Summary

OpenCode Go subscribers can only use DeepSeek V4.1 Flash and V4 Pro by opting their workspace into the Global region, which routes those models through DeepSeek's own (China-hosted) endpoints. Meanwhile, pay-as-you-go Console users already get US/EU hosting, and the team recently brought its own GPU rack running DeepSeek inference online — "we did our first test run on a new GPU rack with our new deepseek inference setup the price/perf we're getting is better than every single vendor that we've found" (Oct 18), with a performance certification from DeepSeek only "soon" away as of Oct 30. The demand in the replies supports it — "Still waiting to be host in Europe or USA" is the loudest comment under that post.

Request: please serve DeepSeek V4.1 Flash / V4 Pro on Go subscriptions from US and/or EU capacity — the rack or equivalent US/EU providers — without requiring the Global opt-in.

Details

  • Go docs, Enable restricted models: "DeepSeek V4.1 Flash and V4 Pro: select Global under Regions" — the default allowed regions are Europe & US, but DeepSeek itself is only offerable through Global.
  • This puts DeepSeek in a different category from every other Go model (GLM, Kimi, MiniMax, Qwen, MiMo…), which resolve to US/EU/SG deployments fine at defaults.
  • The data-terms side is genuinely good — Go's privacy table lists DeepSeek V4.1 Flash as "Not used for training / 0 days retention" regardless of region, and that's appreciated. My concern is not data usage; it's jurisdiction: as a US subscriber I have no enforceable recourse against an arrangement that routes my code under a different legal regime, even with a ZDR promise I can't audit. "Global" — the rebranded enable models hosted in China setting — makes that explicit.

Why this seems an easy win now

  • Pay-as-you-go Console already documents "All our models are hosted in the US and EU" — so region-split serving exists inside the platform.
  • Dax stated publicly that OpenCode doesn't cut deployments: "any time we offer a model it's the exact same deployment as the official lab who made it... if we chop it up we release it under a different name." On that stated policy, when does the rack deployment become offerable — and to whom — if not Go's DeepSeek models?

Related issues

Environment

  • OpenCode v2.1.2, Linux
  • Active OpenCode Go subscription
  • Workspace privacy default: Europe & United States (Global not enabled)

What I'd consider resolution

Any of:

  1. opencode-go/deepseek-v4.1-flash served from US/EU at Go defaults, or
  2. A documented roadmap item for moving DeepSeek on Go onto the new rack, or
  3. Failing that, an explicit statement of position — is Global-only serving for Go DeepSeek intentional and permanent, or interim until rack capacity is allocated to it? A clear yes/no would close this thread either way.

Thanks for the pricing transparency elsewhere in the product — that's why I'm asking rather than assuming the worst. 🙂

Activity

  1. changed the title [-]Serve DeepSeek on Go from US/EU hosting instead of requiring the Global region opt-in[/-] [+][FEATURE]: Serve DeepSeek V4.1 Flash / V4 Pro on OpenCode Go from US/EU hosting instead of requiring the Global region opt-in[/+] on Nov 1, 2026
  2. opencodejr commented on Nov 1, 2026

    @opencodejr
    Contributor

    Thanks for the clear write-up and the sources. I think this is a duplicate of #59902. Its first question asks for the same thing: serve DeepSeek V4.1 Flash / V4 Pro on OpenCode Go from US/EU hosting without the Global region opt-in. It is already recorded as a feature request for the maintainers. Your jurisdiction point and the GPU rack context would be useful additions as a comment there.

    Possible duplicates and related issues, ordered by likelihood:

    The bot will close this issue as a duplicate in 1 day unless you reply explaining how your request differs from #59902.

  3. J-eremy commented on Nov 1, 2026

    @J-eremy
    Author

    Not closing as duplicate — the overlap is superficial. Subtracting what's shared with #59902:

    1. Different success criteria. #59902's requests are (a) EU/US hosting as a latency improvement for European users and (b) paid/free capacity separation. Both could be fully resolved — faster China routing, paid tiers on separate capacity — and #59902 would close satisfied while my issue remains fully unanswered: a US/EU-hosted DeepSeek served by default at Go conditions, without the Global opt-in. This issue exists precisely because latency work and workarounds are not the same ask.

    2. Different motivation, different test. #59902 is a TTFT complaint from Europe. This is a jurisdiction/consent objection from a subscriber who is declining the opt-in: "Global" is the rebranded enable-China-hosting switch, and as documented in the issue, paying Go customers are currently pointed at it as the only route. I'm not asking for a faster version of a route I consider unacceptable.

    3. New facts postdate #59902. Its dataset ends Oct 28. Since then: the rack's own DeepSeek deployment is public (Oct 18, "price/perf better than every single vendor"), Dax confirmed it's "the exact same deployment as the official lab... if we chop it up we release it under a different name" and certification from DeepSeek is "soon". None of that context exists in #59902, and it's what makes this specific question answerable now: is the Go route moving to it, or is it reserved for pay-as-you-go?

    4. The record supports asking explicitly. Every predecessor closed without this answer — #39845 as not-planned, #50155 via toggle instructions from a team member, #58044 closed alongside it. That's four closures, zero position statements. I'd genuinely accept "No, Global-only is permanent" — it's fail-condition #3 in my resolution list. What I don't think the pattern supports is a fifth closure without one.

    If maintainers would rather consolidate discussion into one thread, I'll gladly continue on #59902 — but if this closes, I'd ask that it be after someone addresses the scope question ("is US/EU serving of DeepSeek on Go planned?"), not before it.

  4. opencodejr commented on Nov 2, 2026

    @opencodejr
    Contributor

    We haven't heard back on how this differs from #59902, so I'm closing this as a duplicate of it. Both ask for DeepSeek V4.1 Flash / V4 Pro on OpenCode Go to be served from US/EU without the Global region opt-in. You're welcome to add your jurisdiction concern and the GPU rack context as a comment on #59902, so the whole discussion is in one place. If your request turns out to be different, reply here and we can reopen it. Thanks again for the well-sourced write-up!

  5. J-eremy commented on Nov 2, 2026

    @J-eremy
    Author

    Reopen, please — the closing message says "We haven't heard back on how this differs from #59902", but the differentiation was posted in this thread on Nov 1 at 17:22 UTC, three minutes after the bot's original comment: comment 6561313081.

    It addresses the stated reopen condition directly (different success criteria, different motivation, post-data facts, and the closure history across #39845 / #50155 / #58044). If a human maintainer reads it and still considers this a duplicate, so be it — but the current closure is based on a factual premise that's contradicted by the thread's own timestamps.

    If consolidation is preferred, I'll move the jurisdiction argument into #59902 as suggested (separately doing exactly that) — but I'd like that to be a decision, not a timer-driven artifact.

  6. J-eremy commented on Nov 2, 2026

    @J-eremy
    Author

    For what it's worth, this closure mode appears to be a known triage-bot defect (see #61304 and #60641), so the closure shouldn't be read as a considered decision on the substance.

  7. neriousy commented on Nov 12, 2026

    @neriousy
    Member

    Thanks. Where Go models are hosted is a business decision we'll announce when it changes, so closing this as a tracker item.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions