admin/CC-Switch

Fork 0

mirror of https://github.com/farion1231/cc-switch.git synced 2026-08-01 12:22:09 +08:00

Files

T

Jason 28529620f4 docs(release): add v3.19.1 release notes

2026-07-31 22:30:36 +08:00

60 KiB

Raw Blame History

CC Switch v3.19.1

本リリースの主軸は前バージョンの積み残しを片付けることです。中国系 Codex ゲートウェイ 3 社が Responses API のネイティブ対応を確認できたため、ローカルルーティングの引き継ぎが不要になりました——DeepSeek と火山方舟 Coding Plan のプリセットはローカルルーティング経由から直接接続へ変更、新規追加の Tencent Hunyuan TokenHub は最初から直接接続です。日常的に遭遇しうる 4 つの不具合も修正しました——Claude Desktop の使用量が v3.18.0 以降 2 重に計上されていた問題（アップグレード後に過去の数値も自動で正常化しますが 30 日の期限があります。「アップグレード時の注意」を参照）、公式 Codex プロバイダに戻すと 401 のままログイン画面も表示されなくなる問題、設定ページからの Grok Build アップグレードが os error 2 の一言で失敗する問題、Grok Build で引き継ぎを有効にすると 404 になる問題です。さらに、これまで $0 で計上されていた 8 モデルに組み込み価格を追加し、UI 文言 39 件の言語の問題を修正しました。本リリースにデータベースマイグレーションはなく、また本プロジェクト史上初めて削除行数が追加行数を上回ったリリースでもあります。

English → | 中文版 →

ハイライト：本リリースでできること

DeepSeek・火山方舟 Coding Plan・Tencent Hunyuan を Codex から直接接続する：3 社の公式 Codex ドキュメントで、エンドポイントが Responses API をネイティブ提供していることが確認できました。DeepSeek と火山方舟 Coding Plan の既存プリセットは Chat 形式からネイティブ形式に変わり、プロバイダカードの「ルーティングが必要」バッジと切り替え時の確認メッセージがなくなり、リクエストはローカルプロキシのプロトコル変換を通らなくなります。Tencent Hunyuan TokenHub は本リリースで追加されたプリセットで、最初からネイティブ形式です。DeepSeek V4 Pro はまだ直接接続で使えない点にご注意ください——ベンダー側で Codex 連携がまだ開放されていません。直接接続では V4 Flash（プリセットの既定モデル）をご利用ください。詳細はアップグレード時の注意を参照してください。
DeepSeek に DeepSeek 自身が公開したモデルカタログを使わせる：新しい「公式ベンダーカタログのミラーリング」機構は、ベンダーが公開している models.json をそのまま当該ベンダーのエンドポイント向けに配信します。これにより freeform な apply_patch の登録と、対になる GPT-5 ハーネスがセットのまま保持され、中立テンプレートに押し込められることがなくなります。判定はホスト名のみで行い、モデル名では行いません——同じモデルでも、再販するアグリゲータが同じ機能を実装しているとは限らないためです。
Claude Desktop の正しい使用量を得る：v3.18.0 以降、ローカルゲートウェイ経由の Claude Desktop のトラフィックはダッシュボードに 2 回記録されていました——1 回はプロキシから、もう 1 回はセッションログの取り込みから——token・費用・リクエスト数がおよそ 2 倍になっていました。本リリースの修正後、明細行が残っている日は自動的に正しい数値に戻ります。再構築の操作は不要です。
公式 Codex プロバイダに戻した後に正常にログインする：これまでサードパーティのプロバイダから組み込みの公式 Codex エントリに戻すと、サードパーティのキーが ~/.codex/auth.json に残っていました。Codex はそのキーで公式エンドポイントにリクエストし、確実に 401 になります——しかもファイルが存在するため Codex 自身のログイン画面にも戻らず、アプリ内から抜け出す手段がありませんでした。
設定ページから Grok Build をアップグレードする：grok update は 0.2.112 以降、内部で npm を呼び出して配布を行うようになりましたが、GUI から起動したアプリからは node が見えないため、アップグレードは Error: No such file or directory (os error 2) の一言で失敗していました。
Grok Build で 404 にならずに引き継ぎを有効にする：API 形式を手動で OpenAI Chat または Anthropic に変更した Grok Build プロバイダで引き継ぎを有効にすると、プロキシが登録していないルートにリクエストが送られ、そのまま 404 になっていました。フェイルオーバーも使用量の記録もありません。さらに Grok Build のリクエストはこれまで毎回新しいセッションとして扱われ、キャッシュキーの注入とセッション単位の集計がどちらも効かなくなっていました。
これまで $0 で計上されていた 8 モデルの実際のコストを見る：gpt-5.3-codex-spark、gemini-3.5-flash-lite、kimi-k2.7-code-highspeed、glm-5-turbo、glm-5v-turbo、qwen3.6-flash、および日付サフィックスのない claude-opus-4-6 / claude-sonnet-4-6 です。
繁体字中国語の UI で「バージョン情報」ページのツール管理を読む：30 件の文言が簡体字中国語・英語・日本語にしか追加されておらず、繁体字中国語が漏れていました。i18next は黙って英語にフォールバックするため、このパネルは v3.16.0 以降ずっと半分英語のままでした。さらに 9 件の文言はすべての言語で簡体字中国語が表示されていました。
公式サブスクリプションと DeepSeek を二者択一ではなく行き来する：auth.json と config.toml はどちらもスロットが 1 つしかないファイルで、Codex 自身は 2 組目の認証情報を保持できません。ベンダーのワンクリックスクリプトはこの設定を自分専用に書き換えますが、CC Switch はプロバイダごとにまとめてスナップショットして復元します——これが公式スクリプトとの最も実際的な違いです。詳細は後述の比較を参照してください。

利用ガイド

本リリースの変更は Codex の接続方式と使用量の集計基準に集中しています。以下のドキュメントとあわせてお読みください：

