API on KnightLiブログ

LLM API はなぜ Token 課金なのか：入力・出力・コンテキストのコストをまとめて理解する

Sat, 25 Apr 2026 08:44:32 +0800

LLM API の料金体系で最も混乱しやすい点の 1 つは、なぜほとんどのプラットフォームが最終的に token という単位で課金するのか、ということです。要するに、なぜ大規模モデルは token ごとに課金され、しかも token の種類によって価格まで違うのか、という疑問です。

モデル API を使い始めたばかりの人が戸惑いやすいのは、モデル性能よりもむしろ請求額です。少し質問しただけなのに、なぜこんなに料金が増えるのか。なぜ入力は安く、出力は高いのか。なぜコンテキストが長くなるとコストが急に制御しづらくなるのか。

これをシンプルに捉えるなら、まず次の一文を覚えておくと分かりやすいです。課金されているのは「1 回の回答」ではなく、推論全体で消費された計算資源と帯域です。

1. token とは何か

LLM の課金でいう token は、文字数でも単語数でもありません。モデルがテキストを処理するときの分割単位です。

1 つの token は、たとえば次のようなものになり得ます。

1 つの漢字
英単語の一部
句読点
よく出る短いテキスト断片

そのため、API プラットフォームは通常「1 文ごと」や「1 リクエストごと」には課金しません。モデルが実際に読んだ token 数と生成した token 数に応じて課金します。
これはリクエスト回数ベースの課金よりも合理的です。同じ 1 回のリクエストでも、20 文字だけ入力する場合もあれば、20 万 token のコンテキストを入れる場合もあるからです。消費される資源はまったく違います。

2. なぜ入力と出力は別料金なのか

現在の多くのモデル API では、料金が次の 2 つに分かれています。

入力 token 料金
出力 token 料金

しかも一般的には、出力 token のほうが入力 token より高いです。

理由はそれほど難しくありません。

モデルが入力を処理するときは、基本的には既存の内容を読み取り、エンコードしています。けれども出力を生成するときは、次の token を 1 つずつ予測し続ける必要があります。これは単に読むだけではなく、継続的に推論とサンプリングを行う処理なので、通常はより多くの計算資源を使います。

大まかに言えば次のように考えられます。

入力：資料をモデルに渡す
出力：その場でモデルに回答を書かせる

その場で書くほうが、資料を一度読むよりも計算コストが高くなりやすいため、出力価格が高いのはよくある設計です。

3. なぜコンテキストが長いとコストが膨らみやすいのか

少し背景情報を足しているだけだと思っていても、請求の観点では想像以上に影響が大きいことがあります。

理由は、モデルは通常、各リクエストで渡されたコンテキスト全体をもう一度処理する必要があるからです。

つまり、現在のリクエストに次のようなものが含まれていれば：

システムプロンプト
会話履歴
ツールの返り値
長文書の断片
ソースコードファイルの内容

それらはすべて入力 token として課金対象になります。

請求額を本当に押し上げるのは、最後の一言の質問ではなく、その前にぶら下がっている長いコンテキストであることが多いです。
会話のターン数が増え、ツール呼び出しが増え、履歴メッセージが何度も再投入されると、token コストはラウンドごとに膨らんでいきます。

4. なぜツール呼び出しは特に token を増やしやすいのか

Agent、コーディングアシスタント、ワークフロー自動化のような場面では、token 消費は通常のチャットよりかなり大きくなりがちです。

問題は「モデルが少し長めに答えた」ことだけではありません。ワークフロー全体で次のような内容が絶えず発生するからです。

ファイルを読む
ログを確認する
API を呼ぶ
JSON を返す
ツール結果をモデルに戻す

ツール呼び出しの結果が次のラウンドのコンテキストに再投入されるたび、それは新たな入力 token になります。

だからこそ多くの開発者は最終的にこう気づきます。
問題はモデルの単価そのものではなく、ワークフローが token の請求額を何層にも積み上げていることがあるのです。

たとえばコーディング Agent が次のことを連続で行うとします。

プロジェクト構造を読む
いくつかのソースファイルを開く
テストを実行する
エラーログをモデルに戻す
さらに関連ファイルを読む

各ステップで、次のリクエストがより長いコンテキストを背負うことになります。単価が同じでも、総額はすぐに増えていきます。

5. 同じようなモデルでも価格差が大きいのはなぜか

モデルごとの token 価格差は、単にベンダーが高く売りたいからというだけではありません。多くの場合、次のような要素と直接結び付いています。

モデル規模
推論効率
コンテキスト長
配備コスト
ターゲット市場

