CodexBarでClaude Code・Codex使用量を可視化する方法と仕組み

「Claude Code の Weekly Reset まであと何時間残っているのか」「Codex の 5 時間ウィンドウはあとどれくらい使えるのか」を、作業を止めずに把握したい。そう考えたことがある方は多いのではないでしょうか。

Claude Code や OpenAI Codex、Cursor、Gemini など、AI コーディングプロバイダーは各社ごとにセッション枠・週次枠・月次枠が独立しています。ccusage のような CLI ツールで都度残量を確認する方法もありますが、コマンドを叩くこと自体が集中の妨げになりがちです。

そこで注目されているのが、macOS メニューバーに使用量メーターとリセットカウントダウンを常駐表示できる OSS「CodexBar」です。GitHub でスター 17,439・フォーク 1,419 を獲得しており、対応プロバイダーは 57 種類以上に及びます。

本記事では CodexBar の公式ドキュメント（GitHub リポジトリ・公式サイト）を一次情報として、機能・アーキテクチャ・認証方式・使い方の要点・類似ツールとの違いを整理し、「自分の開発ワークフローに CodexBar を採用すべきか」を判断できる材料を提供します。動作検証は行わず、README と docs/ 配下のドキュメントの記載内容を根拠に解説します。

CodexBar とは — Claude Code・Codex の使用量をメニューバーに可視化する OSS

CodexBar は、AI コーディングプロバイダーごとの利用制限（rate limit）と各リセット時間を macOS のメニューバー（ステータスバー）に常時可視化する小規模なユーティリティです。作者は Peter Steinberger 氏（GitHub アカウント: steipete）で、リポジトリは MIT ライセンスで公開されています。

一言でいうと「AI コーディングプロバイダーの利用制限をメニューバーに常駐させる」ツール

README の冒頭では次のように紹介されています。

Tiny macOS 14+ menu bar app that keeps AI coding-provider limits visible and shows when each window resets.

出典: steipete/CodexBar README

「ログイン不要（without having to login）」という説明が付いていますが、これはユーザーがパスワードを CodexBar に渡す必要がないという意味です。実際には、既存のプロバイダーセッション（OAuth トークン、API キー、ブラウザ Cookie、CLI キャッシュ、ローカル設定ファイル）を CodexBar 側が再利用してデータを取得する設計になっています（詳細は後述のプロバイダー別認証方式で解説します）。

基本メタデータ（スター・言語・ライセンス・macOS 動作要件）

執筆時点で GitHub API から取得した主要メタデータは以下のとおりです。

archived=false かつ fork=false であり、フォークではなく steipete 氏本人が主管する独自の OSS として活発にメンテナンスされている状態です。

なぜ Claude Code・Codex ユーザーに CodexBar が必要なのか

CodexBar が解決しようとしている課題は、AI コーディングプロバイダーの「制限枠が複数併存し、それぞれリセット時刻が異なる」という運用負荷にあります。README の "Why" 節では、次の 4 点が導入価値として挙げられています。

• Plan around resets: プロバイダー別のセッション・週次・月次ウィンドウに対して、次のリセットまでのカウントダウンを表示する
• Credits, spend, and cost scans: クレジット残高、Admin API のスペンドダッシュボード、プロバイダー請求サマリ、ローカルコストスキャンを一元表示する
• Live status: プロバイダー障害の状況をポーリングし、メニューにインシデントバッジ、バーアイコンにインジケーターオーバーレイを表示する
• Privacy-first: 既存のプロバイダーセッション（OAuth、デバイスフロー、API キー、ブラウザ Cookie、ローカルファイル）を再利用し、パスワードは保存しない

出典: steipete/CodexBar README

Claude Code の Weekly Reset や Codex の 5 時間ウィンドウは、長時間ジョブを走らせるかどうかの判断に直結します。ccusage のような CLI ツールでも同じ情報は取れますが、「作業中も常に視界の隅に残量が入っている」という UX 上の価値は、GUI 常駐アプリならではの特徴といえます。

