You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Send x-opencode-session header on API requests (required by OpenCode Go from 09/05) #3506
Hi — we operate the OpenCode Go managed-inference API, and 836 of your users' orgs call it through Kimi Code CLI (UA kimi-code-cli/0.39.1).
Starting 09/05, requests without an x-opencode-session header will error on our side — we need a stable per-conversation ID for routing/optimization. Kimi Code CLI doesn't send it in any version we've seen.
Ask: include x-opencode-session: <stable-id-per-conversation> on all outbound inference HTTP requests. Any stable UUID per conversation works. Happy to confirm from our telemetry once a build ships it. Thanks!
Reacted by pixelpaws, Xiaowen.Z, Yan, safecodee, Danta1ion, cbubs, waterwu, Lu Wang, Pifenggg, nothankyou and 5 more
Reacted by xuruizhe891, Aries2050, Ivan Nikulin, ZHAO Jin-Xiang, Thomas Germer, Noblet Ouways, LJF-0125, Alan Chen, Xenos Tian, Lei Fu and 6 more
Thanks for flagging this, and for the detail on your routing requirements.
Kimi Code is implemented strictly against the official OpenAI and Anthropic API specs, and both already define a request-body field for exactly this purpose:
Moonshot — prompt_cache_key (Chat Completions / Responses): "Used to cache responses for similar requests to optimize cache hit rates. For Coding Agents, this is typically a session id or task id representing a single session; if the session is exited and later resumed, this value should remain the same. For Kimi Code Plan, this field is required to improve cache hit rates. For other agents involving multi-turn conversations, it is also recommended to implement this field" https://platform.kimi.ai/docs/api/chat#body-one-of-0-prompt-cache-key metadata.user_id (Messages): "A stable identifier for the end user or session, used to improve cache hit rate and for abuse detection. Use a hashed value; do not send personally identifiable information. For coding agents, pass the session id and keep it constant for the whole session." https://platform.kimi.ai/docs/api/messages#body-metadata
We already send these fields in the request body today — prompt_cache_key on Completions/Responses calls, and metadata.user_id on Messages calls. Neither has any effect on the model itself, so as long as the OpenCode Go gateway reads the stable per-request ID from these body fields, Kimi Code can call OpenCode Go models without any changes on our side.
Adding a bespoke x-opencode-session header would mean diverging from both upstream specs, which we want to avoid. If a standardized header is the direction you'd prefer, the right place to raise it is with OpenAI or Anthropic so it can be adopted across the ecosystem.
For now, since we're keeping strictly to the OpenAI and Anthropic documentation, we won't be able to support additional custom headers. Hope the existing body fields work for your routing — happy to help you validate against them.
Reacted by ZHAO Jin-Xiang, Thomas Germer, safecodee, 李润泽, Noblet Ouways, Kexy Biscuit a.k.a. るる, newsletternewsletter, Alice39s, Cloud, YD-233 and 6 more
Saying that you want to strictly follow OpenAI chat completion API is actually impractical and is not the real case for literally any open providers nowadays.
Openai chat completion is a frozen API which does not even have reasoning_content field. If the API uses reasoning_content to provide thinking content, it already diverges from the standard openAI chat completion spec, it is the de facto standard now for open models but it is already diverged from the openai spec.
Activity
7Sageer commentedon Sep 7, 2026
Thanks for flagging this, and for the detail on your routing requirements.
Kimi Code is implemented strictly against the official OpenAI and Anthropic API specs, and both already define a request-body field for exactly this purpose:
prompt_cache_key(Chat Completions / Responses): "Used to cache responses for similar requests to optimize your cache hit rates. Replaces theuserfield." https://developers.openai.com/api/reference/resources/chat/subresources/completions/methods/createmetadata.user_id(Messages): "An external identifier for the user who is associated with the request." https://platform.claude.com/docs/en/api/http/beta/messages/createprompt_cache_key(Chat Completions / Responses): "Used to cache responses for similar requests to optimize cache hit rates. For Coding Agents, this is typically a session id or task id representing a single session; if the session is exited and later resumed, this value should remain the same. For Kimi Code Plan, this field is required to improve cache hit rates. For other agents involving multi-turn conversations, it is also recommended to implement this field"https://platform.kimi.ai/docs/api/chat#body-one-of-0-prompt-cache-key
metadata.user_id(Messages): "A stable identifier for the end user or session, used to improve cache hit rate and for abuse detection. Use a hashed value; do not send personally identifiable information. For coding agents, pass the session id and keep it constant for the whole session."https://platform.kimi.ai/docs/api/messages#body-metadata
We already send these fields in the request body today —
prompt_cache_keyon Completions/Responses calls, andmetadata.user_idon Messages calls. Neither has any effect on the model itself, so as long as the OpenCode Go gateway reads the stable per-request ID from these body fields, Kimi Code can call OpenCode Go models without any changes on our side.Adding a bespoke
x-opencode-sessionheader would mean diverging from both upstream specs, which we want to avoid. If a standardized header is the direction you'd prefer, the right place to raise it is with OpenAI or Anthropic so it can be adopted across the ecosystem.For now, since we're keeping strictly to the OpenAI and Anthropic documentation, we won't be able to support additional custom headers. Hope the existing body fields work for your routing — happy to help you validate against them.
Xenon1112 commentedon Sep 8, 2026
milanglacier commentedon Sep 9, 2026
Saying that you want to strictly follow OpenAI chat completion API is actually impractical and is not the real case for literally any open providers nowadays.
Openai chat completion is a frozen API which does not even have
reasoning_contentfield. If the API usesreasoning_contentto provide thinking content, it already diverges from the standard openAI chat completion spec, it is the de facto standard now for open models but it is already diverged from the openai spec.xbin9679-lab commentedon Sep 9, 2026
文档上 kimi code 本身自带有添加自定义请求头的功能,只要增加自定义请求头可以引用session-id这种内置变量,就可以在不违反规范的前提下,实解决这个问题
Duskriver commentedon Sep 10, 2026
不要互相踢皮球,如果你们真的为用户着想就尽早适配吧,天天为这些无所谓的标准吵来吵去没意义,又没有OpenAI/Anthropic的能力一统标准。
两分钟就可以完成适配,不要总说“这不优雅”“这不符合设计原则”,更何况你们只需要单独对opencode go适配,又不会影响其他供应商。这对kimi来说很容易做到,但对用户来说很重要,用户不在乎你们解决问题时是否优雅,只要你能解决问题
milanglacier commentedon Sep 10, 2026
我觉得“为了严格遵循 OpenAI/Anthropic 标准,所以不能支持
x-opencode-session”这个理由说服力不强。OpenAI Chat Completions API 的原始接口基本可以看作已经冻结。为了支持新的模型能力,现实中的 OpenAI-compatible API 早就会加入非标准扩展。比如
reasoning_content并不是 OpenAI Chat Completions 规范中的字段,但现在已经被大量开源推理模型和服务采用,用来传输推理内容。Kimi 自己也把动态工具加载作为 Chat Completions API 的扩展,这同样不属于原始 OpenAI 规范。为支持新功能而在原始 API 之上做扩展是可以理解的,毕竟原始 Chat Completions 规范不可能覆盖后来出现的能力。既然这些扩展已经是实际生态的一部分,就不能再以“严格遵循原始规范”为理由拒绝
x-opencode-session。为 OpenCode Go 提供这个支持是合理的,尤其这里只需要在这个 provider 里加一行代码。这个 header 也不是 breaking change:它不修改请求体或已有 API 行为,只针对 OpenCode Go provider 发送;不会影响其他 provider,也不会破坏不使用它的客户端,现有请求保持向后兼容。
Xenon1112 commentedon Sep 11, 2026
今日割五城,明日割十城,然后得一夕安寝。opencode这么搞我不知道为什么这么做。我还是放弃opencode吧。中转又不止这一家。
helloasong commentedon Sep 11, 2026
真是服了,这点破事踢来踢去的,接入opencode 的,基本都是充过钱的,总不能不要吧,kimi code 在这么傲慢下去,总不能自己魔改吧,只能换一个coding agent了