モデルが大きく、アクティブパラメータが多く、推論経路が複雑になるほど、1 token を生成するコストは一般に高くなります。
さらに超長コンテキスト、複雑な推論、ツール利用最適化まで対応するなら、基盤側の負荷はさらに増えます。

そのため、価格設定は本質的に次のようなコストをカバーしています。

GPU / アクセラレータ資源
VRAM 使用量
推論レイテンシ
ネットワークとサービス安定性
ピーク同時実行能力

安いモデルが悪いとは限らず、高いモデルがすべての場面に向くわけでもありません。多くの場合、価格差は「その能力にどれだけの基盤コストがかかるか」を反映しています。

6. なぜキャッシュ入力は安くなるのか

多くのモデルプラットフォームでは現在、次のような仕組みが提供されています。

cached input
prompt caching
prefix caching

共通する考え方はシンプルで、すでに処理した大きな入力断片を、毎回フル価格でゼロから再計算しないようにすることです。

たとえば固定の system prompt、固定のツール説明、固定の長文書プレフィックスを毎ラウンドまったく同じように送るなら、プラットフォームはその一部をキャッシュできる可能性があります。すると同じ入力 token でも、キャッシュに当たった部分はより安い料金で計上できます。

この仕組みがあるからこそ、多くの API 料金表には次のような複数の価格帯があります。

通常入力
キャッシュ入力
出力

違いはテキストの意味ではなく、下層の計算が再利用できるかどうかです。

7. 「安い token」が必ずしも「安い総額」にならない理由

あるモデルが「100 万 token あたりとても安い」と書かれていると、総コストも必ず安いと思いがちです。ですが、実際にはそうとは限りません。

総額は大まかに次の式で考えられます。

token 単価 × 実際の消費量

そして実際の消費量は、さまざまな要因で膨らみます。

プロンプトが長すぎる
履歴メッセージを整理しない
ツール結果を戻しすぎる
出力が冗長すぎる
1 つのタスクを何度もやり直す

つまり請求額を決めるのは単価だけではなく、通常は次の組み合わせです。

モデル単価
各ラウンドの入力長
各ラウンドの出力長
呼び出し回数
ワークフロー設計

だからこそ、単価の安いモデルでも Agent タスクでは最終的な総費用がそれほど安くならないことがあります。より多くのラウンド、補足コンテキスト、再試行が必要になることがあるからです。

8. 開発者は token コストをどう見積もるべきか

実プロジェクトで予算を安定して管理したいなら、まずは素朴な見積もり方法が役に立ちます。

1 リクエストあたりの平均入力 token 数を測る
1 リクエストあたりの平均出力 token 数を測る
1 つのタスクが何ラウンド必要か見積もる
それをモデル単価に掛ける

たとえば次のようなイメージです。

1 ラウンドあたり入力 8k tokens
1 ラウンドあたり出力 1k tokens
1 タスクあたり 10 ラウンド

この場合、本当に消費しているのは「1 回のやり取り」ではなく：

入力およそ 80k tokens
出力およそ 10k tokens

途中でログ、ツール結果、ファイル内容が増え続ければ、総量はさらに上がります。

だから予算を見るときは、単一ラウンドではなく、タスク 1 件を最後まで回したときに何 token 消費するかを見るべきです。

9. 実際に請求額を抑えるには

すでに API や Agent を使っているなら、次の方法が特に効果的です。

system prompt を短くして重複表現を削る
古い履歴を定期的に削る
ツール出力は必要な項目だけ残す
長文書は先に検索して必要部分だけ渡す
出力長を制御して無制限な展開を防ぐ
高価なモデルは高価値タスクに、安価なモデルは低価値タスクに使う

多くの場合、節約の近道はむやみに安いモデルへ切り替えることではなく、まずワークフロー内の無駄な token 消費を削ることです。

10. 結局どう理解すればよいか

LLM の token 課金とは、要するに「モデルがどれだけ読み、どれだけ推論し、どれだけ書いたか」に対する課金です。

これは従来のソフトウェアのように、アカウント単位、回数単位、月額課金だけで資源消費を表しきれる世界ではありません。モデル呼び出しは動的な計算プロセスであり、送るコンテキスト量、呼ぶツール、求める出力長がすべて直接コストに反映されます。

だから大切なのは価格表を暗記することではなく、まず次の直感を持つことです。

長いコンテキストは入力コストを増やす
長い出力は生成コストを増やす
ツールチェーンは総 token を増幅する
キャッシュとワークフロー設計は請求額を大きく変える

この感覚がつかめれば、多くの LLM API の価格構造はかなり理解しやすくなります。

