Skip to content

Send x-opencode-session header on API requests (required by OpenCode Go from 09/05) #3506

Closed as not planned
arrrrny/kimi-code-sync
#53

Description

@thdxr

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!

Activity

  1. 7Sageer commented on Sep 7, 2026

    @7Sageer
    Collaborator

    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:

    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.

  2. Xenon1112 commented on Sep 8, 2026

    @Xenon1112
  3. milanglacier commented on Sep 9, 2026

    @milanglacier

    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.

  4. xbin9679-lab commented on Sep 9, 2026

    @xbin9679-lab

    感谢您标记这一点,以及您的路线要求细节。

    Kimi Code 严格针对官方的 OpenAI 和 Anthropic API 规范实施,并且两者都已为此定义了一个请求体字段:

    * **OpenAI**  — `prompt_cache_key` (聊天完成/回复):用于缓存类似请求的响应,以优化缓存命中率。 替换 `user` 田野。 [https://developers.openai.com/api/references/resources/cath/subresources/completions/methods/create](https://developers.openai.com/api/reference/resources/chat/subresources/completions/methods/create)
    
    * **人类** — `metadata.user_id` (消息):“与请求关联的用户的外部标识符。 [https://platform.claude.com/docs/en/api/http:/beta/messages/create](https://platform.claude.com/docs/en/api/http/beta/messages/create)
    
    * **登月** — `prompt_cache_key` (聊天完成/响应):用于缓存类似请求的响应,以优化缓存命中率。 对于编码代理,这通常是一个表示单个会话的会话 id 或任务 id;如果会话已退出并随后恢复,则此值应保持不变。 对于 Kimi Code Plan,此字段需要改进缓存命中率。 对于涉及多转对话的其他代理,建议也实施此字段
      https://platform.kimi.ai/docs/api/chat#body-one-of-0-prompt-cache-key
      `metadata.user_id` (消息):“最终用户或会话的稳定标识符,用于提高缓存命中率以及用于滥用检测。” 使用哈希值;不要发送个人身份信息。 对于编码代理,请通过会话 ID,并在整个会话中保持其恒定。
      https://platform.kimi.ai/docs/api/messages#body-metadata
    

    我们今天已经将这些字段发送到请求机构—— prompt_cache_key 完成/响应电话,以及 metadata.user_id 在消息通话中。 两者对模型本身都没有影响,因此只要OpenCode Go网关读取这些正文字段中的稳定每请求ID,Kimi Code就可以调用OpenCode Go模型,而我们这边无需任何更改。

    添加定制 x-opencode-session 头球将意味着从两个上游规格中进行跳转,我们希望避免这种情况。 如果一个标准化的标头是你偏好的方向,那么使用 OpenAI 或 Anthropic 来提升它,因此可以将其应用于整个生态系统中。

    目前,由于我们严格遵循 OpenAI 和 Anthropic 文档,将无法支持额外的自定义头。 希望现有的身体字段能有效支持您的路由——乐意帮助您验证是否使用。

    文档上 kimi code 本身自带有添加自定义请求头的功能,只要增加自定义请求头可以引用session-id这种内置变量,就可以在不违反规范的前提下,实解决这个问题

  5. Duskriver commented on Sep 10, 2026

    @Duskriver

    不要互相踢皮球,如果你们真的为用户着想就尽早适配吧,天天为这些无所谓的标准吵来吵去没意义,又没有OpenAI/Anthropic的能力一统标准。
    两分钟就可以完成适配,不要总说“这不优雅”“这不符合设计原则”,更何况你们只需要单独对opencode go适配,又不会影响其他供应商。这对kimi来说很容易做到,但对用户来说很重要,用户不在乎你们解决问题时是否优雅,只要你能解决问题

  6. milanglacier commented on Sep 10, 2026

    @milanglacier

    我觉得“为了严格遵循 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,也不会破坏不使用它的客户端,现有请求保持向后兼容。

  7. Xenon1112 commented on Sep 11, 2026

    @Xenon1112

    今日割五城,明日割十城,然后得一夕安寝。opencode这么搞我不知道为什么这么做。我还是放弃opencode吧。中转又不止这一家。

  8. helloasong commented on Sep 11, 2026

    @helloasong

    真是服了,这点破事踢来踢去的,接入opencode 的,基本都是充过钱的,总不能不要吧,kimi code 在这么傲慢下去,总不能自己魔改吧,只能换一个coding agent了

  9. locked as resolved and limited conversation to collaborators on Sep 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions