Token Proxy: ローカル AI クライアントとモデル経路、トークン観測を 1 つの gateway に寄せる

いまのローカル AI ワークフローは、もう「API key を 1 つ入れて終わり」という段階ではなくなってきています。

• OpenAI、Anthropic、Gemini を並行して使う;
• Codex、Claude Code、OpenCode を同じマシンで回す;
• upstream ごとに優先順位や failover を分けたい;
• token 消費や latency をローカルで見たい;
• provider ごとの API 形式差も吸収したい。

こうなると、設定はあっという間に分散します。

• ある CLI は OpenAI 互換 endpoint を期待する;
• 別の tool は Anthropic Messages を前提にする;
• さらに別の client は Gemini を直接叩きたがる;
• model alias や key、base URL が client ごとにばらける;
• 問題が起きても、どの層で失敗したのか見えにくい。

今日メモしておきたい mxyhi/token_proxy は、まさにその分散を収束させようとしている project です。README ではローカルで動く local AI API gateway と説明されており、AI client からの request を受け、複数 upstream へ route し、必要なら format conversion を行い、token や request の観測もローカルに残します。

GitHub の repository page、README、releases page を 2026-06-26 時点で確認すると、この repository は 74 stars、14 forks、作成日は 2026-01-09、直近の公開更新は 2026-06-26 です。主要実装は Rust で、加えて TypeScript/Tauri ベースの desktop UI を含みます。license は Apache-2.0、最新 release は v0.1.115、公開日は 2026-06-23 です。

Project overview

項目	内容
Repository	mxyhi/token_proxy
位置づけ	ローカル AI API gateway / client 接続層
Stars	74
Forks	14
主要技術	Rust、TypeScript、Tauri
作成日	2026-01-09
直近の公開更新	2026-06-26
License	Apache-2.0
Latest release	v0.1.115
Release date	2026-06-23

これは「1 つの API を中継する project」ではなく、「ローカル AI client 接続を収口する project」

Token Proxy の重要な点は、単なる provider wrapper で終わっていないことです。

README から見える中心テーマは、

• ローカルでの統一入口;
• 複数 upstream の整理;
• provider 間の優先順位付け;
• API format の相互変換;
• token / request 観測;
• 主要 AI CLI への接続自動化;

をまとめて扱うことにあります。

つまり、これは単なる変換器というより ローカル AI client の control layer に近いです。

よくある project は、

• OpenAI 互換 endpoint を 1 つ作る;
• ある provider を別形式に見せかける;
• key と base URL の置き場を変える;

ところで止まりがちです。

でも実際のローカル運用では、その先のほうが面倒です。

• この model はどの upstream を優先するのか;
• どの client がどの format を必要とするのか;
• 429 や timeout の後でどう fallback するのか;
• model alias をどう揃えるのか;
• token 消費をどこで見るのか。

Token Proxy は、そこまで含めて 1 つの gateway に押し込もうとしているのが面白いです。

互換性だけでなく、運用面まで含めて設計されている

README に並んでいる機能を見ると、小さなローカル gateway 製品という印象です。

• openai、openai-response、anthropic、gemini、kiro、codex を扱える;
• OpenAI Chat / Responses、Anthropic Messages、Gemini の相互 conversion ができる;
• upstream priority と fill-first / round-robin の order を持てる;
• serial / hedged / race の dispatch 戦略を選べる;
• model alias mapping と response model rewrite を持てる;
• local access key と upstream key injection を分離できる;
• SQLite に requests、tokens、latency、recent logs を残せる。

ここがかなり実務的です。

ローカル AI スタックが複雑になってくると、「複数 client を同じ base URL に向ける」だけでは足りません。

本当に必要になるのは、

• 失敗時にどこへ切り替えるか;
• 同じ model 名を upstream ごとにどう吸収するか;
• どの format をどこで変換するか;
• どの request がどの provider に流れたか;
• token 使用量がどこで増えたか;

といった運用面です。

Token Proxy は、その層まで含めて local-first に整理しようとしています。

Codex や Claude Code への配慮が、かなり具体的

README の中で特に良いのは、単に「互換です」と言って終わらないことです。

Token Proxy には one-click CLI setup があり、

• Claude Code の設定ファイルを書き換える;
• Codex の ~/.codex/config.toml と ~/.codex/auth.json を書く;
• OpenCode の設定と認証ファイルも更新する;
• 上書き前に backup を作る;