CodexBar の主な機能とサポート範囲

README の "Features" 節と "Providers" 節を軸に、機能とサポート範囲を整理します。

対応プロバイダー（57 種類の代表例と全体感）

CodexBar は README 冒頭で「57 providers」に対応することが明記されています。主要どころは以下のとおりです。

• コーディングエージェント系: Claude、Codex、Cursor、Gemini、Copilot、Grok、Zed、Kiro、Kilo、Windsurf、Augment、Amp
• API プロバイダー系: OpenAI、Azure OpenAI、Anthropic Admin API、OpenRouter、LiteLLM、LLM Proxy、AWS Bedrock、Vertex AI、DeepSeek、Mistral、Moonshot、Doubao、Perplexity、GroqCloud
• 音声・専門系: ElevenLabs、Deepgram、Poe、Sakana AI
• 中国語圏プロバイダー: z.ai、MiniMax、Alibaba Coding Plan、Alibaba Token Plan、Xiaomi MiMo、Kimi、Kimi K2、Chutes、Qoder、StepFun、ClawRouter

対応プロバイダーの完全なリストと各プロバイダーの認証方式は、README の Providers 節を参照してください。開いた瞬間に「自分が使っているプロバイダーがカバーされているか」を確認できます。

セッション・週次・月次のリセットカウントダウン

各プロバイダーのメニュー項目には、以下のような情報が表示される設計になっています（README「Features」より）。

• プロバイダーごとの使用量メーターと次回リセットまでのカウントダウン
• Codex の Web ダッシュボードから取得できる追加情報（コードレビュー残数・使用内訳・クレジット履歴）
• 支出と使用量のインラインチャート（OpenAI・Claude Admin API・OpenRouter・LiteLLM・z.ai・MiniMax・Mistral・AWS Bedrock）

Claude と Codex についてはローカルのコスト使用量スキャン機能も備えており、他のプロバイダーで表示している履歴チャート UI と共通の見た目に整えられているとのことです。

クレジット残高・API 支出・ローカルコストスキャン

API 系プロバイダーは、支出・使用量のグラフをメニュー内にインライン表示できます。Admin API 系（OpenAI・Claude）については、集計対象日を Today / 7d / 30d と切り替えて眺められる仕様が公式ドキュメントに記載されています（詳細は後述の Claude セクション参照）。

Merge Icons モードと表示カスタマイズ

複数プロバイダーを利用している場合、メニューバーに常時多数のアイコンが並ぶと視覚的に煩雑になりがちです。README では次の表示オプションが挙げられています。

• 「1 プロバイダー = 1 ステータス項目」構成
• Merge Icons モード（複数プロバイダーを 1 つのステータス項目にまとめ、内部でプロバイダー切り替えスイッチャを表示）
• プロバイダーアイコン・ラベル・バー・リセット時刻スタイル・利用率最高のプロバイダーを自動選択する挙動を個別に切り替え可能

WidgetKit ウィジェットと CLI（codexbar コマンド）

CodexBar は macOS メニューバーだけでなく、WidgetKit ウィジェットと CLI (codexbar) も同梱しています。CLI 単体は macOS / Linux の両方に配布されており（詳細は後述）、CI やスクリプトからも使用量データを取得できます。

アーキテクチャとデータフロー

CodexBar の内部構造は docs/architecture.md および docs/refresh-loop.md にまとめられています。ソースコードを読まなくても、モジュール構成とデータフローがドキュメントとして公開されている点は、OSS の採用判断において重要な材料になります。

モジュール構成（Core / UI / Widget / CLI / Watchdog / Probe）

docs/architecture.md によると、リポジトリは次のモジュールで構成されています。