DeepSeek-V4 Preview 公開：1M コンテキスト、2 モデル構成、API 移行の注意点

Fri, 24 Apr 2026 22:39:46 +0800

DeepSeek は 2026-04-24 に DeepSeek V4 Preview Release を公開しました。公式ニュースページを見ると、今回の更新の軸はかなりはっきりしています。1M context、V4-Pro と V4-Flash の 2 モデル構成、Agent 向けの専用最適化、そして API 側のモデル移行です。

一言でまとめるなら、今回のリリースの本質は、DeepSeek が単に「より強いモデル」を目指しているだけではなく、超長コンテキストと Agent 能力をそのまま実運用に載せやすい形へ進めていることです。

1. 今回公開されたもの

公式ページによると、DeepSeek-V4 Preview は主に次の 2 つのラインで構成されています。

DeepSeek-V4-Pro
DeepSeek-V4-Flash

それぞれの公式説明も非常に分かりやすいです。

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

名前を見るだけでも、今回は単一モデルの更新ではなく、高性能側と高コスト効率側を同時に展開していることが分かります。

V4-Pro はより高い性能上限を重視しており、公式は世界トップクラスのクローズドモデルに競合できるとしています。一方の V4-Flash は、速度、効率、コストをより重視した位置づけで、レイテンシや API 料金に敏感な用途に向いています。

2. `1M context` が今回いちばん目立つポイント

公式ページで最も印象的な表現の 1 つが、「Welcome to the era of cost-effective 1M context length.」 です。

DeepSeek は今回、単に長コンテキスト対応をうたっているだけではありません。1M context をこの世代の標準能力として打ち出しています。ページでも次のように明記されています。

1M context は公式 DeepSeek サービス全体の標準になった
V4-Pro と V4-Flash はどちらも 1M context をサポートする

重要なのは、これが単に「より多くの token を詰められる」という話ではないことです。実際には次のような作業に直結します。

大規模コードベースの理解
長文書の Q&A や情報整理
複数ターンにまたがる Agent ワークフロー
複数ファイル、複数ツール、複数段階にまたがる複雑なタスク

コンテキストウィンドウが十分に大きければ、途中で文脈を落として何度も読み直すことが減ります。これは Agent コーディングや複雑な知識作業で特に重要です。

3. `V4-Pro` が主に強調していること

公式ページの表現を見ると、DeepSeek-V4-Pro が強く押し出しているのは次の 3 点です。

Agentic Coding 能力
世界知識
推論能力

ページでは、V4-Pro が Agentic Coding ベンチマークでオープンソース SOTA を達成したこと、世界知識では現行のオープンモデルの中で最上位クラスであり Gemini-3.1-Pro にのみ後れを取ること、さらに数学、STEM、コーディングで現行のオープンモデルを上回り、トップクラスのクローズドモデルに対抗できることが示されています。

つまり V4-Pro は、単純な質問応答モデルというより、高難度推論、複雑なコーディング、長いタスクの遂行に寄せた設計です。

4. `V4-Flash` は単なる縮小版ではない

もう 1 つ注目すべき点は、DeepSeek が V4-Flash を単なる廉価版として扱っていないことです。むしろ、実務的な多くのタスクでは十分に強いモデルであることを前面に出しています。

ニュースページによると、V4-Flash は：

推論能力が V4-Pro にかなり近い
シンプルな Agent タスクでは V4-Pro と同等の性能を持つ
パラメータ規模が小さく、応答が速く、API 価格も低い

つまり今回は、「1 つが旗艦、もう 1 つが入門」という極端に分かれた構成ではなく、次のような役割分担に近いです。

V4-Pro：より高い性能上限を狙う
V4-Flash：より低いレイテンシと優れたコスト効率を狙う

開発者にとっては、このほうが実際には使いやすい構成です。多くの本番タスクで必要なのは、理論上最強のモデルではなく、十分に強く、十分に速く、十分に安いモデルだからです。

5. Agent 最適化がかなり前面に出ている

今回の発表でもう 1 つ明確なのは、DeepSeek が V4 を Agent シナリオへ積極的に寄せていることです。

公式ページでは、DeepSeek-V4 が次のような主要 AI Agent とシームレスに統合されていると紹介されています。

Claude Code
OpenClaw
OpenCode

加えて、DeepSeek 自身も社内の agentic coding に V4 を使っていると述べています。

これは、対象が単なるチャットや通常の補完ではなく、コードを読み、構造を理解し、ツールを呼び出し、結果を生成し、その一連の流れをつなぐ長いワークフローになっていることを意味します。

最近 coding agent を追っているなら、この点は見逃しにくいです。モデル提供側の競争軸が、ベンチマークだけではなく「本当にワークフローに組み込めるか」へ広がっているからです。