ローカルルーティング：どのプロバイダで引き継ぎが必要か、引き継ぎが何をするか。本リリース以降、DeepSeek・火山方舟 Coding Plan・Tencent Hunyuan には不要になります。
使用量統計：使用量ダッシュボードのデータソースと集計基準。Claude Desktop の 2 重計上がどう起きたか、修正後もなぜ一部の過去日を戻せないかを理解する助けになります。
Codex で DeepSeek のような Chat 形式 API を使う：このガイドはローカルルーティングが Responses を Chat Completions に変換する仕組みを説明したものです。仕組みの部分は Kimi・MiniMax・SiliconFlow など Chat 形式のままのプロバイダには引き続き当てはまりますが、DeepSeek を例として扱っている部分は本リリースには当てはまりません——DeepSeek は直接接続になり、ルーティングは不要です。

Warning

唯一の公式チャネル（必ずお読みください）

CC Switch は完全に無料・オープンソースのデスクトップアプリで、ユーザーから料金を徴収することはありません。本ソフトウェアは下記の公式チャネルからのみ入手してください：

チャネル唯一の公式

公式サイト ccswitch.io

ソースコード github.com/farion1231/cc-switch

ダウンロード GitHub Releases

作者 @farion1231

偽サイト通報 GitHub Issues

料金請求・チャージ・認証情報の提供を求める「CC Switch」サイトやクライアントはすべて偽物です。 支払いを誘導された場合は直ちに操作を中止し、GitHub Issues からご報告ください。

チャネル	唯一の公式
公式サイト	ccswitch.io
ソースコード	github.com/farion1231/cc-switch
ダウンロード	GitHub Releases
作者	@farion1231
偽サイト通報	GitHub Issues

概要

CC Switch v3.19.1 はメンテナンスリリースで、軸は 3 つあります。1 つ目は中国系 Codex ゲートウェイがまとめてネイティブ Responses に移行したことです。DeepSeek は api.deepseek.com に直接接続し、あわせて再利用可能な機構をもたらしました——ベンダー自身が公開するモデルカタログをそのままミラーリングして配信し、freeform な apply_patch の登録と対になる GPT-5 ハーネスが中立テンプレートに畳み込まれず、整合したまま保たれます。火山方舟の Coding Plan エンドポイント /api/coding/v3 も公式ドキュメントでの確認を経て追随し、Tencent Hunyuan の TokenHub が新しいプリセットとして加わりました。3 つとも、もうローカルルーティングの引き継ぎを有効にする必要はありません。

2 つ目は実際に遭遇しうる 4 つの不具合の修正です。Claude Desktop の使用量が v3.18.0 以降 2 回記録されていた問題（#5938）、組み込みの公式 Codex プロバイダに戻すとサードパーティの auth.json が残り、401 になったうえログイン画面も出なくなる問題、grok update が GUI 環境では os error 2 としか報告しない問題、そして Grok Build のプロキシ引き継ぎが Responses 以外のバックエンドで 404 になり、かつ毎回のリクエストが新規セッション扱いになっていた問題（#5677）です。3 つ目は減量です。呼び出し元が 1 つもないコード 3,166 行と、未使用の npm 依存 4 件を削除しました——本プロジェクト史上初めて、削除行数が追加行数を上回ったリリースです。このほか、ディープリンクのインポート確認ダイアログはマスクをより厳しく、切り詰めをより少なくし、$0 で計上されていた 8 モデルに価格を追加し、組み込み価格 4 件をベンダーの定価に合わせ直しました。本リリースにデータベーススキーマのマイグレーションはなく（バージョンは v16 のまま）、アップグレードは軽量です。

リリース日：2026-07-31

変更規模：12 commits | 71 files changed | +2,324 / -3,680 lines

追加機能

公式ベンダーモデルカタログのミラーリング（DeepSeek が第 1 号）

Codex はカタログファイルからモデルの機能を読み取りますが、CC Switch はこれまでどのプロバイダに対しても中立テンプレートからカタログを生成していました。アグリゲータにはこれが正しいものの、ベンダー自身の連携が前提としている機能が落ちてしまいます。本リリースからは、公式カタログをアプリに同梱しているベンダーについては、そのベンダー自身のファイルをそのまま配信します。

DeepSeek が第 1 号です。同梱ファイルは deepseek-v4-flash と deepseek-v4-pro の 2 エントリを持ち、apply_patch_tool_type: "freeform"、web_search_tool_type: "text"、supports_search_tool: true、low / high / max の 3 段階の推論レベル、そして base_instructions と model_messages に入っている 17,644 文字の GPT-5 ハーネスを保持します——このハーネスは freeform なツール登録とセットで扱う必要があります。ハーネス自体がモデルに apply_patch の使用を指示しているため、どちらか一方だけを取り出すと整合しなくなるからです。

判定条件は意図的に狭くしてあります。プロバイダがネイティブ Responses の区分に該当し、かつ base_url が deepseek.com 上にあることが条件です。判定はホスト名で行い、モデルのブランド名では行いません——同じモデルを再販するアグリゲータが同じ機能を実装しているとは限らず、ブランド名で付与することは、実装していないサービスに機能を与えることになるからです。プロバイダが自身のカタログで明示した項目は引き続き優先されます。未知のモデル ID の場合はフラッグシップのエントリを複製したうえで、そのモデル自身の名称を保ちます。他のすべての区分で生成されるカタログは、変更前とバイト単位で同一です。

Tencent Hunyuan（TokenHub）Codex プリセット

Codex のプリセット選択に「Tencent Hunyuan」が追加され、「オープンソース公式」カテゴリの Bailian と StepFun の間に入ります。選択すると https://tokenhub.tencentmaas.com/v1、wire_api = "responses"、および TokenHub が必須としている disable_response_storage = true が書き込まれます。モデルは hy3 と hy3-preview の 2 つを宣言し、コンテキストウィンドウは 256K（Codex の既定である 128K を受け入れるのではなく）、さらにテキスト専用として印を付けます——Codex が view_image の画像ペイロードを、画像を読めないモデルに送ることはなくなります。

ネイティブ Responses のプロバイダであるため、Codex はローカルルーティングなしでゲートウェイに直接接続します。生成されるカタログは中立のネイティブテンプレートを使い、shell_type = "shell_command" を固定し、ネイティブゲートウェイが受け付けない freeform な apply_patch の登録を外します。アドレス管理と速度計測には最初から 2 つの候補があります——メインドメインと、公式のバックアップである .cn ドメインです。地域が独立している国際サイトは、API キーがサイト間で共通ではないため意図的に除外しています。

API キーは Hy3 の権限が有効な TokenHub のキーである必要がある点にご注意ください。Coding Plan や Token Plan のサブスクリプションキーは、このエンドポイントでは利用できません。

$0 で計上されていた 8 モデルに組み込み価格を追加

gpt-5.3-codex-spark、gemini-3.5-flash-lite、kimi-k2.7-code-highspeed（Kimi の Turbo の慣例に従い kimi-k2.7-code の基準価格の 2 倍）、glm-5-turbo、glm-5v-turbo、qwen3.6-flash は組み込み価格テーブルに行そのものが存在せず、プレフィックスによるフォールバックでも届かなかったため、これらへのリクエストはすべてコスト 0 として記録されていました。

さらに 2 行——日付サフィックスのない claude-opus-4-6 と claude-sonnet-4-6——は、より分かりにくい隙間を塞ぐものです。モデル ID の解決は日付サフィックスを取り除くことしかせず、付け足すことはないため、日付なしの ID を持つログはどれにも一致しませんでした。8 行はいずれも「存在しない場合のみ挿入」で投入されるため、変更済みの価格は影響を受けません。

Grok Build がフェイルオーバータブと環境変数の競合検出に加わりました

設定ページのフェイルオーバーに、Claude Code・Codex・Gemini に続く 4 つ目の Grok Build タブが追加されました。起動時の環境変数競合バナーも XAI_API_KEY と GROK_DEFAULT_MODEL の検出を開始します——この 2 つはアプリで選んだプロバイダを黙って上書きしてしまう変数です。検出は完全一致とプレフィックスを区別するため、CC Switch 自身が使う GROK_BIN_DIR や GROK_HOME が誤検出されることはありません。

変更

DeepSeek と火山方舟 Coding Plan が Codex に直接接続、ローカルルーティング不要に

両プリセットはこれまで OpenAI Chat 形式として扱われていたため、どちらも「引き継ぎが必要」でした。プロバイダカードには「ルーティングが必要」バッジが付き、プロキシを起動せずに切り替えると確認が出て、リクエストは毎回 Codex → ローカルプロキシ → Responses から Chat への変換 → 上流、という経路をたどっていました。

両社の公式 Codex 連携ドキュメントで、エンドポイントが Responses API を提供していることが確認できました——DeepSeek の api.deepseek.com と火山方舟の /api/coding/v3 です。これに伴い両プリセットはネイティブ Responses として宣言され、バッジと確認メッセージはなくなり、Codex はゲートウェイに直接接続します。両社とも生成される config.toml に変化はありません（もともと wire_api = "responses" でした）。変わるのはカタログの生成区分と、DeepSeek についてはコンテキストウィンドウで、1,000,000 からベンダー自身の 1,048,576 に合わせ直しました。

BytePlus の国際サイトは、ドキュメントを個別に確認するまで意図的に Chat ルーティングのままとします。火山方舟のプリセットには、知っておく価値のある課金上の注記も残しました。従量課金の /api/v3 エンドポイントは、このプリセットのバックアップアドレスに絶対に追加してはいけません——別勘定で課金され、プランの残量を消費しないためです。

カタログの表示名とコンテキストウィンドウが「明示した場合のみ有効」に

この 2 つのフィールドには、これまでローカルの既定値——モデル ID と 128,000 のウィンドウ——が付いており、しかもベンダーの値が関与する前に適用されていたため、ミラーリングしたカタログの 1M のウィンドウが 128K に上書きされてしまう状態でした。現在この 2 つは省略可能になり、フォールバックはエントリ構築の層まで下ろされたため、「空のままにする」ことが本当に「ベンダーが宣言した値を使う」を意味するようになりました。この 2 つを明示したプロバイダ、およびミラーリング以外のすべての区分では、生成されるカタログは以前とまったく同じです。

CC Switch 経由の導入と公式スクリプトの違い

DeepSeek は Codex のワンクリック導入スクリプトを公開しています。これはきちんと動き、バックアップも取り、復元メニューも備えています。このマシンで DeepSeek だけを使うつもりなら、公式スクリプトを実行して何の問題もありません。 CC Switch が扱うのは別の場面です——複数のプロバイダを行き来したい場合です。

プロバイダを切り替えるとき、ログイン状態と設定がまとめて入れ替わる（自分でバックアップする必要はありません）

~/.codex/auth.json と ~/.codex/config.toml はどちらもスロットが 1 つしかないファイルです——Codex 自身に複数の認証情報を保持する仕組みはなく、1 つの設定は 1 つのプロバイダにしか対応できません。CC Switch はあるプロバイダから切り替えるとき、この 2 ファイルの内容をまとめてそのプロバイダのレコードにスナップショットし、戻すときにまとめて書き戻します。そのため「ChatGPT サブスクリプション → DeepSeek → サブスクリプションに戻る」で通常 codex login をやり直す必要はなく、サードパーティ間の行き来には手作業がまったく不要です。同じことを手作業で行う場合は、切り替えのたびに前後でこの 2 ファイルをコピーする必要があり、一度でも漏らせば、上書きされた OAuth の認証情報はログインし直す以外に取り戻せません。

公式スクリプトのトレードオフは異なります。config.toml を DeepSeek 専用の設定に作り替え——トップレベルに preferred_auth_method = "apikey" と forced_login_method = "api" を固定して認証方式を API キーに固定し、さらに config.toml にすでにある [profiles.*] を削除します（Codex 自身が持つ、複数プロバイダを切り替える仕組みです）。ChatGPT のログイン認証情報そのものは削除されず、auth.json はそのまま残りますが、その設定のもとでは使えません。サブスクリプションに戻すにはスクリプトの復元メニューで全体をロールバックする必要があり、そのロールバックではインストール後に config.toml へ加えた手動の変更もあわせて失われます。スクリプト自体も flash と pro の切り替えしかできず、「3 つ目のプロバイダに移る」という選択肢はありません。

プロバイダを切り替えた後も、`codex resume` に以前のセッションが残る

Codex は各セッションに記録された model_provider によって、再開一覧を引き出しのように分けています。CC Switch が作成するサードパーティの Codex プロバイダは——DeepSeek でも Kimi でもアグリゲータでも——すべて同じ識別子 custom を書き込むため、それらの間をどう切り替えても codex resume からは常に全履歴が見えます。CC Switch は初回起動時に一度だけ移行処理も行い、ベンダーごとに分かれていた既知の古いセッション（公式スクリプトが書き込む deepseek もこれに含まれます）をこの共有の引き出しへまとめます。その際、元のファイルは先に ~/.cc-switch/backups/ へバックアップされます。

ここには明確な境界があります。この移行は CC Switch の初回起動時に一度だけ実行されます。先に CC Switch をインストールし、その後で公式スクリプトを実行した場合、deepseek の識別子を持つそれらのセッションはもうまとめられず、自分の引き出しに残ったままになります。また、手書きで指定した、既知の一覧にないプロバイダ識別子は、CC Switch が意図的に変更しません。

公式サブスクリプションのセッションは、CC Switch ではもともとサードパーティと同じ一覧に並んでいます

CC Switch のセッション管理パネルはセッションディレクトリを直接スキャンし、model_provider を読みません。そのため公式サブスクリプションの利用中に生まれた Codex セッションは、以前からサードパーティのセッションと同じ一覧にあり、検索・再開・削除ができます——どのスイッチも有効にする必要はありません。

さらに Codex 自身の codex resume の一覧でも公式とサードパーティをまとめたい場合は、それは別の話になります。設定 → 一般 → Codex アプリ拡張 → **「Codex セッション履歴を統一」**で、既定はオフです。有効にすると新しいセッションのみが対象になります。既存の公式セッションもあわせて移すには、有効化の確認ダイアログで「既存の公式セッション履歴もあわせて移行する」にチェックを入れる必要があります（こちらも既定ではチェックなしです）。この 2 つはどちらも既存機能で、本リリースでの新規追加ではありません。境界となるケースについては「Codex セッション履歴の統一」ガイドを参照してください。

共通の前提が 2 つあります。後で戸惑わないよう先に明記します：

1. すべては CC Switch が参照している Codex ディレクトリが基準です。 既定は ~/.codex で、設定から変更できます。CC Switch は CODEX_HOME 環境変数を読みません——この変数で Codex を別の場所に向けている場合、そちらのセッションは CC Switch からは見えず、プロバイダの切り替えも CLI が使っていないディレクトリに書き込まれます。ディレクトリを変更するときは、CC Switch 自身の「設定ファイルのディレクトリ」設定をお使いください。

2. 同じ一覧に並ぶことは、必ず再開できることを意味しません。 Codex の推論内容（encrypted_content）は、それを生成したバックエンドでしか復号できないため、別のプロバイダで以前のセッションを続けようとすると失敗することがあります——これは上流の設計であり、CC Switch が回避できるものではありません。

修正

Claude Desktop の使用量が 2 回計上されていた問題

ローカルゲートウェイ経由の Claude Desktop のトラフィックは、使用量ダッシュボードに 2 回入っていました——1 回はプロキシの行、もう 1 回はセッション記録の取り込みの行です——その結果、token・費用・リクエスト数がおよそ 2 倍になっていました。

これは v3.18.0 で入った回帰です。プロキシ側の重複排除 ID は claude 以外のすべてのアプリにスコープのプレフィックスを付け、session:{アプリ}:{プロバイダ}:{メッセージID} の形にしていました。これにより claude-desktop が独立した名前空間に入る一方、セッションの取り込み側は同じ Claude のメッセージを、素の session:{メッセージID} の形かつ app_type = 'claude' で書き続けていました。その結果、3 つの重複排除の防御が同時に破られました——プロキシの行が既存のセッション行を吸収するための主キーの収束、書き込み側のフィンガープリント照合、読み取り側のフィルタです。後の 2 つはどちらもアプリ種別を厳密な等価比較で判定していました。

現在は 2 つのアプリが再び素の名前空間を共有し、2 か所の比較は一方向の規則で緩和されています。claude のセッション行は claude-desktop のプロキシ行に吸収されうる一方、その逆は成立しません。読み取り側のフィルタは日次ロールアップの集計が通るものと同一であるため、すでに保存済みの重複行も計上されなくなります。行の書き換えも削除も行いません——この自動修復には保持期間の制限があります。「アップグレード時の注意」を参照してください。Codex・Gemini・OpenCode では緩和後の比較はもとの厳密一致に退化し、上限チェックは引き続き厳密一致を使います。（#5938、#5951）

公式 Codex プロバイダに戻すと 401 のまま、ログイン画面も出ない問題

Codex の API キー保持スイッチがオフのとき（既定はオフです）、サードパーティのプロバイダに切り替えると相手のキーが ~/.codex/auth.json に書き込まれます。その後、組み込みの公式プロバイダ——保存されている認証情報は空です——に切り替えると「設定だけを書く」分岐を通るため、config.toml は置き換えられる一方、サードパーティの OPENAI_API_KEY はそのままディスクに残りました。Codex はその外部のキーで公式エンドポイントにリクエストして確実に 401 になり、さらに auth.json が存在するため自身のログイン画面にも戻らず、アプリ内には出口がありませんでした。

現在は、公式 Codex プロバイダへの切り替えが成功した後、auth.json の中身が OPENAI_API_KEY のみで、その横に第一級の認証情報が何もない場合、このファイルを削除します——OAuth トークン、パーソナルアクセストークン、agent の識別情報、Bedrock のキーのいずれかがあれば本物の認証情報であることを示すため、完全に保持されます。一方、auth_mode・last_refresh・アカウント ID のような単なるメタデータは、古くなったキーを「かばう」ことがもうできません。

{} を書き込むのではなくファイルを削除するのは意図的な選択です。空のオブジェクトは Codex にトークンのない ChatGPT モードと判定され、起動時にエラーになります。ファイルがない状態こそが未ログインと等価で、そのままログインの流れに入ります。このクリーンアップは、以前のプロバイダがデータベースへ正常に書き戻された後にのみ実行されるため、削除されたキーは失われていません——そのプロバイダのレコードに保存されており、再び選択すれば戻ってきます。同じ変更でライブ設定の読み取りも緩和され、クリーンアップ後の状態（auth.json がなく config.toml がある）が「Codex がインストールされていません」と報告されることはなくなりました。

設定ページからの Grok Build アップグレードが `os error 2` の一言で失敗する問題

設定 → バージョン情報から Grok Build をアップグレードすると、Error: No such file or directory (os error 2) で失敗し、それ以外の情報は何も出ませんでした。

根本原因は、検出の経路と実行の経路の非対称性です。検出はログインシェルを通るためユーザーの rc ファイルを読み、nvm・Homebrew・Volta が見えます。一方、ライフサイクルのスクリプトは非ログインシェルで実行され、GUI アプリの起動時に受け継がれる非常に狭い PATH を引き継ぎます。本来これは問題になりません。アンカーされたコマンドは対象のプログラムを絶対パスで呼び出すからです——しかし grok 0.2.112 は自己更新を npm 配布に移し、grok update は内部で npm view と npm i -g を呼び出すようになりました。そして npm 自身は shebang を通じて node を解決します。内側の呼び出しが ENOENT を返し、grok はそれをそのまま os error 2 として投げていました。

現在、macOS と Linux のライフサイクルコマンドは、ログインシェルの実際の PATH を、引き継いだ PATH の前に結合します。読み取りは変数をエコーするのではなく /usr/bin/env を実行して行います——fish は PATH をリストとして保持しており、エコーするとスペース区切りの断片になってしまうためです。ネイティブインストールの Grok については、アップグレードの連鎖に公式 xAI インストーラーをフォールバックとして追加しました。あえて npm i -g は使いません：npm は主経路と同じ 2 つの失敗モード（node がない、ミラーにパッケージがない）を共有しており、一緒に失敗するからです。公式インストーラーは node に依存しない唯一の経路で、配置先も同じであり、さらに CLI 自身の installer 設定を internal に書き戻すため、初期の npm フォールバックによって npm 配布に切り替わってしまったユーザーも、ついでに元に戻ります。

Grok Build で引き継ぎを有効にすると 404 になり、毎回のリクエストが新規セッションのように扱われる問題

API 形式を OpenAI Chat または Anthropic に変更した Grok Build プロバイダで引き継ぎを有効にすると、ただちに 404 になり、フェイルオーバーも使用量の記録もありませんでした——引き継ぎはアドレスとキーを書き換える一方、バックエンドのフィールドには手を付けなかったため、CLI がプロキシの登録していないルートにリクエストを送っていたのです。現在は引き継ぎがバックエンドも Responses に固定します。個別のプロバイダに応じて Chat Completions へ落とす処理は引き続き転送層で行われ、この強制された値はプロキシ停止時にライブ設定のバックアップとともに元へ戻ります。

もう 1 つの問題は、プロキシのセッション判定が Codex と OpenAI のクライアントしか認識していなかったことです。そのため Grok Build のリクエストは毎回新しいセッション ID を生成して「クライアント提供ではない」と印を付けられ、キャッシュキーの注入とダッシュボードのセッション単位の集計がどちらも効かなくなっていました。現在は Grok 自身のヘッダを読みます——まずセッションが属する会話の ID、次にセッション ID を見て、リクエストごとに変わる ID は無視します——さらに専用のプレフィックスを使い、Codex の記録と衝突しないようにしています。（#5677）

9 件の UI 文言がすべての言語で簡体字中国語を表示していた問題

9 件の文字列が、UI の言語にかかわらず簡体字中国語で表示されていました。英語や日本語の UI でも同様です。各呼び出し箇所は「インラインの既定値」の書き方を使い、既定値には中国語のリテラルが入っていましたが、対応するキーは 4 つの言語ファイルのどれにも存在しませんでした——そして i18next は言語チェーンをすべてたどってからインラインの既定値を検討するため、英語へのフォールバックが働く機会がそもそもなく、中国語のリテラルがすべての言語で勝っていました。

対象の文言は、Grok Build プロバイダフォームの必須項目チェック、アプリがまだ引き継がれていないときのフェイルオーバーのホバー説明、別のアプリが引き継ぎを保持している状態で Claude Desktop のルーティングを停止しようとしたときの警告とその理由の説明、プロバイダ識別子の読み取り失敗、Codex 共通設定が空のときのエラー、ルーティングサービスの停止と停止失敗の 2 つの通知、そして使用量テーブルで「token はあるがコストが 0 と算出された」リクエストに付く「未計算」のラベルにわたります。9 件のキーは現在、簡体字中国語・英語・日本語・繁体字中国語のすべてに存在します。（#5960）

繁体字中国語の「バージョン情報」ページでツール管理が英語にフォールバックしていた問題