という流れまで面倒を見ます。

これはかなり大きいです。

多くの gateway project は server 側だけ整っていて、最後の client 接続はユーザー任せです。けれど実際に面倒なのは、client ごとに設定箇所が違うことです。

Token Proxy はそこを product の一部として扱っているので、単なる middleware よりも道具としての完成度を感じます。

ローカル観測を中核に置いているのも良い

README では、SQLite ベースの dashboard が中核機能として扱われています。

保存される情報には、

• request ごとの token;
• cached token;
• latency;
• model;
• upstream;
• recent request;

が含まれます。

desktop dashboard では totals、provider ごとの統計、time series、recent requests を見られ、Logs パネルには 30 秒間の request-detail capture まであります。

これはローカル運用ではかなり助かります。

複数 provider と複数 client を同時に回し始めると、困るのは config そのものよりも、

• timeout の原因がどの upstream なのか;
• どの request がどこへ route されたのか;
• token 消費がどの client で増えたのか;
• format conversion のどこでエラーが出ているのか;

が見えないことだからです。

Token Proxy は、それをまずローカルで可視化しようとしているのが良いです。

ルールと境界を細かく書いているのが、むしろ信頼につながる

この手の project で一番危ないのは、routing と auth の境界が曖昧なことです。

例えば、

• local auth header と upstream auth header は混ざらないのか;
• /v1/messages は誰に送られるのか;
• /v1/responses が失敗したとき何に fallback するのか;
• Gemini native endpoint はどこまで conversion 可能なのか;
• retry と cooldown の条件は何か;

といった点です。

Token Proxy の README は、そこをかなり細かく書いています。

• local_api_key の扱い;
• upstream api_key の解決順;
• route ごとの provider pinning;
• retryable 条件;
• cooldown 条件;

が具体的に説明されています。

こういう project は、説明が少ないものより信頼しやすいです。実際の運用では、トラブルの大半がこのルールの曖昧さから生まれるからです。

CLI と desktop の二面構成が、使いどころを広げている

Token Proxy は CLI だけでも desktop app だけでもありません。

README と release からは、

• Cargo workspace の CLI;
• src-tauri/ ベースの desktop app;
• 複数 platform 向けの packaged artifacts;

が見えます。

この構成は理にかなっています。

ある人は、

• config.jsonc を書いて CLI だけで動けば十分;

と思うはずです。

一方で別の人は、

• upstream を GUI で管理したい;
• dashboard を見たい;
• 設定変更をその場で反映したい;

と考えます。

この 2 つを同じ project の中で扱おうとしているので、単なる headless proxy よりも「ローカル control plane」に近い手触りがあります。

向いている人

Token Proxy は、次のような人に向いていそうです。

• Codex、Claude Code、OpenCode など複数の AI client を併用している人;
• provider を 1 つの入口にまとめて route したい人;
• OpenAI / Anthropic / Gemini 間の format 差を吸収したい人;
• token、latency、request trace をローカルで見たい人;
• client ごとに key や base URL、model mapping を重複管理したくない人。

ローカル AI ツールが「ちょっとした補助」ではなく、日常の開発基盤になり始めている人ほど相性が良さそうです。

境界も見ておくべき

もちろん、Token Proxy は

• enterprise 向けの統合 API 管理基盤ではない;
• cloud-hosted な team gateway ではない;
• 完全自動の最適 routing システムでもない;
• 隔離や security をすべて肩代わりする sandbox でもない。

むしろ、

• ローカル client 接続を収束させる;
• provider routing を明示する;
• format conversion と balancing を local gateway に寄せる;
• observability をできるだけ自分のマシンに残す;

ための local-first control plane と捉えるのが自然です。

単一 client、単一 provider で十分な人には少し重いかもしれません。でもローカル AI スタックが複雑になり始めた人には、かなり刺さるはずです。

まとめ

mxyhi/token_proxy の面白さは、「何社の model provider を支援するか」だけではありません。

本当に価値があるのは、ローカル AI 利用で分裂しやすい層をまとめて扱っていることです。

• client 接続;
• provider routing;
• API format conversion;
• load balancing と fallback;
• token / request observability;
• 主要 AI CLI への設定反映。

ローカル開発機の中で複数の AI client と複数の model provider が当たり前になっていくなら、こういう gateway はますます重要になると思います。Token Proxy は、その現実にかなり正面から向き合っている repository です。