• Sources/CodexBarCore: 取得・パース層（Codex RPC、PTY runner、Claude probes、OpenAI web scraping、status polling）
• Sources/CodexBar: 状態・UI 層（UsageStore / SettingsStore / StatusItemController / メニュー / アイコン描画）
• Sources/CodexBarWidget: WidgetKit 拡張（共有スナップショットに接続）
• Sources/CodexBarCLI: codexbar CLI
• Sources/CodexBarClaudeWatchdog: Claude CLI PTY セッションを安定化させるヘルパープロセス
• Sources/CodexBarClaudeWebProbe: Claude Web fetch 診断用の CLI ヘルパー

出典: docs/architecture.md

「取得と UI が明確に分離されている」「Widget と CLI は同じスナップショットを参照する」という設計は、拡張の余地を判断する材料になります。たとえば新しいプロバイダーを追加する場合、変更範囲が CodexBarCore に閉じ込められる可能性が高いことが読み取れます。

データフロー（Background refresh → UsageStore → menu/icon）

docs/architecture.md にはデータフローも記載されています。

• Background refresh → UsageFetcher / provider probes → UsageStore → menu / icon / widgets
• 設定の変更は SettingsStore を経由し、更新頻度と feature flag を制御する

並行処理については、Swift 6 の strict concurrency を有効化し、Sendable 状態と明示的な MainActor hops を推奨する方針が明記されています。macOS 14+ のターゲットに合わせた最新の Swift 6 世代の実装が採用されている点は、メンテナンスの健全性を判断する上でプラス材料といえます。

Adaptive Refresh のポリシー表

docs/refresh-loop.md には、リフレッシュ頻度プリセットとして Manual / 1m / 2m / 5m（デフォルト）/ 15m / 30m / Adaptive が用意されていることが記載されています。特に興味深いのが Adaptive モードのポリシーです。

出典: docs/refresh-loop.md

Adaptive モードは「電力状態と直近メニュー開閉時刻」のみを入力として動作する純粋関数として実装されており、クォータ・エラー・時刻帯には反応しないと明記されています。バッテリー駆動時の電池消費を気にするユーザーにとっては、この設計方針が採用判断の後押しになるでしょう。

プロバイダー別の認証方式とデータ取得の仕組み

CodexBar の「ログイン不要」は、CodexBar が独自にパスワードを持たず、既存セッションを再利用することで実現されています。ここでは Claude と Codex を代表例として、docs/claude.md と docs/codex.md の記載を軸に整理します。

Claude の取得経路（OAuth API → CLI PTY → Web API のフォールバック順）

docs/claude.md によると、Claude のデータ取得経路は次のように整理されています。

• Admin API: sk-ant-admin... キーが設定されているとき、/v1/organizations/cost_report や /v1/organizations/usage_report/messages から Today / 7d / 30d の spend / messages / tokens を集計
• App runtime のメイン経路: OAuth API → CLI PTY → Web API の順にフォールバック
• CLI runtime のメイン経路: Web API → CLI PTY の順にフォールバック
• Usage source picker で OAuth / Web / CLI を明示指定できる

推奨は OAuth API で、認証情報のソースは CodexBar OAuth キャッシュ・~/.claude/.credentials.json・Claude CLI Keychain（Claude Code-credentials）の 3 箇所です。user:profile スコープが必要で、user:inference だけの CLI トークンでは使用量取得ができないと明記されています。

Claude Code 2.1.x 系で mcpOAuth のみを含む Keychain の場合は OAuth 設定エラーとして扱われ、Web / CLI へフォールバックするか Keychain 修復を案内する挙動になっているとのことです。詳細は docs/claude.md を参照してください。

Codex の取得経路（OAuth API → CLI RPC → OpenAI Web extras）

Codex は docs/codex.md によると次の順序で取得を試みる仕様です。

1. OAuth API（~/.codex/auth.json）
2. CLI RPC（codex app-server）
3. OpenAI Web extras（有効かつセッションが存在する場合、ダッシュボード拡張を別リフレッシュとして追加。ソースラベルは primary + openai-web になる）