UI の言語を繁体字中国語に設定すると、「バージョン情報」ページのツール管理の領域が英語で表示されていました——バージョンの行、インストールと更新のボタン、結果の通知、インストール競合の診断、そして更新確認ダイアログ全体です。このパネルは 3 回の変更を経て段階的に作られましたが、そのたびに簡体字中国語・英語・日本語だけが追加されていました。i18next の方針はエラーにせず英語へフォールバックすることなので、欠けていた 30 件のキーはテストからまったく見えませんでした。この欠落は v3.16.0 から v3.19.0 までずっと出荷され続けていました。

30 件の文言はすべて翻訳され、インストールの説明も他の言語と揃えました。新しく追加した言語テストは、ツール管理のすべての文言が 4 言語に存在し、かつ補間変数が一致することを要求するため、この種のずれは今後リリースされる前にテストで失敗します。（#5943）

組み込み価格がベンダーの定価とずれていた問題

コストはログに書き込む時点で組み込み価格テーブルに従って確定するため、古い初期値は以後のすべてのリクエストを黙って誤って計算します。本リリースでは 4 行を修正しました。deepseek-chat と deepseek-reasoner は V4 Flash の旧称エイリアスとなり、100 万 token あたり入力 $0.14 / 出力 $0.28、キャッシュ読み取り $0.0028 になりました（従来は $0.27/$1.10 と $0.55/$2.19）。minimax-m3 は公式の標準区分に合わせて半額の $0.30/$1.20 に。gpt-5.6-luna は OpenAI の 2026-07-30 の値下げに合わせて 80% 引き下げて $0.20/$1.20、gpt-5.6-terra は 20% 引き下げて $2/$12 とし、gpt-5.6-sol は意図的に据え置き、このシリーズのキャッシュ書き込みの比率も維持しています。

この修正は、行の 4 つの価格列がすべて従来の組み込み値と等しいままである場合にのみ書き換えます。そのため、自分で変更した価格——あるいは models.dev の同期によって書き込まれた価格——が触られることはありません。

セキュリティ強化

ディープリンクのインポート確認：マスクをより厳しく、切り詰めをより少なく

これは v3.19.0 の ccswitch:// 確認ダイアログ強化の続きです。設定のプレビューは共有モジュールで一元的に構築するようになり、入れ子になった TOML テーブルや JSON オブジェクトの中の秘匿値も再帰的にマスクします。これにより、方向の異なる 2 つの欠陥が同時に解消されました。Grok Build のインポートはこれまで設定のプレビューがまったく描画されず、Codex のインポートは埋め込まれた api_key を平文で表示していました。

設定プレビューにあった 300 文字の切り詰めは撤廃され、全文がスクロール可能な枠内に描画されるようになりました——確認ダイアログが「これから何を書き込むか」を隠しうる最後の箇所が塞がれます。マスク自体も、使われているすべての箇所で厳しくなりました。MCP のインポート確認ダイアログも含みます：秘匿キー名の照合に AUTHORIZATION・COOKIE・CREDENTIAL と、完全一致の AUTH・BEARER を追加し、マスク後に表示される平文のプレフィックスは 8 文字から 4 文字に縮小、長さが 8 文字以下の値は、そのまま表示するのではなく全体を置き換えるようになりました。

最後に、フロントエンドの Base64 デコーダーは前後の空白を切り落とさなくなりました——それは URL デコードによって + が空白になったものである可能性があるためです。これは v3.19.0 で修正したのと同じ種類の、フロントエンドとバックエンドのデコード基準のずれです。確認ダイアログが表示するものと、インポーターが書き込むものが食い違ってしまいます。

内部変更

呼び出し元のないコード 3,166 行、14 モジュール、依存 4 件を削除

「呼び出し元が 1 つもない」コードを対象にした整理です。バックエンドではプロバイダのアイコン推定テーブル、プレースホルダーのヘルスチェッカー、一度も接続されていない SSE 実装（ストリーミングと非ストリーミングのハンドラを含みます）、未使用のプロキシセッション型 2 つ、参照のない使用量パーサー 4 つ、そして使われていないコスト計算の入口を削除しました——本番の課金経路、その自動判別パーサー、セッション ID の抽出はすべて手つかずです。コンパイラが今まで警告しなかった原因である 22 か所の #[allow(dead_code)] も、あわせて削除しました。

フロントエンドではインポート元のない 14 モジュールを削除しました。パネルへの作り直しで置き換えられたプロンプトフォームのモーダルとリポジトリマネージャ、重複したプロキシ設定の hook、プロジェクトの歴史上一度もインポート元を持たなかったサーキットブレーカーのパネル、そして 3 つの schema ファイルが含まれます。これらの文言も 4 言語から同時に削除しました。これらのモジュールの背後にある Tauri コマンドは意図的に残しています。未使用の npm 依存 4 件も削除しました。手動管理のアイコンインデックスを再生成する 2 つのスクリプトを削除し、インデックスファイルのヘッダには「自動再生成は意図的にサポートしない」と明記しました。

あわせて、プロキシの状態と引き継ぎの状態を単一のクエリ層に統合しました——これまで同じコマンドを対象とする 2 つ目の hook 群が並存していましたが、呼び出し元はゼロで、そのクエリキーには観測者が一度も付かず、それらを対象とした無効化はすべて空振りでした。クエリキーの文字列は一字も変わっておらず、残した hook は従来のポーリング動作を維持しています。（#5916、#5928）

アップグレード時の注意

本リリースにデータベースマイグレーションはありません

v3.19.1 にスキーマのマイグレーションは含まれず（バージョンは v16 のまま）、アップグレード前のバックアップも発生しないため、そのまますぐに利用できます。

Claude Desktop の 2 重計上の自動修復には 30 日の期限があります（要確認）

この修正はデータを書き換えたり削除したりするのではなく、クエリ時に重複行を抑制します。そのため明細行が残っている日は、次回起動時に正しい合計へ戻ります。再構築の操作は必要ありません。

