OpenCode v1.19.0 改了什么：升级路径与更新机制变了，provider 兼容性修复在别处

如果你看到「OpenCode v1.19.0 修复了 provider 兼容性」这样的说法，先别急着按版本号去等自动更新。把官方 changelog 的条目逐条对过之后，v1.19.0（2026-10-11）的条目里没有任何一条在描述 provider 兼容性修复；这个版本真正改的是升级路径和更新机制。对日常用它写代码的开发者来说，这意味着两件直接的事：更新不再自动安装，跨大版本升级需要你自己显式执行命令。S1

先看 v1.19.0 的官方条目到底写了什么。Core 部分三条：运行 opencode upgrade --major 升级到 OpenCode 2；允许 OpenAI ultrafast 服务层级；在校验 PTY 是否存在之前，先校验 PTY 连接来源与票据。TUI 部分一条：改用 /update 来安装更新或升级到 OpenCode 2，且更新不再自动安装。这四条没有一条提到某个 provider 或某类模型兼容性问题。需要说明边界：changelog 是发布方自述，以上只证明 v1.19.0 的条目文字内容，不排除存在未在条目中列出的改动。S1

那 provider 兼容性修复到底在哪？在相邻版本。v1.18.33 起，Cloudflare AI Gateway 模型开始遵循 provider 的响应与流超时；Gemini 的 thinking 默认值与 effort 选项对齐各代模型支持的控制项。v1.18.34 起，模型请求携带带命名空间的 session 与 parent-session 身份头。v1.18.35 起，xAI 工具结果包含受支持的图片、跳过不支持的图片格式。这些条目分属 v1.18.33 至 v1.18.35，不能归入 v1.19.0；changelog 也未给出各修复的完整适用 provider 清单。S1

再看这些修复是什么形态。它们不是一次统一的机制性修复，而是按 provider 与模型代际逐条打的边界补丁：Bedrock 图片附件只在 Claude、Nova、Llama 4 模型上提升（hoist）；Bedrock DeepSeek 模型 ID（含 ARN 形式）被保留以正确解析；Azure 与 OpenAI 的 provider SDK 更新以获取兼容性修复；为受支持的 GitLab GPT 与 Claude 模型增加 reasoning effort 变体；Codex OAuth 模型过滤识别 gpt-6 这类整数 GPT 版本。边界处理还包括：provider header 超时默认设为五分钟以降低慢启动失败率，流式 chunk 超时默认五分钟且支持设为 false 关闭；Anthropic thinking.blockBinding 可通过配置退出；Anthropic thinking block 绑定被限制在 Claude 5.1+ 模型，避免较旧部署拒绝请求；Claude 5 会话容忍过期 thinking block；Bedrock GPT-5.6 模型接受 none reasoning effort。这些「五分钟默认」「Claude 5.1+」均为发布方自述，无独立验证；且这批条目在片段中未标注所属版本号，需与 release 页面逐条对齐。S1S1

鉴权与缓存也有按 provider 的修复：Azure CLI 登录不再依赖 Bun，Azure provider 可通过 Azure CLI 用 Microsoft Entra ID 登录而无需 API key；Bedrock reasoning 响应不再被缓存为不可重放的空消息；V1 现在读取受支持的 V2 配置字段，使较新配置文件在混合环境中继续可用。同样，这些条目未标注版本号。S1

从条目分布看，一个合理的推断是：OpenCode 的 provider 兼容性工作是持续小步累积，而不是某一次版本事件；「v1.19.0 修复 provider 兼容性」的说法更可能源于对相邻版本或 v2 分支条目的混淆。这是编辑推断，不是发布方表述；现有材料也无法确认 v1.19.0 是否真的包含未列出的 provider 兼容性改动，无法确认各修复对应的具体版本号与提交，以及修复在自托管端点、非标准 baseURL、旧模型版本等条件下是否仍不成立。S1

落到可操作层面。第一，更新行为变了：以前等它自动装好，现在要在 TUI 里用 /update，跨大版本升级要显式跑 opencode upgrade --major，「等下一个版本自动修好」的预期不成立。第二，遇到 provider 问题，按 provider 与模型代际去查 changelog 条目，而不是按版本号扫一眼有没有「兼容性修复」字样。第三，注意条件性边界：如果你用自托管端点、非标准 baseURL 或旧模型版本，条目里写的修复可能不覆盖你的场景——这是基于条目形态的推断，材料未提供失败形态的复现。OpenCode 官方 provider 文档称其通过 AI SDK 与 Models.dev 支持 75+ LLM provider，provider 可通过 /connect 写入凭据（存于 ~/.local/share/opencode/auth.json），并可在配置的 provider 段自定义 baseURL、用 blacklist/whitelist 控制模型可见性；文档也提示，以 Amazon Bedrock 为例，需先在 Bedrock 控制台申请目标模型访问权限，再配置鉴权。这些是配置机制说明，不是 v1.19.0 的修复内容。S2S2

最后明确未决项：无法确认 v1.19.0 是否真的包含 provider 兼容性修复，还是该说法来自对相邻版本或 v2 分支的混淆；无法确认各 provider 兼容性修复对应的具体版本号与提交；无法确认 CHANGELOG.md 与 release notes 是否与官网 changelog 一致；桌面端 BETA 与 provider 修复的关系也未在材料中说明。这些作为待核项保留，不写成结论。S1