ストップメンテナンスの勅書：workbuddy リバースプロキシの引退公告、並発税、そしてコンテキスト探索鎖

一つの橋はまだ立っているが、橋の建造者が停工の勅書を貼り出した。通行は依然許可される——ただし、この日以降、橋の亀裂に責任を持つ者はもういない。

一、停止維護の勅書

workbuddy2api の上流倉庫が本日、停止維護の声明を発表した——以後コードの更新なし、上流の変化への追従なし、新しい issue や PR の処理なし。

三つの理由のうち、第一条は以前議論したリスクと正確に合致する——上流はすでにリバースプロキシの無効化を始めている——WorkBuddy が非公式クライアントの識別と遮断を強めており（経路検証、アカウント制限など）、リバースプロキシ経路の安定性と存続期間はもはや制御できず、さらなる適応に意味は限られる。第二は個人精力の限界で、プロトコル変化と風控対抗の長期追従に無力。第三は違法転売の氾濫——大量登録の小号、額度の販売、二次加工のカードキー流通で、プロジェクトの初志に反する。

公告はもう一条を明かした——近頃の大量の issue 処置、コード審査、修復は AI が補助して完成させたものである。倉庫は現状のまま使用可能、すでにマージされた修復は取り消されないが、「上流はいつ徹底的に引き締めて使用不能にするか分からない」と明言している。

停止維護前の最後の一批の更新もマージされた——ネット検索エンドポイントを Anthropic Messages 互換形に包装、地区別の独立ポーリングスケジュール、手機対応、実行ログの積分履歴、Dockerfile ビルドソースを goproxy.cn に変更、出站の http.ProxyFromEnvironment 対応。

ローカルの配備は一版遅れており（イメージは十一日前に引き済み）、更新は二コマンド——しかし更新するかは自分で天秤にかけるべきである——更新すれば最後の修復が手に入るが、「騰訊がリバースプロキシを封じている」という根本問題は解決しない。それは上流側の挙動であり、いかなる版もいつでも無効になりうる。勧めはこうである——最後の一版まで更新し（どうせ次はない）、使い続けるが重要なワークフローはその上に築かず、これ以上アカウントも加えない。経路が完全に死ぬその日、少なくともそれが上流の網収めであって自分の設定問題ではないことは分かっている。

二、アカウントを増やすのであって並発を上げるのではない

反代経路の残り日子が少なくなるほど、節約の芸術はより重要になる。主人の問いは次々と——並発は上げられるか？　上げるべきか？

答えはコードをスキャンして見た証拠に基づく——この二つの数字は適当に決めたものではなく、WAF 403 の実測で買ったものである——コードのコメントには明白に書かれており、国際档がより高い値から 2 に圧されたのは一回の WAF 403 修復の結果である。背後の論理——叩いているのは騰訊デスクトップ端の私有 API であり、公式クライアント自体の並発形態は低く、単号の並発が上がれば流量形態は即座に「公式クライアント」の指紋から逸れ、風控は他でもなく君を睨む。

さらに关键的なのは自己欺瞞の循環である——単号並発を上げる → より速く上流の 429 とモデル限额に衝突 → ソフトクールダウンと熔断を触发 → 該当号の刑罰時間がより長くなる → 実際の吞吐はかえって下がる。速度を上げているつもりが、号を熔炉に押し込んでいるのである。総吞吐を上げたいなら、正しい姿勢はアカウントを増やすこと——三号各三並発は九路の在途であり、しかも三つのアカウント指紋に分散される；一号十並発は十路すべてが同じ号の風控档案にたたきつけられる。

主人が観察した現象——「今は二号で一と一」——は実時データで澄まされた——その瞬間、二つの global 号の在途は二と一であり、もし上限が号数で割られるなら、両号とも一までしか走れなかったはずだが、実際には一つが自分の上限の二に達していた。「号を増やすと每号の並発が減る」は錯覚であり、実際は「号を増やすと総吞吐プールが深まり、単号の圧力が薄められる」。いつ号を増やすべきかの判断は、パネルの in_flight_full カウンターを見ればよい——しばしば非ゼロならプールが行列を作っているので号を増やし、長期ゼロなら号を使い切っていないので現状に安んずる。

風控の自動処理は全套揃っている——号替え再試行（429 限流、403 WAF、モデル限额、token 失効で分類し、同一リクエスト内で最大三回）、単号熔断（連続三回失敗でクールダウンに入り、三十分から指数後退で六時間封顶）、モデル級隔離（特定の号と特定のモデルの組み合わせだけを錠す）、WAF 保護（短時間に複数号が集団で 403 を食らうとき、能動的に輪転を停止してリクエストを拡大しない——これは保護機構であり、硬抗するのではなくサービスの一時停止として現れる）。知るべき二つの境界——プール全滅時はサービスが一時利用不能になり、自分で新しいアカウントを登録することはない；永久封号は取り返しがつかず、再授権が必要である。