6. 構造的な工夫は長コンテキスト効率のため

技術面では、公式ページは今回の構造的な工夫を次のようにまとめています。

token-wise compression
DSA (DeepSeek Sparse Attention)

方向性は非常に明快です。長コンテキストを、より安く、より高効率にし、計算コストとメモリコストをできるだけ抑えることです。

ニュースページでは完全な技術詳細までは踏み込んでいませんが、少なくとも DeepSeek が単純に計算資源を増やして長ウィンドウを支えているだけではなく、長コンテキスト効率のためのアーキテクチャ最適化も行っていることは読み取れます。

実際の利用者にとっては、単にコンテキスト数値が大きいことよりも、こちらのほうが重要な場合が多いです。なぜなら実用性を決めるのは、1M が使えるかどうかだけではなく、次のような点だからです。

速度が実用範囲に収まるか
コストが許容範囲に収まるか
長コンテキスト処理が実際に安定するか

7. API はすでに利用可能だが、モデル切り替えに注意

公式ページでは、今回の API が当日から利用可能であることも明記されています。

切り替え方法も比較的シンプルです。

base_url はそのまま
モデル名を deepseek-v4-pro または deepseek-v4-flash に変更する

さらに、両モデルが次をサポートするとされています。

1M context
Thinking / Non-Thinking の 2 モード
OpenAI ChatCompletions
Anthropic APIs

つまり、すでに DeepSeek API を使っているなら、移行の難しさはそれほど高くありません。主な作業はモデル名の差し替えと挙動確認です。

8. 旧モデルの終了時期も明確に書かれている

開発者にとって、この発表の中で見落とせない情報の 1 つが旧モデルの終了通知です。

公式には：

deepseek-chat
deepseek-reasoner

が 2026 年 7 月 24 日 15:59 UTC 以降に完全に廃止され、アクセス不能になると書かれています。

またページでは、現在この 2 つのモデルは実質的に deepseek-v4-flash の非思考 / 思考モードへルーティングされているとも説明されています。

そのため、もし今もプロジェクト内で deepseek-chat や deepseek-reasoner を直接参照しているなら、正式終了直前まで待つのではなく、今のうちに移行計画を進めるべきです。

9. この発表をどう読むべきか

今回の更新をいくつかの要点に圧縮すると、次のようになります。

DeepSeek は 1M context を高級機能ではなく標準機能へ変え始めている
2 モデル戦略がより明確になった。1 つは性能上限、もう 1 つは速度とコスト効率
Agent 能力がかなり中心的な位置に置かれている
API の移行経路は比較的シンプルだが、旧モデルの終了時期には早めの対応が必要

一般ユーザーにとっては、長文書、長いコード文脈、長い作業フローを 1 回のコンテキストに収めやすくなるのが分かりやすい変化かもしれません。
開発者にとってより重要なのは、すでに Agent、コードアシスタント、情報整理、複雑な自動化ワークフローを作っているなら、この世代のモデルは明らかにそうした用途を意識して設計されているという点です。

今回の DeepSeek の発表は、単なる通常のモデル更新というより、次の製品方向をより明確に示したものだと見たほうが自然です。超長コンテキスト、Agent 最適化、そして実用的な API 運用性です。

Codex クォータ使用統計

Sun, 12 Apr 2026 00:01:33 +0800

現在の Codex アカウントの残高を確認したい場合は、ChatGPT の /backend-api/wham/usage インターフェイスを要求する小さなスクリプトを直接作成できます。

このタイプのスクリプトの考え方は非常にシンプルです。

auth.json から tokens.access_token および tokens.account_id を読み取ります
リクエスト https://chatgpt.com/backend-api/wham/usage
リクエストヘッダーに Authorization: Bearer ... と ChatGPT-Account-Id を含めます
返された結果の 5 時間のウィンドウと週ごとのウィンドウクォータを解析します。

やるべきことに適した

この方法は、ローカルですばやく確認するのに適しています。

5 時間の割り当てはどれくらい残っていますか?
週の割り当てはどれくらい残っていますか?
クォータはいつリセットされますか?

