Posted:
| Tags:
ai,
codex,
llm,
openai,
operations
Codexの利用量とPrompt Cachingの見方
Codex を ChatGPT plan で重めに使っていると、ローカルログ上は非常に大きな token 数に見える。
ただし、ChatGPT plan の Codex 利用と OpenAI API 課金は同じものではない。ChatGPT plan 側では agentic usage limit と rate limit で制御され、API 側では input / cached input / output の token 単価で課金される。
このメモでは、ローカルの ~/.codex から次を確認する。
- 月次でどのくらい使っているか
- cached input がどの程度効いているか
- 短文脈と長文脈の割合
- API 課金に近い概算を見る時の注意点
ローカルログの構造
Codex CLI は ~/.codex 配下に session JSONL と SQLite のローカル状態を持つ。
月次統計の主データとして使うのは session JSONL の event_msg / token_count event である。
現在の JSONL では、usage は top level ではなく payload.info.last_token_usage に入っている。
Read more...Posted:
| Tags:
agent,
ai,
codex,
llm,
operations
何が起きたか
AI agent に、自宅検証環境の復旧と設計相談を任せていた。
使っていたのは GPT 5.5 xhigh の coding agent で安定してた。それでも、既存ドキュメントに残っていた重要な制約を、計画上の制約として扱いきれなかった。
具体的には、ある Windows app installer を Wine / container / Kubernetes volume 上で動かす検証で、install destination が local disk として見える必要があった。
Linux 側では path が見えており、Kubernetes volume として mount でき、read/write もできる。しかし app 側はそれだけでは通さない。Windows API 的に remote filesystem と判定されると installer が止まる(NFS上にストレージを置くとエラーになる)。
# TF_VAR_xpra_basic_auth_htpasswd: ‘kaoru:$2y$05$replace_with_htpasswd_output_after_changeme’
Wine / Windows app の文脈では、たとえば GetDriveType("C:\\") が DRIVE_FIXED なのか DRIVE_REMOTE なのかが効く場合がある。
この制約は過去ログや既存メモに残っていた。しかし AI agent は、復旧計画を立てる時点でそれを制約事項に昇格できなかった。
推論力不足ではなく制約抽出の失敗
この失敗は、単純な推論力不足とは少し違う。
AI は関連ログを読めば、NFS-backed path が local disk と見なされず installer が失敗したことを説明できた。つまり、後から問われれば正しく整理できる。
Read more...