ただし明細行は 30 日を超えると日次ロールアップに集計され、削除されます。そしてロールアップは集計時点で有効だった基準で一度計算され、そのまま固定されます。この修正を含まないバージョンですでに集計されてしまった日は、水増しされた数値が永久に残ります。 この回帰は v3.18.0（2026-07-21）で入ったため、アップグレードが早いほど、取り戻せる過去の範囲は広くなります。

新しい価格が過去のデータに与える 2 通りの影響

新たに価格を追加した 8 モデルは遡って再計算されます。起動時にコストが 0 と記録されているリクエストへコストが補われるため、これらのモデルのダッシュボードの数値は上がります。すでに集計・削除された明細行は再計算できず、0 のままです。

価格を変更した 4 モデルは逆方向です。補正は 0 コストの行しか扱わないため、すでに記録済みのリクエストは旧価格のままで、新しいリクエストのみが新価格で計上されます——同じモデルでも、過去の費用と今後の費用は一致しません。どちらの経路でもご自身の価格は保護されます。修正は元の組み込み値のままの行しか変更せず、~/.cc-switch/model-pricing.json にある手動での価格変更・models.dev の同期値・削除の記録は、投入と修正の後に再適用され、常に優先されます。

プリセットの変更は新規作成のプロバイダにのみ影響します

すでに保存済みの DeepSeek や火山方舟 Coding Plan のプロバイダは、保存されている API 形式を保ち、引き続きローカルルーティングを必要とし、従来のカタログを使います。直接接続にするには、プリセットからプロバイダを作り直すか、プロバイダフォームの詳細設定で API 形式をネイティブ Responses に変更してください。

ただし、すでにネイティブ Responses で、アドレスが deepseek.com 上にあるプロバイダは、次回の切り替え時に自動でミラーリングされた公式カタログを使うようになります。保存し直す必要はありません——判定はライブ設定を読むためです。

DeepSeek V4 Pro はまだ直接接続で使えません

プリセットには引き続き deepseek-v4-pro が並んでおり、ベンダー自身が公開しているカタログにも含まれていますが、DeepSeek 側で pro 向けの Codex 連携がまだ開放されていません。公式に示されている時期は 2026 年 8 月上旬です。それまでは直接接続モードで pro を選ぶと上流でエラーになります——プリセットの既定モデルでもある deepseek-v4-flash をご利用ください。

いま pro をどうしても使いたい場合は、そのプロバイダの API 形式を「OpenAI Chat」に戻し、ローカルルーティングの引き継ぎを有効にしてください。これは v3.19.1 より前に DeepSeek がずっと通っていた経路そのものです。ローカルプロキシが Codex の送る Responses リクエストを Chat Completions に変換するため、pro はこの経路では影響を受けません。

DeepSeek 公式カタログの 2 つの前提

ミラーリングされたカタログは Codex クライアントの最低バージョンとして 0.144.0 を宣言していますが、CC Switch 自身は検証を行いません——カタログが持つ freeform な apply_patch の登録には、このバージョン以降が必要です。また、生成されるカタログファイルは（ミラーリングされた 2 モデルで）約 75 KB まで大きくなります。各エントリがハーネスの全文を含むためです。

直接接続の後、使用量の帰属はプロバイダ名から `Codex (Session)` に変わります

DeepSeek・火山方舟 Coding Plan・Tencent Hunyuan は引き継ぎを必要としなくなったため、そのトラフィックはローカルプロキシを完全に迂回でき、プロキシ側のリクエスト単位の記録からは見えなくなります。

使用量そのものは失われませんし、区別もできます——Codex のセッションログの取り込みが従来どおり記録します。ただしこの経路はプロバイダの識別情報を持ちません。ローカルプロキシを通らなかった Codex の使用量はすべて Codex (Session) という名前の項目にまとめられ、公式サブスクリプションの消費もこの行に入ります。つまり DeepSeek がルーティング経由から直接接続に変わると、その使用量は「DeepSeek」という名前の下から Codex (Session) に移ります。

区別するにはモデルを見てください：使用量の各レコードはそれぞれのモデル ID を保持しており、使用量パネルの「モデル統計」がモデルごとに 1 行ずつ表示します——deepseek-v4-flash・hy3・ark-code-latest と公式サブスクリプションの GPT 系は、それぞれ別の行になり、費用も token も分かれています。プロバイダ単位という軸そのものが必要な場合（たとえば同じモデルを複数のアグリゲータ間で比較したい場合）にのみ、引き続きローカルルーティングの引き継ぎを使う必要があります——この経路は実際のプロバイダ名を記録します。

Codex の古い認証情報のクリーンアップには 2 つの前提があります

クリーンアップは「切り替え先のプロバイダに明示的な公式カテゴリが付いている」かつ「切り替え元のプロバイダが正常に書き戻された」場合にのみ実行されます。手動で作成し公式カテゴリを付けていないエントリや、書き戻しに失敗した切り替えでは、古い認証情報はディスクに残ったままです。

Grok Build で引き継ぎを有効にするとバックエンドのフィールドが書き換わります

Grok Build のプロバイダで引き継ぎを有効にすると、ライブ設定のバックエンドのフィールドが Responses に書き換えられるようになりました。データベースに保存されているプロバイダのレコードは影響を受けず、プロキシ停止時にライブファイルはバックアップから丸ごと復元されます。

ツールのインストールと更新における PATH の変化（macOS / Linux のみ）

設定 → バージョン情報から実行するツールのインストールと更新はすべて、ログインシェルの PATH を、引き継いだ PATH の前に結合するようになりました。そのためライフサイクルのスクリプトが名前で解決するプログラムが、以前と異なるものになる可能性があります。また各操作でこの PATH を読むためのシェルが 1 つ余分に起動され、対話用の起動ファイルが実行されます。Windows は影響を受けません。

grok 0.2.112 以降を使っているユーザーは、インストールの記録が 2 つ見えることがあります——ネイティブのものと、grok update 自身が作成したグローバルの npm パッケージです。これらは上流によって同期が保たれ、同じバージョンを報告します。