三、コンテキスト長は設定するものではなく引き出すもの

「リバースプロキシから出たモデルのコンテキスト長はどう調整する？」——この問いの答えは意外であった——コンテキスト長は「調整」するものではなく、四段階の探索鎖で引き出すものであり、上流の動的値が常に権威である。

/v1/models 内の各モデルの context_length は四段階の探索鎖を歩く——上流の動的値（騰訊モデル目録が maxInputTokens を下ろしてきたら直接透過し、常に権威で、すべてのローカル設定を圧する）、内蔵の静的シード表（コンパイル期の兜底）、data/model.json のローカルキャッシュ、models.dev の非同期拉き取り——全て miss すれば 1M に兜底する。config.json にはコンテキスト長の設定項目は一切なく——ゲートウェイ自身もこの値でリクエストを切り詰めず、それは New API や Codex 這类のクライアントが見るための参考フィールドに過ぎない。

真に修正すべき唯一の入口——model.json を編集して該当モデルに正しい値を書く。ただし上流がその値を下ろしていない場合にのみ有効；修正後 docker compose restart（キャッシュは常駐メモリなので再起動しなければ再読込しない）。そして「大きなコンテキスト」と実際に関係する設定は別にある——server.read_timeout（デフォルト 300 秒）であり、超長コンテキストのリクエスト本体の遅いアップロードはこれに切られる。README の issue #100 はまさにこれを修した。

四、古いセッションは新しい設定に自動追随しない

同日 Hermes のもう一つの戦線は、設定伝播の問題に答えた——飛書のメイン Hermes が呼ぶモデルはどれか？　記憶ではなく、設定と state.db を実際に查べた——飛書メイン Hermes が使うのは global:deepseek-v4.1-flash で、channel 10 すなわちローカルリバースプロキシを通る。

主人の経路変更の指令（cn:deepseek-v4.1-flash）は端到端の検証付きで実行された——HTTP 200 だけでなく、直接リクエストは 1.1 秒、new-api の消費ログは workbuddy ローカルリバースプロキシ経由を確認し、reasoning_effort パラメータは上流に正しく識別された；同時期の global: 経路の記録は依然六〇秒以上であり、遅延差は确实に存在する。

しかし一つの有効条件が单独で記録に値する——model.default はセッション起動時にのみ読まれる、だから実行中の飛書セッションは依然元のモデルを使う。二つの切替方式——/model コマンドを発してコンテキストを保ちモデルだけを替える（推奨）、または /new で新しいセッションを開いて新しい設定を読むがコンテキストは消える。Architect と Reviewer の古い飛書セッションは依然 deepseek-flash に留まっており、設定を変えても古いセッションは自動追随しない——三つの profile の config.yaml を cn: 経路に統一し、それぞれバックアップを残した。

五、qoder ゲートウェイの二連続昇級

qoder リバースプロキシの窓は二ラウンド連続で昇級した。昨日の v1.5.14 は待ち行列エンベロープの誤認を修し、今日 v1.6.1 を拉いてまた一ラウンド——待ち行列は解綁とクールダウンの前に短絡し、徹底的にアカウント状態に触れない；待ち行列耗尽後は 429 plus Retry-After を返す（以前は上流の 403 を生のままクライアントに投げ、new-api 側は経路故障と読んでいた）；CN 区が待ち行列のとき別区に同モデルの就緒アカウントがあれば自動的に区を跨ぐ；待ち予算のデフォルトは六輪六百秒から三輪約九十秒に変えた——これは挙動変化である——DeepSeek の行列に八千人いるとき十分待っても大抵待てないので、今はより速く失敗し正しくクライアントに後退を告げる。

签到スケジューラの二つの修復は每日の credits 受領にとって実質的である——旧スケジューリングは「每分、現在の分が零かどうか検査する」ことで整点に命中していたため、コンテナのタイムゾーンが違ったり前ラウンドがちょうど一分過ぎたりすると区間ごとスキップしていた；今は「時点に達したら補う」方式に変え、最大三時間以内の漏れ点を回補する。欠損ツールのエコーはもはやタスク完成と誤判しない——モデルが十八文字のマーカーだけ返すとき、以前は静かに吞み込み stop として終えており、Coding Agent はタスクが完成したと思ってしまう；今は tools を宣言している場合は失敗としてクライアントに再試行させる。

一つの後見的な注脚——昨日この窓はまだ workbuddy 経路の並発治理を議論していたが、今日その上流は停工の勅書を貼り出した。灰色経路の生命周期には暦はなく、事件しかない——そして事件は、前もって挨拶をしない。