OAuth API は GET https://chatgpt.com/backend-api/wham/usage を叩き、rate_limit.primary_window / secondary_window をセッション/週次にマッピングする実装です。追加の rate limit（例: GPT-5.3-Codex-Spark）は UsageSnapshot.extraRateWindows として保持されます。

OpenAI Web ダッシュボードは off-screen WKWebView と、アカウントごとの WKWebsiteDataStore を使って取得しており、バッテリー消費を抑えるための Battery Saver トグルも用意されています。詳細は docs/codex.md を参照してください。

API 系プロバイダー（Admin API・API キー・ブラウザ Cookie の使い分け）

Claude / Codex 以外のプロバイダーも、認証方式は「API キー」「ブラウザ Cookie」「CLI キャッシュ」「デバイスフロー」のいずれか（または組み合わせ）で実装されています。README の Providers 節では、各プロバイダーごとに使う認証方式が併記されているため、自分の環境で用意できる認証情報から採用可否を判断できます。

プライバシー設計（Full Disk Access は Safari Cookie 読取時のみ・パスワード非保存・キーチェイン無効化オプション）

CodexBar のプライバシー設計は README「Privacy note」と「macOS permissions」に詳しく整理されています。要点は以下のとおりです。

• ディスク全体をクロールせず、機能を有効化した場合のみ「決まった場所」（ブラウザ Cookie / local storage、プロバイダーの config ファイル、ローカル JSONL ログ）だけを読み取る
• プロバイダートークンとアカウント設定は CodexBar の config ファイルに、厳格な file permission 付きで保存する
• Screen Recording / Accessibility 権限は要求しない
• Full Disk Access は Safari の Cookie を読むときのみ任意で要求される
• Keychain 使用は Chromium Cookie 復号鍵・Claude OAuth ブートストラップ・キャッシュされた Cookie ヘッダー等に限定
• 「CodexBar → Settings → Advanced → Keychain access → Disable Keychain access」で Keychain 参照を完全に無効化可能。ブラウザ Cookie 系プロバイダーは無効化に伴いスキップされるが、Claude / Codex の OAuth（~/.codex / ~/.claude の config ファイルから読み取り）は動作を継続する

「パスワードを CodexBar に預けたくない」「監査可能なプライバシー設計かを事前に確認したい」と考えるユーザーにとって、この設計方針は採用判断の重要な要素になるでしょう。

インストールと初期設定の要点（動作検証は行わない）

ここからは CodexBar の実際の使い方に踏み込みます。本記事では実機での動作検証は行わないため、README「Install」節に記載されている配布経路と初期設定の流れを、公式ドキュメントの引用として整理します。

動作要件と配布経路

README には次の配布経路が明記されています。

• 動作要件: macOS 14 (Sonoma) 以降
• GitHub Releases（.dmg / .zip）: https://github.com/steipete/CodexBar/releases
• Homebrew Cask: brew install --cask codexbar
• Homebrew tap（Linux 用 CLI を含む）: brew install steipete/tap/codexbar
• Arch Linux AUR パッケージ: yay -S codexbar-cli
• Release tarball（macOS / Linux）

Homebrew のインストールコマンドは README の Install 節から引用しています。

brew install --cask codexbar

出典: steipete/CodexBar README

初期設定の流れ

README の "First run" 節では、初期設定を次のように案内しています。

• Settings → Providers を開き、使うプロバイダーを有効化する
• 依存するプロバイダーソースにインストール / サインインする（CLI、ブラウザセッション、OAuth / デバイスフロー、API キー、ローカルアプリファイル、プロバイダーアプリのいずれか、プロバイダーに応じて選択）
• 任意: Settings → Providers → Codex → OpenAI cookies (Automatic または Manual) で OpenAI ダッシュボード拡張を有効化

