Replies: 21 comments 7 replies
|
we started looking for the deepseek header that has this info so it should be ok |
|
Update from our telemetry: we can now see the session header when it arrives, and the picture is model-specific. muse-spark-* requests arrive with session context 74-90% of the time, but deepseek-v4-flash is at ~2.5% and mimo-v2.5 / glm-5.3-flash / everything else are near 0%. Flash is your highest-volume model through us, so that is where most of the breakage will land on 09/06. So the ask narrows: whatever attaches the session header on the Spark-serving path needs to run on all provider adapters, not just that one. Happy to re-measure the moment a build ships it. |
|
even if telemetry sounds bad, i think it allowed you to jump from 30-60tps to 120-190tps for glm5.3-flash(?) which is crazy work - assuming it's really for better routing (more cache hits and less rejections?) it's likely worth it. Assume: the hard deadline will break user environments, since DSH is still WIP Allowing a bit more generous breakage deadline would be appreciated (likely reason for current downvotes) |
Proposed Fix:
|
|
How interesting, would it solve opencode's own problem of reducing intelligence? Why should we have to adapt to it for this |
|
I am trying to use my opencode go sub with deepseek harness and I get this error: Is that related? @thdxr. By the way, the sub works perfectly in claude code |
|
Following this thread's requirement (in effect from 09/05): I implemented The header is injected at the chat call site from the per-conversation session id, gated like the official client ( Two scope notes: (1) this currently covers all |
|
Discovery probes are untouched. The branch is ready at |
|
Hi @thdxr thanks for the report. Does it make more sense for the pi-ai package to include this header when it's configured to use the OpenCode Go provider? It is supposed to be that package that handles and normalizes all the providers particular needs. |
|
他们那边应该会把这个功能放进 Pi AI 里 |
|
A config-driven implementation: Following tianyicui's point that the pi-ai package should normalize provider particulars, we implemented this as an explicit, opt-in profile field rather than a route-name gate, converging with RaulLazaro's proposal: providers:
opencode-go:
sessionHeader: x-opencode-sessionHow it works: the adapter already threads Why not pi-ai's Context: we run DeepSeek Harness daily on Windows against the OpenCode Go/Zen gateways (28 Go models, 7 free, plus dedicated Branch: Separately: we also have a proposed write-validation rule for agent edits to |
|
在settings.yaml中添加headers，即可解决（在deekseek harness中错误下面改用deekseek v4 flash模型解决） |
|
增加了header后,调用慢了不少,并且花费更高了好像 |
|
他这种方法是固定了会话id，也就是你在dsh中如果切换会话，但是opencode那边还是认为你的id不变。这样自然造成缓存失效，费用升高 |
|
Fix verified — proposed patch for Root cause confirmed locally: DSH's request path ( We patched { "n-session": sessionId, "n-client": "deepseek-harness", "x-opencode-session": sessionId }Both header sets are sent for belt-and-suspenders coverage of native-header recognition and the public contract. Verified end-to-end: reproducible Suggested upstream fix (≈10 LOC): port pi's |
|
Just to unlock temporarily the situation And asked it to crawl this issue page and find a fix But the dsh team should come with a clean solution |
|
Status report: A brief update from our side, now that the deadline has passed and the thread has heated up: 1. In production since Sep 5, no errors and no cost anomaly. Our deployment has been running the 2. On the cost reports after the static header (downnititiffany-spec and z3347212573-cloud): your diagnosis is correct, and this is exactly what a per-conversation id avoids. A fixed value collapses every conversation into one affinity bucket: switching sessions in DSH still points at the same replica with different prefixes, so cache locality degrades as you observed. The 3. Data for the clean fix (lws2004, good find). We verified by direct probe, before the deadline, that the gateway accepts Branch: |
|
Independent confirmation on Route: Local change in { "x-opencode-session": sessionId, "n-session": sessionId, "n-client": "deepseek-harness" }After restart, the same sessions proceeded (tool calls / completed turns). Remaining Happy to treat |
|
We hit this too and have a working local implementation you may want to adopt or adapt (external PRs are currently not accepted per CONTRIBUTING.md, so sharing the details here). Root cause: pi-ai does not send any What we did (all inside the
Validation: llm-pi-ai unit suite 291/291 green; full repository Reference branch (two commits):
Happy to reshape this however the team prefers — e.g. as an |
|
Work perfectly, thanks! |
|
Hi, I’m using DeepSeek‑Harness to call your API, and as you’ve noted, it currently doesn’t include the x‑opencode‑session header. But DeepSeek‑Harness is still under active development. Setting a hard deadline with such short notice is unreasonable – it breaks my integration, which is why I’m here commenting. It would be much more sensible to wait until the harness officially adds support for that header before enforcing the change, rather than forcing users to patch or adapt the tool themselves. |
|
Your behavior is disgusting, strongly support dsh not adding this feature. If you love playing with it yourself, just go ahead and play. |
Don't flatter yourself — my reply has nothing to do with yours. |
|
遇到同样的问题（OpenCode Go 从 09/05 起要求每个推理请求带稳定的 我写了个插件 安装（需要完全重启 dsh 生效）： 启动日志出现 期待官方内置按会话的 English: Same problem here — OpenCode Go requires a stable
Install (a full dsh restart is required): Startup log should show Looking forward to the official per-conversation |
|
opencode 对于deepseek官方的会话id是认的（x-deepseek-harness-session-id），但是dsh只会对自家api请求时，会在请求头加上会话id（x-deepseek-harness-session-id），对于其他厂商的并不会加。所以对其他模型厂商也加上此id即可。 |
|
DSH is already open enough. This kind of one-sided adaptation demand should be implemented on your own side and offered to your users — not pushed onto others to implement. If OpenCode Go needs a stable per-conversation ID for routing, nothing stops you from accepting any stable session header (you already recognize DSH's own x-deepseek-harness-session-id) or shipping an adapter/gateway-side shim yourselves. Demanding that another project hard-modify its outbound requests on a 2-day notice, breaking ~25k of your own customers, is not how open ecosystems work. To be clear: what people are pushing back on is not the header itself — it's the unilateral hard deadline and the "you must adapt" framing. |
|
An in-repo precedent for the design question Verified fact on current master (included in the 0.1.3-alpha.2 release train): the dedicated official-DeepSeek-API adapter already implements the exact pattern this thread is discussing. In options.sessionId !== undefined
? { 'x-deepseek-harness-session-id': String(options.sessionId) }
: {},So "send the conversation id under a header the provider recognizes" is already shipped harness behavior for the DeepSeek provider. And two comments in this thread (z3347212573-cloud and n-pll) report that your gateway already recognizes exactly that header. This answers tianyicui's open design question with in-repo precedent: yes, normalizing each gateway's particularities belongs in the harness's provider package, because The community patches keep converging on the same shape (nobu121's Branch: |
|
If you need an immediate infrastructure-level fix for these 400 missing x-opencode-session or MissingSessionID errors, you can route your traffic through this fork of Aurora Gateway. Its Session Hub (map mode) automatically transforms faulty, missing, or volatile headers from local clients into stable outbound x-opencode-session tokens, preventing 400 drops and preserving your Prompt Cache. Fully open-source and Docker-ready: https://github.com/entitybtw/aurora |
and others
Uh oh!
There was an error while loading. Please reload this page.
Hi - we operate the OpenCode Go managed-inference API, and about 25k of your users orgs call it through deepseek-harness. Starting 09/05, requests without an x-opencode-session header will error on our side (we need a stable per-conversation ID for routing and optimization). We measured all recent harness versions at near-zero header presence, so harness users on Go will break. Ask: include x-opencode-session set to a stable UUID per conversation on all outbound inference HTTP requests. Happy to confirm from our telemetry once a build ships it. Thanks!
All reactions