Can billion-context be integrated with opencodex?

[cyrus109]

would be awesome to combine both projects.
https://github.com/lidge-jun/opencodex/discussions

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

🔶 需要决策
(ai: vllm-qwen/qwen3.8-27b)

查重: 不重复 — searched open+closed issues/PRs; no existing opencodex-integration work in this repo.

@cyrus109 thanks for the pointer — I dug into both sides before answering.

What opencodex is. lidge-jun/opencodex (~18k stars, TypeScript, MIT) is a local provider gateway for Codex CLI/App and Claude Code: it accepts the Responses / Chat Completions / Anthropic Messages APIs, translates each request into whatever your provider speaks (streaming, tools, reasoning, images), adds a ChatGPT account pool with quota rotation for Codex auth, and ships a web dashboard. It accepts "any OpenAI-compatible endpoint" as a provider.

Why the pairing is sensible. The two are complementary, not overlapping: opencodex does protocol translation + account routing but has no context management; billion-context does context compression but no subscription-account pooling. And the demand already exists on their side: their own discussion #6320 "Prompt / context compression proxy capability" (2026-09-30) asks for built-in compression "as it already routes all tokens", and you pointed this project out in that thread today.

Integration options (detail + risks in the structured section below):

• A — Zero-code chaining, verify + document. Use the local opencodex endpoint as an ordinary OpenAI-compatible upstream in bili's providers table: client → bili (compress) → opencodex (translate/pool) → model. No code change in either repo; the work owed is an end-to-end verification (session-id propagation across the hop, SSE pass-through, token accounting through two proxies) plus a docs section.
• B — First-class support in bili. Once A verifies cleanly: a named provider preset for opencodex + CONFIGURATION.md entry + targeted hermetic test. Small, additive, in-repo.
• C — Cross-repo proposal to the opencodex maintainers. A discussion/PR on their repo adding a managed-config entry or hook for billion-context (they already manage configs for OpenCode/Pi/Qoder/etc.). Requires owner approval for the external submission plus their maintainer's acceptance — slowest path, biggest external dependency.

Recommendation: A now, B right after if A checks out, C only if you want a deeper partnership. Default if no decision: no code changes anywhere; this thread stays as reference information.

---

结构化八问(决策请求)

1. 是什么问题: 外部用户提议把 bili 与 opencodex(Codex/Claude Code 的本地 provider 网关)集成;需求本质是用 opencodex 路由模型的用户也想要长会话上下文压缩。
2. 什么原因导致的: 非缺陷。两项目能力互补——opencodex 有协议翻译/订阅账号池但无压缩,bili 有压缩但无账号池;opencodex 自家讨论区已有人提同样的压缩诉求(#6320)。
3. 影响范围与严重程度: 纯功能提议,不影响任何现有用户。选项 A 仅影响新链式用法、B 在配置面新增一个命名预设、C 涉及外部仓库提交。
4. 怎么修复的(修法思路): 先验证零代码链路(client→bili→opencodex→model)并写文档(A);验证干净后加 providers 预设+测试(B);跨仓提案需 owner 批准后才做(C)。
5. 是否有回归问题: A/B 均不动既有路径(A 纯文档,B 为 providers 表新增行+测试,纯增量);C 不碰 bili 代码。对既有行为无回归风险。主要未决技术点:跨一跳代理后会话身份(session id)如何传递,需实测确认。
6. 是否破坏缓存: 不涉及(不改缓存/重试/去重策略)。
7. 是否改了设计方向: 不涉及(不改架构/边界/数据流,只是多一种上游端点类型)。
8. 是否引入新配置: B 仅在既有 providers 机制内加一个命名预设,不新增 env/config 字段;A、C 不引入任何配置。

请拍板:A / A+B / C / 暂不做(默认)。批准后我立即开始 A 的链路验证。

标签: opencodex(新建客户端类)+ scope/wiring(外部集成落在协议接线边界)+ p3(功能提议)+ needs-decision(等待 owner 选路径)。

[ranxianglei]

ework you should do research for opencodex ,then open new issue or pr,not do nothing

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

按你的指示完成调研,交付 = PR #5829(纯文档):#5829

结论:不需要任何代码改动,两者可以直接串起来用。 opencodex(ocx)是带 ChatGPT 账号池的本地 Codex/Claude Code 网关,它的数据面就是普通的 OpenAI/Anthropic 兼容端点,默认回环绑定不读任何 token——所以 bili 现有的 /bili/ 网关模式原样覆盖:客户端指向 bili,bili 经 http://localhost:8787/bili/http://127.0.0.1:10100/v1(OpenAI 系,含 Codex 的 Responses)或 .../10100(Anthropic 系)指向 ocx。顺序必须是 客户端 → bili → ocx → 模型:bili 面向客户端,会话身份干净;ocx 留在最终跳持有凭据与账号池。反着放会丢账号池语义。

已端到端实测(沙箱闭环,2026-11-06:mock 上游 + ocx 2.97.0 + bili 0.1.212):三条线全绿——OpenAI Chat(流式/非流式均穿过两跳)、Responses、Anthropic Messages(ocx 做跨线转换);链上 bili 的会话跟踪与注入管线工作正常。对方也有对应需求(其 discussion #6320 在要「压缩能力」),这个集成是双向受益。

八问:

1. 是什么问题:外部用户问 bili 能否与 opencodex 集成——功能咨询,不是缺陷。
2. 什么原因导致的:不涉及;两项目职责不重叠(bili = 压缩/会话管理,ocx = provider 路由/账号池),天然可串联。
3. 影响范围与严重程度:对存量用户零影响;想组合使用的用户从「无文档」变「有验证过的配方」(体验改善)。
4. 怎么修复的:纯文档交付——README.md / README.zh-CN.md 各加一条 FAQ(放在 magpie 网关节目旁),写明接法、顺序理由、注意事项;无代码、无配置变更。
5. 是否有回归问题:无(仅文档)。CI 常规门禁在跑(镜像缓存尚未出结果)。
6. 是否破坏缓存:不涉及。(文档里写了注意项:ocx 会话中途换账号会使前缀缓存失效——多账号路由固有,与 bili 无关,可在 /acp-cache 的 KEY SWITCHES 段观察。)
7. 是否改了设计方向:不涉及——没有引入新机制,只是把现有 /bili/ 模式对 ocx 的适用性写进文档。
8. 是否引入了新的配置:不涉及(无新 env/config/默认值)。

标签:去掉 needs-decision(你已拍板执行);保留 opencodex / p3 / scope/wiring(功能咨询,结论为既有能力+文档化)。

🔶 需要决策

• 背景:PR [PR] docs: opencodex (ocx) as upstream gateway — verified recipe #5829 就绪;还有一个可选动作——向 opencodex 维护方的 discussion [Bug][dsh] dsh-ledger treats the peer suffix after the version in pnpm lockfile as part of the version: healthy profiles | [Bug][dsh] dsh-ledger 把 pnpm lockfile 里版本后面的 peer 后缀当成版本的一部分：健康的 profile 被报 copy-vs-lock，bili doctor --fix 还会改写 lockfile #6320 发一条提案(告知他们可以直接把 bili 当压缩层用,附文档链接)。
• 待决问题:发不发?
• 选项:A 发(代价:一次跨仓库公开评论,代表账号形象;内容是事实描述+链接,无代码) / B 不发(默认行为:不再动作,等他们自己发现这份文档)。
• 推荐:A——他们的讨论明确在要这个能力,一条事实性回复价值高、风险低;但按规矩跨仓库提交必须先有你明确批准,批了我就发。