導入コストの見積り観点で見ると、「Homebrew でアプリ本体を入れて、Settings で使うプロバイダーをトグルし、それぞれの認証情報を渡す」という 3 ステップに集約されます。詳細な手順を頭に入れる前に、この 3 ステップの見取り図があれば意思決定は進めやすいはずです。

CLI（codexbar コマンド）と HTTP サーバ機能

メニューバーに常駐させる基本的な使い方に加え、CodexBar は macOS アプリだけでなく CLI・HTTP サーバとしても使える点が特徴です。docs/cli.md に主要コマンドがまとまっています。

主要コマンド

docs/cli.md によると、codexbar CLI には次のコマンドが実装されています。

• codexbar（デフォルトで usage を実行）
• codexbar cost: Claude / Codex のローカルコスト計算を実行する
• codexbar cards: ターミナル用のカードグリッド表示（Kitty / Ghostty / WezTerm などの truecolor 端末では拡張描画）
• codexbar serve: localhost の HTTP サーバとして usage / cost の JSON を提供（デフォルト 127.0.0.1:8080）
• codexbar cache clear（--cookies / --cost / --all のサブフラグあり）

Release tarball 経由での動作確認例は docs/cli.md に次のように引用されています。

tar -xzf CodexBarCLI-v0.17.0-macos-x86_64.tar.gz
./codexbar --version
./codexbar usage --format json --pretty

出典: docs/cli.md

設定ファイルからのプロバイダー操作

CLI からプロバイダーの有効化・API キー登録を行うためのサブコマンドも README で紹介されています。

codexbar config providers
codexbar config enable --provider grok
codexbar config disable --provider cursor

出典: steipete/CodexBar README

Settings 画面を開かずに、シェルスクリプトからプロバイダー設定を制御できる点は、複数マシンへの同期・チーム内配布・CI 環境へのセットアップで大きな利点になります。

HTTP サーバ機能の位置づけ

codexbar serve は localhost のみをバインドする HTTP サーバで、GET /health / GET /usage / GET /cost のエンドポイントを提供します。README「Status bar & terminal integration」節では、SketchyBar / tmux / Zellij 向けの showy-quota が codexbar serve と CLI を土台に構築されている例が挙げられており、macOS メニューバー以外の可視化レイヤーへの拡張ポイントとして設計されていることが分かります。

類似リポジトリとの違い（ccusage / ClaudeBar / aqua5230/usage / agentsview）

Claude Code や Codex の使用量可視化には、CodexBar 以外にも複数の OSS が存在します。「CodexBar が自分に合っているか」を判断するには、代表的な類似リポジトリとの比較が有効です。CLI で単発集計するタイプ、軽量な macOS メニューバー GUI、ローカル完結のレポート生成型、Web UI で過去セッションログを深掘り分析するタイプまで、目的別に位置づけを整理します。

差分の一覧

ライセンスに関する補足として、ccusage は LICENSE ファイル、ClaudeBar は README のライセンス欄で、いずれも MIT ライセンスと明記されています。GitHub API の spdx_id フィールドではそれぞれ NOASSERTION / null と検出される場合がありますが、実体は両者とも MIT です。したがって「ライセンスの緩さ」を CodexBar 独自の優位性とみなすことはできません。CodexBar と類似リポジトリの本質的な違いは、リアルタイム監視 vs 過去ログ解析という対象時点の違い、対応プロバイダー数、Widget / CLI / HTTP サーバといった拡張性の 3 点にあります。

ryoppippi/ccusage との違い（GUI 常駐 vs CLI 単発、対応プロバイダー数）

ryoppippi/ccusage は、Claude Code を中心とした AI コーディングエージェント CLI のトークン使用量とコストをローカルデータから解析するコマンドラインツールです。日次・週次・月次・セッション別集計、5 時間課金ウィンドウトラッキング、モデル別コスト内訳などに対応しています。ライセンスは MIT です。

CodexBar 側の README「Credits」節では、「Inspired by ccusage (MIT), specifically the cost usage tracking.」と明記されており、コスト使用量トラッキングは ccusage を参考にしていると開発者自身が言及しています。両者は競合というより補完関係にあり、次のように使い分けられます。

