如果你曾经用 vbk_ 密钥以无头模式运行 Verboo Code，却发现代理始终无法通过认证，那么这个版本就是为你准备的。0.15.18 包含三次提交，涉及 25 个文件，几乎全部集中在两个界面上看不到、却会毁掉自动化流程的地方：认证，以及负责翻译 OpenAI 协议的那一层。
认证有什么变化？
启动关卡此前只接受 OAuth。这造成了一个奇怪的局面：桌面端确实注入了 API 密钥，但关卡从不读取它，因此一个完全有效的 vbk_ 密钥无法让无头代理通过认证。
现在密钥可以作为会话的备用方式被接受，并通过 Bearer 向 /router/v1/models 验证。选择这个端点是有原因的：/api/me 会拒绝 API 密钥，这一点在修复前已经过验证。OAuth 仍然是首选路径，密钥无效或过期时会返回明确的提示，而不是无声失败。
在迁移自动化流程之前，有一个细节值得注意：条款与权益相关的流程使用的端点仅接受 OAuth。在 API 密钥这条路径上，这些流程会被跳过。
为什么凭据只在 Windows 上出错？
这类问题往往要耗掉一个下午，直到有人去看原始字节。Windows 的凭据存储此前使用 Encoding.UTF8 写入文件，而 PowerShell 5.1 在该模式下会输出 BOM，也就是文件开头的三个字节 EF BB BF。在任何编辑器里内容看起来都正常，但下一次读取时却与预期的 base64 对不上。
修复方案改用 UTF8Encoding($false)，更重要的是，写入之后会重新读取字节并与准确的 base64 比对。这不只是去掉 BOM，而是不再假定写入一定成功。
加固 OpenAI 兼容层意味着什么？
本次改动的主要体量都在这里。改动最多的文件是 openaiShim.ts、openaiArtifactSelfTest.ts 和 openaiProtocolReliability.ts，此外还有 codexShim.ts 与 boundedResponseBody.ts。
实际上，这一层的职责是：即使响应的格式不够理想，也要让兼容 OpenAI 的端点表现得符合客户端的预期。这些文件在同一次提交中都附带了测试，这说明了工作的性质：不是新增功能，而是封堵响应可能溜走的路径。
如何升级
npm i -g @verboo/code@latest两个版本之间的完整差异见 github.com/verbeux-ai/code/compare/v0.15.17...v0.15.18。
这个版本说明了什么
这三项改动都不会出现在功能清单上。无头模式的 API 密钥、Windows 的 BOM、协议的健壮性，都属于只有在出问题时才会被注意到的东西，而它们偏偏在最糟糕的时刻出问题：在流水线内部，没有人盯着终端。
产品其余部分遵循的是同样的逻辑。14 个开源模型运行在专用 GPU 上，配合不限量的 token，就是为了让开发者不必在重构进行到一半时停下来考虑用量。本月我们已为 222 位活跃订阅者提供了 227 亿个 token。可如果认证在 Windows 上无声失败，这一切都没有意义。
想让你的代理运行时不必计算 token？了解 Verboo Code。