環境変数の競合検出の照合基準が変わりました

Claude Code・Codex・Gemini の検出は「部分一致」から「プレフィックス」に引き締められました。そのため、単に名前にアプリ名を含むだけの変数——MY_ANTHROPIC_API_KEY、OLD_GEMINI_API_KEY——は競合として報告されなくなります。あわせて Grok Build の検出を追加しました。

ディープリンクのインポート確認で表示される秘匿値が減ります

マスク後に表示される平文のプレフィックスは 8 文字から 4 文字に縮小され、長さが 8 文字以下の値は全体がマスクされます。これは MCP のインポート確認ダイアログにも影響します。

リスク通知

継続してお伝えしている注意事項

xAI Grok OAuth サインイン：公式 Grok CLI の公開 OAuth クライアント識別情報を再利用しており、利用によってアカウントの制限や停止につながる恐れがあります——詳細は v3.18.0 release notes を参照してください。

Codex OAuth リバースプロキシ：ChatGPT サブスクリプションの Codex OAuth をリバースプロキシ経由で使用すると、OpenAI の利用規約に違反する可能性があります。詳細は v3.13.0 release notes を参照してください。

SuperGrok の残量照会：プロバイダカードの残量表示は grok.com の非公開の課金エンドポイントに依存しており、xAI がインターフェースを変更すると機能しなくなる可能性があります——詳細は v3.19.0 release notes を参照してください。

サードパーティプロバイダへのルーティング：CC Switch のローカルプロキシで Codex・Claude Desktop・Grok Build のリクエストを変換してサードパーティのプロバイダへ転送する場合、課金・コンプライアンス・データ保持に関する制約はプロバイダごとに異なります。利用前に対象プロバイダの利用規約をお読みください。

上記の機能を有効にした時点で、ユーザーは関連するリスクを自ら引き受けることになります。CC Switch は、これらの機能の利用に起因するアカウントの制限・警告・サービス停止について、一切の責任を負いません。

謝辞

本リリースの修正は、その大半が外部のコントリビューターによるものです——6 つの PR のうち 5 つは私が書いたものではありません。

コード貢献

#5677：Grok Build のプロキシ引き継ぎとディープリンク連携の仕上げ——バックエンドのフィールド、セッションの識別、フェイルオーバータブ、環境変数の検出、さらに設定プレビューでの秘匿値の漏れの修正まで。@YUZHEthefool さんに感謝します。本リリースで最も広い範囲をカバーした仕事です。
#5951：Claude Desktop の使用量 2 重計上の修正。@Komikawayi さんに感謝します。v3.18.0 のどの変更が 3 つの重複排除の防御を同時に破ったのかを突き止めたのは、本リリースで最も根気を要した調査でした。
#5916、#5928：呼び出し元のないコード 3,166 行と、重複したプロキシのクエリ層の削除。@SaladDay さんに感謝します。
#5943：繁体字中国語のツール管理の文言を補い、言語のずれを防ぐテストを追加。@yovinchen さんに感謝します。
#5960：すべての言語で簡体字中国語が表示されていた 9 件の文言の補完。@mhy1227 さんに感謝します。

問題報告

#5938 で、Claude Desktop のリクエストごとに session_log を出所とするログが 1 行余分に生まれ、token が 2 回集計されていることを報告してくださった @Alaric-L さんに感謝します——データソースまで特定された報告で、本リリースで最も重要な使用量の修正はこの報告から直接たどり着いたものです。

ダウンロードとインストール

Releases から、お使いのシステムに対応するビルドをダウンロードするか、公式サイト ccswitch.io から入手してください（ダウンロードは Cloudflare のエッジノード経由で配信され、GitHub への到達性に依存しません）。

システム要件

システム	最低バージョン	アーキテクチャ
Windows	Windows 10 以降	x64 / ARM64
macOS	macOS 12 (Monterey) 以降	Intel (x64) / Apple Silicon (arm64)
Linux	下表を参照	x64 / ARM64

Windows

ファイル	説明
`CC-Switch-v3.19.1-Windows.msi`	推奨 - 自動更新対応の MSI インストーラー
`CC-Switch-v3.19.1-Windows-Portable.zip`	ポータブル版、展開してそのまま実行できます

Windows ARM64 デバイスでは、ファイル名に arm64 が含まれる対応する成果物を選択してください。

macOS

ファイル	説明
`CC-Switch-v3.19.1-macOS.dmg`	推奨 - DMG インストーラー、Applications へドラッグ
`CC-Switch-v3.19.1-macOS.zip`	展開して Applications へドラッグ、Universal Binary
`CC-Switch-v3.19.1-macOS.tar.gz`	Homebrew インストールと自動更新用

Homebrew インストール：

brew install --cask cc-switch

更新：

brew upgrade --cask cc-switch

Linux

Linux アセットは x86_64 と ARM64（aarch64）の両方を提供します。ファイル名のアーキテクチャ識別子を、マシンの uname -m 出力に合わせて選択してください：

CC-Switch-v3.19.1-Linux-x86_64.AppImage / .deb / .rpm
CC-Switch-v3.19.1-Linux-arm64.AppImage / .deb / .rpm

ディストリビューション	推奨形式	インストール方法
Ubuntu / Debian / Linux Mint / Pop!_OS	`.deb`	`sudo dpkg -i CC-Switch-.deb` または `sudo apt install ./CC-Switch-.deb`
Fedora / RHEL / CentOS / Rocky Linux	`.rpm`	`sudo rpm -i CC-Switch-.rpm` または `sudo dnf install ./CC-Switch-.rpm`
openSUSE	`.rpm`	`sudo zypper install ./CC-Switch-*.rpm`
Arch Linux / Manjaro	`.AppImage`	実行権限を付与して直接実行、または AUR を利用
その他 / 不明な場合	`.AppImage`	`chmod +x CC-Switch-.AppImage && ./CC-Switch-.AppImage`

60 KiB Raw Blame History Unescape Escape