複数のアカウントをお持ちの場合は、スクリプトで account/*.auth.json を一括で読み込み、一律に集計表を出力することもできます。 auth.json ファイルは、現在ログインしている chatgpt アカウントに対応する ~/.codex/ ディレクトリにあります。

最も重要なインプット

通常、スクリプトは次の 2 つの資格情報のみに依存します。

access_token
account_id

これらは通常、ローカルの auth.json から入手できます。これら 2 つの値が有効である限り、リクエストヘッダーは次のように構成できます。

headers = {
    "Authorization": f"Bearer {auth_token}",
    "Accept": "application/json",
    "ChatGPT-Account-Id": auth_account_id,
    "Origin": "https://chatgpt.com",
    "Referer": "https://chatgpt.com/",
    "User-Agent": "Mozilla/5.0",
}

返された結果の見方

インターフェイスが戻った後は、次の 2 種類のウィンドウに焦点が当てられます。

five_hour
weekly

スクリプトはそれらを次の項目に整理できます。

残高の割合
リセット時間
対応する時間ウィンドウの長さ

インターフェイスフィールド名が異なる場合、バリアント primary_window、secondary_window、five_hour_limit、および weekly_limit とも互換性がある可能性があります。

よくある質問

スクリプトが 401 を返した場合、通常、access_token の有効期限が切れているか、無効であることを意味します。

403 が返された場合は、通常、現在のアカウントにこのインターフェイスにアクセスする権限がないか、アカウントのステータスが異常であることを意味します。

同じ応答内でフィールドの名前が一貫していない場合でも驚かないでください。実際の処理では、異なる命名方法を統一的にマッピングしてから出力するのがベストです。

参考リンク

codex-auth-manager：https://github.com/RioArisk/codex-auth-manager

コード

import argparse
import base64
import json
import os
import sys
from datetime import datetime, timedelta, timezone
from pathlib import Path
from typing import Any

import requests


UTC = timezone.utc
CST = timezone(timedelta(hours=8), name="CST")
JSONDict = dict[str, Any]


def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(
        description="Query ChatGPT Codex usage from /backend-api/wham/usage."
    )
    parser.add_argument(
        "account_name",
        nargs="?",
        help="Account name used to load account/<account_name>.auth.json. If omitted, load all *.auth.json files in account/.",
    )
    parser.add_argument(
        "--account-dir",
        default="account",
        help="Directory containing <account_name>.auth.json files.",
    )
    parser.add_argument(
        "--chatgpt-url",
        default="https://chatgpt.com/backend-api/wham/usage",
        help="ChatGPT usage endpoint.",
    )
    parser.add_argument(
        "--raw-json",
        action="store_true",
        help="Print the full JSON response body.",
    )
    parser.add_argument(
        "--raw-headers",
        action="store_true",
        help="Print response headers.",
    )
    return parser.parse_args()


def print_json(data: Any) -> None:
    print(json.dumps(data, indent=2, ensure_ascii=False))


def load_auth_json(path_str: str | Path | None) -> JSONDict | None:
    if not path_str:
        return None
    path = Path(path_str).expanduser()
    if not path.is_file():
        return None
    try:
        return json.loads(path.read_text(encoding="utf-8"))
    except (OSError, json.JSONDecodeError):
        return None


def get_nested_string(data: JSONDict | None, *keys: str) -> str | None:
    current: Any = data
    for key in keys:
        if not isinstance(current, dict):
            return None
        current = current.get(key)
    return current if isinstance(current, str) and current else None


def format_dt(dt: datetime | None) -> str:
    if dt is None:
        return "-"
    return dt.astimezone(CST).strftime("%Y-%m-%d %H:%M:%S %Z")


def format_cst(dt: datetime | None) -> str:
    return format_dt(dt)


def epoch_ms_to_dt(value: Any) -> datetime | None:
    if value is None:
        return None
    try:
        raw = int(value)
    except (TypeError, ValueError):
        return None
    # Newer responses sometimes use epoch seconds, older ones use epoch milliseconds.
    timestamp = raw / 1000 if raw > 10**11 else raw
    return datetime.fromtimestamp(timestamp, tz=UTC)


def first_dict(data: Any, *keys: str) -> JSONDict | None:
    for key in keys:
        value = data.get(key) if isinstance(data, dict) else None
        if isinstance(value, dict):
            return value
    return None


def decode_jwt_exp(token: str) -> datetime | None:
    parts = token.split(".")
    if len(parts) != 3:
        return None
    try:
        payload = parts[1]
        payload += "=" * (-len(payload) % 4)
        data = json.loads(base64.urlsafe_b64decode(payload.encode("ascii")))
        exp = data.get("exp")
        if exp is None:
            return None
        return datetime.fromtimestamp(int(exp), tz=UTC)
    except (ValueError, TypeError, json.JSONDecodeError):
        return None


def get_percent_left(value: JSONDict) -> float | int | None:
    percent_left = value.get("percent_left")
    if percent_left is None:
        percent_left = value.get("remaining_percent")
    if percent_left is not None:
        return percent_left

    used_percent = value.get("used_percent")
    try:
        if used_percent is not None:
            return max(0, 100 - float(used_percent))
    except (TypeError, ValueError):
        return None
    return None


def resolve_limit_window(value: JSONDict) -> JSONDict:
    if (
        "reset_at" not in value
        and "reset_time_ms" not in value
        and isinstance(value.get("primary_window"), dict)
    ):
        return value["primary_window"]
    return value


def parse_limit_entry(name: str, value: Any) -> JSONDict | None:
    if not isinstance(value, dict):
        return None

    value = resolve_limit_window(value)

    percent_left = get_percent_left(value)
    reset_time_ms = value.get("reset_time_ms")
    if reset_time_ms is None:
        reset_time_ms = value.get("reset_at")

    window_seconds = value.get("limit_window_seconds")

    return {
        "name": name,
        "percent_left": percent_left,
        "reset_time_ms": reset_time_ms,
        "reset_at": epoch_ms_to_dt(reset_time_ms),
        "limit_window_seconds": window_seconds,
    }


def infer_limit_name(window_seconds: Any) -> str | None:
    if not isinstance(window_seconds, (int, float)):
        return None
    if window_seconds <= 6 * 3600:
        return "five_hour"
    if window_seconds >= 6 * 24 * 3600:
        return "weekly"
    return None


def relabel_rate_limits(primary: JSONDict | None, secondary: JSONDict | None) -> tuple[JSONDict | None, JSONDict | None]:
    for entry in (primary, secondary):
        if not entry:
            continue
        inferred_name = infer_limit_name(entry.get("limit_window_seconds"))
        if inferred_name:
            entry["name"] = inferred_name

    if primary and secondary and primary.get("name") == secondary.get("name"):
        if primary.get("name") == "weekly":
            primary["name"] = "five_hour"
        else:
            secondary["name"] = "weekly"

    if primary and primary.get("name") == "weekly" and secondary is None:
        return None, primary

    if secondary and secondary.get("name") == "five_hour" and primary is None:
        return secondary, None

    return primary, secondary


def parse_rate_limits(data: JSONDict) -> tuple[JSONDict | None, JSONDict | None]:
    primary = None
    secondary = None

    for primary_key in ("five_hour", "five_hour_limit", "five_hour_rate_limit", "primary"):
        if primary_key in data:
            primary = parse_limit_entry("five_hour", data.get(primary_key))
            if primary:
                break

    for secondary_key in ("weekly", "weekly_limit", "weekly_rate_limit", "secondary"):
        if secondary_key in data:
            secondary = parse_limit_entry("weekly", data.get(secondary_key))
            if secondary:
                break

    if primary is None:
        primary = parse_limit_entry("five_hour", data.get("primary_window"))
    if secondary is None:
        secondary = parse_limit_entry("weekly", data.get("secondary_window"))

    return relabel_rate_limits(primary, secondary)


def format_percent(value: Any) -> str:
    return f"{value:g}" if isinstance(value, (int, float)) else str(value if value is not None else "-")


def percent_sort_value(value: Any, descending: bool) -> tuple[int, float]:
    if isinstance(value, (int, float)):
        numeric_value = float(value)
        return (0, -numeric_value if descending else numeric_value)
    return (1, 0.0)


def get_auth_paths(account_dir: str, account_name: str | None) -> list[Path]:
    base_dir = Path(account_dir)
    if account_name:
        return [base_dir / f"{account_name}.auth.json"]
    return sorted(base_dir.glob("*.auth.json"))


def get_account_name_from_path(path: Path) -> str:
    suffix = ".auth.json"
    return path.name[: -len(suffix)] if path.name.endswith(suffix) else path.stem


def build_summary_row(account_name: str, five_hour: JSONDict | None, weekly: JSONDict | None) -> JSONDict:
    return {
        "account": account_name,
        "five_hour_percent": five_hour["percent_left"] if five_hour else None,
        "weekly_percent": weekly["percent_left"] if weekly else None,
        "weekly_reset_at": weekly["reset_at"] if weekly else None,
    }


def print_summary_rows(rows: list[JSONDict]) -> None:
    if not rows:
        return

    sorted_rows = sorted(
        rows,
        key=lambda row: (
            percent_sort_value(row.get("five_hour_percent"), descending=True),
            percent_sort_value(row.get("weekly_percent"), descending=True),
            format_cst(row.get("weekly_reset_at")),
            row["account"],
        ),
    )

    display_rows = []
    for row in sorted_rows:
        display_rows.append(
            {
                "account": str(row["account"]),
                "five_hour": format_percent(row.get("five_hour_percent")),
                "weekly": format_percent(row.get("weekly_percent")),
                "weekly_reset": format_cst(row.get("weekly_reset_at")),
            }
        )

    headers = {
        "account": "account",
        "five_hour": "five_hour%",
        "weekly": "weekly%",
        "weekly_reset": "weekly_reset",
    }
    widths = {
        key: max(len(headers[key]), max(len(item[key]) for item in display_rows))
        for key in headers
    }

    print(
        f"{headers['account']:<{widths['account']}}  "
        f"{headers['five_hour']:>{widths['five_hour']}}  "
        f"{headers['weekly']:>{widths['weekly']}}  "
        f"{headers['weekly_reset']:<{widths['weekly_reset']}}"
    )
    for item in display_rows:
        print(
            f"{item['account']:<{widths['account']}}  "
            f"{item['five_hour']:>{widths['five_hour']}}  "
            f"{item['weekly']:>{widths['weekly']}}  "
            f"{item['weekly_reset']:<{widths['weekly_reset']}}"
        )


def validate_token_inputs(
    token: str,
    account_id: str,
    auth_token: str | None,
    auth_account_id: str | None,
) -> int | None:
    if token.startswith("sess-"):
        print("status: invalid_token_type", file=sys.stderr)
        print(
            "message: --chatgpt-token looks like a session token (sess-...). Use the JWT access_token instead.",
            file=sys.stderr,
        )
        if auth_token:
            print(
                "hint: Found tokens.access_token in auth.json; omit --chatgpt-token or pass that value instead.",
                file=sys.stderr,
            )
        return 1

    token_exp = decode_jwt_exp(token)
    if token_exp is not None and token_exp <= datetime.now(UTC):
        print("status: expired", file=sys.stderr)
        print(f"message: access_token expired at {format_dt(token_exp)}", file=sys.stderr)
        if auth_token and auth_token != token:
            auth_token_exp = decode_jwt_exp(auth_token)
            hint = format_dt(auth_token_exp) if auth_token_exp else "unknown time"
            print(f"hint: auth.json contains a different access_token expiring at {hint}", file=sys.stderr)
        return 1

    if auth_account_id and account_id != auth_account_id:
        print("warning: supplied --account-id does not match auth.json tokens.account_id", file=sys.stderr)

    return None


def handle_error_response(response: requests.Response, data: Any, raw_json: bool) -> int | None:
    if response.status_code == 401:
        print("status: expired", file=sys.stderr)
        print("message: Token 已过期或无效", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code == 403:
        print("status: forbidden", file=sys.stderr)
        print("message: 账号已被封禁或无权访问", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code >= 400:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print_json(data)
        return 3

    return None


def fetch_chatgpt_usage(auth_path: Path, args: argparse.Namespace) -> tuple[int, JSONDict | None]:
    auth_data = load_auth_json(auth_path)
    account_name = get_account_name_from_path(auth_path)
    auth_token = get_nested_string(auth_data, "tokens", "access_token")
    auth_account_id = get_nested_string(auth_data, "tokens", "account_id")

    if not auth_data:
        print(f"{account_name}: auth file not found or invalid", file=sys.stderr)
        return 1, None

    if not auth_token:
        print(f"{account_name}: missing access_token", file=sys.stderr)
        return 1, None

    if not auth_account_id:
        print(f"{account_name}: missing account_id", file=sys.stderr)
        return 1, None

    validation_error = validate_token_inputs(
        auth_token,
        auth_account_id,
        auth_token,
        auth_account_id,
    )
    if validation_error is not None:
        return validation_error, None

    headers = {
        "Authorization": f"Bearer {auth_token}",
        "Accept": "application/json",
        "ChatGPT-Account-Id": auth_account_id,
        "Origin": "https://chatgpt.com",
        "Referer": "https://chatgpt.com/",
        "User-Agent": "Mozilla/5.0",
    }

    try:
        response = requests.get(args.chatgpt_url, headers=headers, timeout=60)
    except requests.RequestException as exc:
        print(f"Request failed: {exc}", file=sys.stderr)
        return 2, None

    if args.raw_headers:
        print("=== Headers ===")
        print_json(dict(response.headers))
        print()

    try:
        data = response.json()
    except ValueError:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print(response.text, file=sys.stderr)
        return 3, None

    error_response = handle_error_response(response, data, args.raw_json)
    if error_response is not None:
        return error_response, None

    if args.raw_json:
        print("=== Raw JSON ===")
        print_json(data)
        print()

    rate_limits = first_dict(data, "rate_limit", "rate_limits")

    if rate_limits is None:
        return 0, build_summary_row(account_name, None, None)

    five_hour, weekly = parse_rate_limits(rate_limits)
    return 0, build_summary_row(account_name, five_hour, weekly)


def main() -> None:
    args = parse_args()
    auth_paths = get_auth_paths(args.account_dir, args.account_name)
    if not auth_paths:
        print("No auth files found.", file=sys.stderr)
        sys.exit(1)

    exit_code = 0
    summary_rows: list[JSONDict] = []
    for auth_path in auth_paths:
        current_exit_code, summary_row = fetch_chatgpt_usage(auth_path, args)
        exit_code = max(exit_code, current_exit_code)
        if summary_row is not None and not args.raw_json:
            summary_rows.append(summary_row)

    if summary_rows:
        print_summary_rows(summary_rows)
    sys.exit(exit_code)


if __name__ == "__main__":
    main()

Windows LAN Access Ollama API セットアップガイド

Sat, 11 Apr 2026 16:43:52 +0800

LAN 内の他のデバイスがローカル Ollama API にアクセスできるようにする場合は、次のように設定できます。

リスニングポートを設定する

まず、Ollama リスニングアドレスをすべてのネットワークカードに変更します。

OLLAMA_HOST=0.0.0.0:11434

ファイアウォールを開く

詳細なファイアウォール設定を開いた後、新しい受信ルールを作成し、ターゲットポート (8080 など) を許可します。

Win + S を押して、「Windows Defender ファイアウォール」を検索して開きます。
「詳細設定」をクリックします。
「受信ルール」→「新しいルール…」を選択します。
ルールの種類として「ポート」を選択し、「次へ」をクリックします。
プロトコル（通常はTCP）を選択し、「特定のローカルポート」に開放するポート番号（例：8080）を入力し、「次へ」をクリックします。
「接続を許可する」を選択し、「次へ」をクリックします。
「プロファイル」の「ドメイン」「プライベート」「パブリック」にチェックを入れて「次へ」をクリックします。
ルールに名前を付けて (OpenPort8080 など)、「完了」をクリックします。

ラン・オラマ

オラマランモデル

API経由でモデルにアクセス

curl http://192.168.x.xxx:11434/api/generate -d '{
  "model": "gemma4",
  "prompt": "这个是什么模型?"
}'

Ollama クラウドモデルとは何か、そしてその使用方法

Thu, 09 Apr 2026 18:42:32 +0800

普段 Ollama を使用してローカルモデルを実行している場合は、クラウドモデルを簡単に理解できるはずです。

主要な相違点は 1 つだけです。
ローカルモデルはユーザーのコンピューター上で推論され、クラウドモデルは Ollama のクラウド上で推論され、結果が返されます。

クラウドモデルとは何ですか

Ollama クラウドモデルは、Ollama の呼び出し方法を保持しますが、コンピューティングの場所をローカルからクラウドに変更します。

これを行うことの利点は次のとおりです。

ローカルハードウェアへの負担が軽減される
ローカルマシンでは実行できない大規模なモデルを使いやすくする
使い慣れた Ollama ワークフローを引き続き使用できます

現地モデルとの違い

对比项	本地模型	云模型
运行位置	本机	云端
硬件要求	高	低
延迟	更低	受网络影响
隐私性	更强	请求会发送到云端

プライバシー、低遅延、オフライン使用を重視する場合は、ローカルモデルの方が適しています。
ローカルのハードウェアでは十分ではないが、より大規模なモデルを体験したい場合は、クラウドモデルの方が便利です。

クラウドモデルを特定する方法

現在の Ollama クラウドモデルには通常、サフィックス -cloud が付いています。次に例を示します。

`1`	`gpt-oss:120b-cloud`

利用可能なモデルのリストは変更される可能性があります。Ollamaの公式ページを参照してください。

使用方法

まずログインしてください:

`1`	`ollama signin`

ログイン後、クラウドモデルを直接実行します。

`1`	`ollama run gpt-oss:120b-cloud`

コードから呼び出している場合は、API キーを構成することもできます。

`1`	`export OLLAMA_API_KEY=your_api_key`

Python の例:

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

messages = [
    {"role": "user", "content": "为什么天空是蓝色的？"}
]

for part in client.chat("gpt-oss:120b-cloud", messages=messages, stream=True):
    print(part["message"]["content"], end="", flush=True)

まとめ

Ollama クラウドモデルは、次の一文で理解できます。

コマンドは基本的に同じままですが、モデルはローカルで実行されなくなります。

コンピューターで大規模なモデルを実行できないが、引き続き Ollama を使用してモデルを呼び出したい場合、クラウドモデルは非常に簡単なソリューションです。