• 「メニューバーで常時可視化したい」「複数プロバイダーを横断利用している」場合は CodexBar
• 「シェルスクリプトや CI で JSON を取得したい」「Claude Code のログを深掘り分析したい」場合は ccusage
• 併用してもコンフリクトは起きないため、両方インストールしても支障はない

tddworks/ClaudeBar との違い（対応範囲、CLI/Widget、コミュニティ規模）

tddworks/ClaudeBar は Claude / Codex / Antigravity / Gemini の 4 プロバイダーに対応した Swift 製の macOS メニューバーアプリです。ライセンスは README 内で MIT と明記されています。CodexBar と同じ Swift 実装ですが、以下の点で違いがあります。

• 対応プロバイダーが 4 種のみ（CodexBar は 57 種）
• CLI・Widget・Adaptive Refresh・Merge Icons といった機能は含まれず、UI もシンプル
• スター数は CodexBar の約 1/13、フォーク数も約 1/13 で、コミュニティ規模とメンテナンス速度に差がある

「Claude と Codex さえ見えれば十分」「軽量な GUI が欲しい」場合は ClaudeBar が向いていますが、対応プロバイダー数・派生プロジェクトの豊富さ・Widget や CLI サーバといった拡張性で判断するなら CodexBar が優位です。

aqua5230/usage との違い（ローカルのみ・API コールなし・AGPL-3.0 の制約）

aqua5230/usage は Python 製の macOS メニューバーアプリで、ローカルのみで動作し API コールを一切行わない設計です。HTML レポートを生成できる点も特徴です。

• CodexBar が公式 API・OAuth・Web ダッシュボードから最新値を取得するのに対し、aqua5230/usage はローカル JSONL ログのみで完結する
• 対応プロバイダーは Claude Code と Codex の 2 種のみ
• AGPL-3.0 のため、社内配布・商用組込みではソースコード開示義務の影響を検討する必要がある（CodexBar は MIT で組込みが容易）

「完全にオフラインで完結させたい」「API アクセスを一切避けたい」場合は AGPL-3.0 を許容できるならば aqua5230/usage が候補になります。多プロバイダーへの拡張性やライセンス面での組込み容易性を重視するなら CodexBar が有利です。

エージェント過去ログ解析ツール（agentsview 等）との違い

Claude Code や Codex のセッションログを Web UI で可視化・過去分析するツールとして kenn-io/agentsview が存在します。CodexBar と agentsview は同じ「AI コーディングエージェントの使用状況を可視化する」領域に属していますが、対象時点と設置形態が大きく異なります。

• CodexBar: セッション / 週間 / 月間の残クレジットとリセット時刻をメニューバーに常駐表示するリアルタイム監視ツール。作業中の「あと何時間使えるか」を作業を止めずに把握することが主目的
• agentsview: セッションログを Web UI で可視化し、過去の使用パターン・コスト内訳・プロンプト履歴を掘り下げる過去分析ツール。振り返りや事後分析の場面で真価を発揮する

両者は競合ではなく補完関係にあり、「現在残量の常時監視は CodexBar、セッション履歴の深掘り分析は agentsview」という住み分けで併用できます。特に、ccusage 由来の CLI 集計から Web UI 分析へ移行する読者は agentsview を検討する余地があります。過去ログ解析ツールとしての位置づけや、ccusage との比較観点はccusageの乗り換え先にagentsviewが選ばれる理由にまとまっているため、ログ分析ニーズを持つ場合は併せて参照してください。

どんな場面で CodexBar を選ぶべきか（意思決定サマリ）

前節までの整理を踏まえ、「CodexBar を採用すべきか」の判断軸を条件ベースで整理します。

CodexBar が向いている条件は、次のいずれかに複数当てはまる場合です。

• macOS 14+ を使っている個人開発者・フリーランスエンジニアで、Claude Code / Codex を業務利用している
• 複数の AI コーディングプロバイダー（Claude、Codex、Cursor、Copilot、Gemini など）を横断利用している
• CLI ではなく GUI で「常に視界に残量が入っている」状態を作りたい
• 将来的に WidgetKit ウィジェットや codexbar serve の HTTP エンドポイントを SketchyBar / tmux / Zellij / 社内ダッシュボードなどに組み込む可能性がある
• ライセンスは MIT（緩やか）を望んでいて、社内配布・改変にも制約を残したくない

一方で、次の条件に該当する場合は他ツールの方が向きます。

• ターミナルで完結する CLI 単発の集計で十分 → ccusage を推奨（CodexBar 側も参考実装として明記）
• Linux GUI 統合が主軸で、macOS を持っていない → CodexBar の派生プロジェクト（Waybar / GNOME / Cinnamon / KDE Plasma / Win-CodexBar など）を検討
• 完全ローカル完結で API コールを一切行いたくない → AGPL-3.0 前提で aqua5230/usage を検討
• Claude と Codex さえ見えれば良く、より軽量な GUI が欲しい → tddworks/ClaudeBar を検討
• 過去のセッションログを Web UI で深掘り分析したい → agentsview を検討（現在残量の常時監視は CodexBar と併用可）

併用パターン

「ccusage を既に使っていて、CodexBar を追加するべきか迷っている」ケースはよくあります。両者は同時併用しても問題なく、GUI 常駐と CLI 深掘り分析を組み合わせることで、日々の残量把握とスポットの詳細分析を役割分担できます。CodexBar 側の README でも ccusage は競合ではなくインスパイア元として明記されているため、心理的にも併用のハードルは低いはずです。同様に、過去のセッションログを Web UI で振り返りたい場面では agentsview を組み合わせることで、リアルタイム監視と過去分析を役割分担できます。

まとめ

CodexBar は、Claude Code や OpenAI Codex を含む 57 以上の AI コーディングプロバイダーの使用量制限とリセット時間を、macOS メニューバーに常駐表示できる OSS です。作者は Peter Steinberger 氏、ライセンスは MIT、スター数 17,439・フォーク数 1,419 と、活発にメンテナンスされているプロジェクトであることが GitHub API のメタデータから読み取れます。

意思決定の観点で重要なポイントを振り返ります。

• 対応プロバイダーは 57 以上と圧倒的に幅広く、複数プロバイダーを横断利用しているユーザーに強い
• アーキテクチャは docs/architecture.md と docs/refresh-loop.md に明文化されており、Swift 6 の strict concurrency を採用した堅牢な設計
• 認証方式は OAuth / API キー / ブラウザ Cookie / CLI キャッシュ / ローカルファイルを組み合わせる方式で、CodexBar 自身はパスワードを保存しない
• Full Disk Access は Safari Cookie 読み取り時のみ任意、Keychain 参照も完全に無効化可能で、プライバシー設計に配慮
• ccusage（CLI）・ClaudeBar（軽量 GUI）・aqua5230/usage（ローカル完結）・agentsview（過去ログ解析）と比較しても、対応プロバイダー数・派生エコシステム・拡張性で優位

さらに深く調査したい場合は、以下の一次情報にあたることをおすすめします。

• 公式サイト: https://codexbar.app
• GitHub リポジトリ: https://github.com/steipete/CodexBar
• 最新リリース: https://github.com/steipete/CodexBar/releases
• アーキテクチャ: https://github.com/steipete/CodexBar/blob/main/docs/architecture.md
• CLI リファレンス: https://github.com/steipete/CodexBar/blob/main/docs/cli.md

「作業を止めずにクォータを把握したい」「複数プロバイダーの残量を一元管理したい」というニーズを持つ macOS ユーザーであれば、CodexBar は導入検討リストの上位に置いてよい OSS といえるでしょう。