ryoppippi

8 jq Commands That Show What Your Coding Agent Actually Did, From Its Transcript - Book: LLM Observability Pocket Guide - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- Forty minutes of scrollback sit above the line that says the refactor is done and the tests pass. Did the agent run git push somewhere in there? Did it touch the migrations folder? Did half its tool calls fail before one worked? You don't have to scroll. Claude Code writes every session to a JSONL file under ~/.claude/projects/: "messages, tool calls, and tool results", in plaintext, kept for 30 days by default through cleanupPeriodDays. Codex writes rollout files under ~/.codex/sessions (openai/codex discussion #46774). Both are one JSON object per line, which is exactly what jq is good at. Below are eight jq commands: seven for Claude Code, one set for Codex, each next to a trimmed sample of the lines it reads. Neither vendor documents these files as a stable, versioned format, and I haven't run these commands myself: they're built from the documented fields and the public samples linked below. So start with the first block and look at your own file before you trust any of them. Find the file, then look at one line # newest Claude Code session, any project T=$(ls -t ~/.claude/projects/*/*.jsonl | head -1) # newest Codex rollout R=$(ls -t ~/.codex/sessions/*/*/*/rollout-*.jsonl | head -1) # what kinds of lines are in it jq -r '.type' "$T" | sort | uniq -c | sort -rn Each project gets a folder named after its working directory, with every character that isn't a letter or digit turned into - (docs). Replace the first * with *my-repo* to stay inside one repo. A tool call arrives in an assistant line. Pretty-printed and trimmed to the fields the commands use, it looks like this: {"type": "assistant", "timestamp": "2026-10-14T10:01:39.120Z", "message": { "id": "msg_01...", "model": "claude-opus-5-5", "content": [ {"type": "tool_use", "id": "toolu_01...", "name": "Bash", "input": {"command": "npm test"}}]}} Its result comes back later in a user line, matched by tool_use_id (this walkthrough explains the pairing): {"type": "user", "timestamp": "2026-10-14T10:01:41.002Z", "message": {"role": "user", "content": [ {"type": "tool_result", "tool_use_id": "toolu_01...", "is_error": true, "content": "Permission to use Bash with command ..."}]}} Three things to know before you start. Subagents write their own transcripts, in the same format, under <session>/subagents/ (docs); when that folder exists, pass "$T" "${T%.jsonl}"/subagents/*.jsonl to any command below to include them (with no match, zsh aborts the command and bash hands jq the literal pattern). The hooks reference says the transcript "is written asynchronously and may lag" (hooks), so on a running session the newest line can be incomplete. For the per-line commands, jq -R 'fromjson? | ...' skips a line that won't parse; for the -s commands, swap -s for -Rn and start the filter with [inputs | fromjson?] |. And the file holds whatever passed through a tool, .env values included (docs), so read the output before you paste it into an issue. What it ran and what it touched 1. Every shell command it ran jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use" and .name=="Bash") | .input.command' "$T" command is the Bash tool's input field in the hooks reference. This lists what the agent asked to run, including commands you denied and commands that failed. Commands 3 and 4 tell those apart. 2. Every file it edited or wrote jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | select(.name | IN("Edit", "Write")) | .input.file_path' "$T" | sort | uniq -c | sort -rn Both tools take a file_path (hooks reference). The count shows which files it kept coming back to. What this misses: anything changed through Bash, such as a sed -i, a formatter or a codegen script. For those, git status and git diff are the source of truth. !A long paper tape of identical log lines spilling from a small terminal window, with a magnifying glass picking out one orange line A transcript is one line per event. jq pulls out the few lines that answer your question. What went wrong 3. Every tool call that came back as an error jq -rs 'def b: .message.content // [] | arrays | .[]; (map(b | select(.type=="tool_use") | {(.id): .name}) | add) as $n | .[] | b | select(.type=="tool_result" and .is_error) | [($n[.tool_use_id] // "?"), (.content | tostring | .[0:100])] | @tsv' "$T" -s reads the whole file into one array (jq manual), which lets the first pass build a map from call ID to tool name. The second pass prints the tool name next to the first 100 characters of each error. A long run of errors on one tool is usually where the session went sideways. 4. Permission denials jq -r 'select(.type=="user") | .message.content[]? | select(.type=="tool_result" and .is_error) | .content | tostring | select(test("has been denied"))' "$T" A command blocked by your permission rules comes back with text like "Permission to use Bash with command ls ~/private-dir/ has been denied." (anthropics/claude-code #45200). In auto mode there's a better record going forward: a PermissionDenied hook receives the reason, such as [Irreversible Local Destruction] (hooks reference). 5. The five slowest tool calls jq -rs 'def b: .message.content // [] | arrays | .[]; def ms: (.[0:19] + "Z" | fromdateiso8601) * 1000 + (.[20:23] | tonumber? // 0); (map(.timestamp as $t | b | select(.type=="tool_use") | {(.id): {t: ($t | ms), name, input}}) | add) as $c | [.[] | .timestamp as $t | b | select(.type=="tool_result") | $c[.tool_use_id] as $u | select($u) | {s: ((($t | ms) - $u.t) / 1000), name: $u.name, what: ($u.input | tostring | .[0:60])}] | sort_by(.s) | reverse | .[:5][] | [.s, .name, .what] | @tsv' "$T" The transcript has no duration field, so this subtracts the call's timestamp from its result's. The ms helper cuts the milliseconds off before fromdateiso8601 and adds them back, so the math doesn't depend on how your jq build handles fractional seconds. The gap also includes the time the call sat on a permission prompt waiting for you. If you want clean numbers from now on, PostToolUse hooks receive duration_ms, which "excludes time spent in permission prompts" (hooks reference). Why it changed course, and which model did the work 6. What it said right after each failure There is no field for "changed approach". The closest thing is the first thing the agent wrote after a tool call failed, because that is usually where it explains the new plan. jq -rs 'def b: .message.content // [] | arrays | .[]; [.[] | .type as $r | b | if .type == "tool_result" and .is_error then null elif $r == "assistant" and .type == "text" then .text else empty end] | . as $s | range(1; length) | select($s[. - 1] == null and $s[.] != null) | "--- \($s[.][0:300])"' "$T" The first pass builds a list with a null for every failed call and the agent's text for everything it said. The second prints each piece of text that follows a failure. Read three or four of these and you usually know whether it adapted or kept retrying the same thing. 7. Which model answered, counted once per response jq -rs 'map(select(.type=="assistant")) | unique_by(.message.id) | group_by(.message.model)[] | [.[0].message.model, length] | @tsv' "$T" The unique_by matters. One API response can be written as several lines that share a message.id and the same usage object, so counting lines over-counts. I went through that in Summing Claude Code's Transcript Usage?, and ccusage dedupes on message.id plus requestId for the same reason. Run it on the subagent files too: a subagent definition can set its own model (subagent frontmatter). 8. The same questions for Codex A Codex rollout line has a timestamp, an outer type and a payload. The outer types include session_meta, turn_context, response_item and event_msg (toolpath-codex types, which mirror the upstream Rust types). Trimmed, with most values elided. The function_call payload is copied from a fixture in that crate's source: {"timestamp": "...", "type": "turn_context", "payload": {"cwd": "...", "model": "..."}} {"timestamp": "...", "type": "response_item", "payload": {"type": "function_call", "name": "exec_command", "arguments": "{\"cmd\":\"pwd\"}", "call_id": "call_1"}} {"timestamp": "...", "type": "event_msg", "payload": {"type": "token_count", "info": { "total_token_usage": {"input_tokens": ..., "cached_input_tokens": ..., "output_tokens": ..., "reasoning_output_tokens": ..., "total_tokens": ...}}}} For Codex: # model per turn jq -r 'select(.type=="turn_context") | .payload.model' "$R" \ | sort | uniq -c # every tool call, name first jq -r 'select(.type=="response_item") | .payload | select(.type=="function_call" or .type=="custom_tool_call") | [.name, ((.arguments // .input) | .[0:100])] | @tsv' "$R" # cumulative token totals at the end of the session jq -c 'select(.payload.type == "token_count") | .payload.info.total_token_usage // empty' "$R" | tail -1 model is a field of the turn context in Codex's protocol source, and total_token_usage includes input_tokens, cached_input_tokens, output_tokens, reasoning_output_tokens and total_tokens in the same file. Tool calls come in two shapes: function_call with arguments as a raw JSON string, and custom_tool_call with a free-form input, such as an apply_patch body (toolpath-codex types). Tool names and argument keys change between Codex releases, so list the names first. Then parse .arguments | fromjson for the tool that runs shell commands in your version, and look for the command under cmd (as in the fixture above) or command. Where Hermes fits I build Hermes IDE, so weigh this section with that in mind. Hermes runs Claude Code, Codex and other agents side by side, each in its own terminal and its own worktree. When an agent doesn't report its own cost, Hermes estimates spend from that agent's transcript. Each session shows "the cost an agent reports, or an estimate from its transcript clearly marked as estimated, with token totals" (README). !A Claude Code session in Hermes with the /context breakdown open, context gauges in the sidebar, and the status strip showing the token total and estimated cost Hermes 2.3.4: Claude Code's /context breakdown, the per-session context gauges in the sidebar, and the status strip with the token total and estimated cost. Conceptually, an estimate like that is close to command 7's dedupe plus each response's token usage summed per model, with a price list on top. The counting is where it gets hard. Hermes 2.2.9's release notes include: "Cost and token totals no longer grow while a session sits open: each session's usage is counted once." The jq commands above stay useful next to it. Hermes answers how much a session cost; the transcript answers what the agent did. For what changed on disk, Hermes saves every agent turn, and the Review Desk (⌘G, Ctrl+Shift+G on Windows and Linux) shows the changes by turn or by file. !Codex and Claude Code sessions side by side in Hermes, each in its own hermes/ worktree, with a sidebar listing status, context use, cost and branch Hermes 2.3.4: Codex and Claude Code side by side, each in its own hermes/ worktree, with the sessions sidebar showing status, context use, cost and branch. Hermes is free to download, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It isn't affiliated with Anthropic, OpenAI or Nous Research. Which of the eight questions do you ask most after a long session? Tell me in the comments, along with the one you'd add. --- If this was useful If you run more than one agent, Hermes IDE puts them in one window with spend per session, and a star on GitHub helps other developers find it. These eight commands are tracing by hand: one session, one file, one question at a time. The LLM Observability Pocket Guide is about doing that for a whole team, and about picking the tracing and evals tools that make it routine instead of a jq session. 

トークンの節約法について整理してみた きっかけ 普段 Claude Code を何となく使っていますが、トークンがどこでどれだけ消費されているのかはあまり意識したことがありませんでした。 普段何気なくやってることがトークンコストの観点で得なのか損なのかも分からないままでした。 そこで仕組みの調査・自分の素朴な疑問点を解消するベースで、開発体験を損なわずにトークンを節約する方法を整理してみました。 この記事の結論 整理した結果、自分が採用することにしたのは次の4つです。 やること 理由 1タスク1セッション。別のタスクに移るときは /clear 関係ない履歴が、毎ターン入力に乗り続けるから /compact は、同じタスクをまだしばらく続けるときだけ使う。終わりかけなら使わない compact 自体が大きなリクエストで、元を取るのに13ターン前後かかるから モデルを切り替えたくなったら、計画や進捗をファイルに書き出して /clear してから切り替える 履歴を抱えたまま切り替えると全履歴の書き込み直しになり、元を取るのに十数ターンかかるから 帰る前に引き継ぎを書き出して、翌朝は /clear から始める キャッシュが有効なうちなら安く、古い情報も持ち越さないから 記事内で、それぞれの根拠を詳しく見ていきます。 トークンが消費される仕組み（ざっくり） 毎ターン、会話全体が送り直されている Claude は会話の内容を覚えているわけではないので、それまでの会話全体を毎回入力として受け取っています。 つまり、同じ「1往復」でも、セッションが長くなるほど1回あたりの入力トークンは増えていきます。 入力に乗るものは、大きく2種類に分けられます。 種類 中身 固定で乗るもの システムプロンプト、ツール定義、CLAUDE.md、MCP サーバーのツール定義 積み上がるもの 自分とのやり取り、読み込んだファイル、コマンドの出力（テストログなど） プロンプトキャッシュのおかげで、実際はそこまで高くない 毎回全部を送り直していると聞くと高そうですが、前回と同じ先頭部分はキャッシュから安く読める仕組みがあります。 Claude Code では、これがデフォルトで自動的に使われています。 キャッシュから読む: 通常の入力単価の1/20（Opus 5.5 / Sonnet 5.5 の場合） キャッシュに書き込む: 通常の入力単価の2倍（有効期限1時間の場合。5分の場合は1.25倍） 最後に使ってから有効期限が過ぎると、キャッシュは切れる 有効期限は使い方で変わります。Claude Code の公式ドキュメント（Prompt caching）によると、Claude Code はサブスクリプションのプラン内で使っている場合は1時間、API キーや追加の利用クレジットで使っている場合は5分です。 自分の環境（サブスクリプション）でログを確かめてみると、実際に1時間が境目になっていました。前のリクエストからの間隔ごとに、キャッシュから読めた割合を集計した結果です。 前のリクエストからの間隔 キャッシュから読めた割合（中央値） 5分未満 99% 5分〜1時間 100% 1時間〜2時間 5% 2時間以上 8% つまり、サブスクリプションなら1時間以内の休憩ではキャッシュは残っています。 逆に、翌日の再開では必ず切れています。 この記事の試算は、この「サブスクリプション・有効期限1時間」を前提にしています。 キャッシュは何を、どの単位で持っているのか キャッシュは「セッションごと」ではなく、「モデル」と「入力の中身」で管理されています。 入力は毎回「ツール定義 → システムプロンプト → 会話履歴 → 今回の入力」の順に並んでいます。キャッシュが使えるのは、このうち前回のリクエストと、先頭から順番に見てまったく同じ部分だけです。 例えば、2ターン目のリクエストはこうなります。 入力の中身 1ターン目にも送ったか キャッシュ ツール定義 送った（同じ） 読める システムプロンプト 送った（同じ） 読める 1ターン目の質問と回答 送った（同じ） 読める 2ターン目の質問 初めて送る 書き込む 会話は後ろに足されていくだけなので、普段は前回までの部分がまるごとキャッシュから読めます。 ただし、途中の1か所でも前回と違うと、そこから後ろはすべて読めなくなります。 例えばシステムプロンプトが少しでも変わると、その後ろの会話履歴が前回とまったく同じでも、全部書き込み直しになります。「どこまで前回と同じだったか」を先頭から順に見ていく仕組みなので、途中で違いが出たら、そこで打ち切られるイメージです。 緑がキャッシュから読む部分、赤が新しく書き込む部分です。 中身が同じなら、別のセッションでもキャッシュは共有されます。ツール定義やシステムプロンプトのように、どのセッションでも同じ部分は使い回されています。 キャッシュの中身そのものは見えませんが、どれだけ読み書きされたかは確認できます。 Claude Code は ~/.claude/projects/ 以下に JSONL 形式でログを残していて、リクエストごとに cache_read_input_tokens（読んだ量）と cache_creation_input_tokens（書き込んだ量）が記録されています。日別・セッション別にざっくり見たいなら、このログを集計してくれる ccusage（npx ccusage@latest）が手軽です。 ! この記事で「ログで確認した」と書いているのは、個人端末のログです。使用量は業務の開発とかなり違うので、使用量の数字は載せず、キャッシュの挙動の確認にだけ使っています。 キャッシュが原因で悪さはしないのか キャッシュは中身が見えず、自分でクリアすることもないので、意図せず放置したままになります。 そこで気になっていたのが、「放置したキャッシュが回答の精度を下げないか」と「保持しておくこと自体にコストがかからないか」の2つでした。 結論はどちらも問題ありません。 精度は下がらない: キャッシュは「前回と完全に同じ部分の計算結果」を使い回しているだけで、余計な情報が足されることはありません。Claude が見ている内容は、キャッシュがあってもなくても同じです 保持コストはかからない: 料金が発生するのは書き込むときと読むときだけで、使わなければ自動で消えます 精度に影響するのは、キャッシュではなくコンテキスト（会話履歴そのもの）の方です。 キャッシュ コンテキスト 中身は見えるか 見えない /context で見える 精度への影響 なし あり（不要な情報が残ると落ちる） 自分で消す必要 なし（自動で切れる） あり（/clear、/compact） キャッシュについて気をつけるべきなのは、「知らないうちに外れて割高になる」ことだけです。Claude Code の公式ドキュメントと Claude API の公式ドキュメントで確認すると、外れる操作と外れない操作は次の通りでした。 操作 キャッシュ モデルを切り替える 外れる（すべて） 有効期限を過ぎて放置する 外れる（すべて） システムプロンプトが変わる 外れる（すべて） effort を変える（Opus 5.5 / Sonnet 5.5 などの新しいモデル） 外れない 途中で MCP サーバーを追加する（ツール検索が有効な場合。デフォルトで有効） 外れない 途中で CLAUDE.md を編集する 外れない（ただし、そのセッションには反映されない。下で説明） 普段の使い方で気にするべきなのは、モデルの切り替えと放置の2つくらいです。 セッションの途中で CLAUDE.md を編集したらどうなるか 作業中に「これは CLAUDE.md に書いておこう」と編集することがありますが、公式ドキュメントによると、その編集は今のセッションには反映されません。 プロジェクト直下とユーザー単位の CLAUDE.md は、セッション開始時に1回だけ読み込まれ、そのまま使われ続ける 編集した内容が反映されるのは、次に /clear・/compact・再起動したとき サブディレクトリの CLAUDE.md は、そのディレクトリのファイルを触ったときに初めて読み込まれるので、読み込まれる前の編集なら反映される コスト面では、編集してもキャッシュは外れないので、途中で直すこと自体はタダです。 ただ、すぐには効かないので、「CLAUDE.md を直したのに Claude が従わない」と感じたら、反映されていないだけかもしれません。CLAUDE.md の修正はタスクの区切りでまとめて行い、/clear で反映させるのがちょうどいいと思います。 モデルごとのコスト差 Claude の主なモデルの API 単価は次の通りです（100万トークンあたり、2026年11月時点。出典: Pricing）。 モデル 入力 出力 キャッシュ書き込み（1時間） キャッシュ読み Fable 5.1 $10.00 $50.00 $20.00 $0.25 Opus 5.5 $4.00 $20.00 $8.00 $0.20 Sonnet 5.5 $2.00 $10.00 $4.00 $0.10 Haiku 5.5 $0.10 $0.50 $0.20 $0.01 ※ Haiku 5.5 は10万トークンまでの単価です。 表を見て気づいたことが3つあります。 キャッシュが効いていれば、入力より出力の方が高くつく Opus 5.5 なら、10万トークンの履歴をキャッシュから読んでも$0.02です。一方で、出力（思考を含む）は2Kトークンで$0.04かかります。長いセッションでも、キャッシュさえ効いていれば、コストの中心は出力になります。 Haiku は桁違いに安い Opus の1/40なので、ちょっとした質問なら Haiku で十分なことも多そうです。 モデル選びと同じくらい、effort（思考の深さ）が効く 思考は出力トークンとして課金されるので、同じモデルでも effort の設定で出力量が大きく変わります。 文脈集めにどれだけ使っているのか セッションを始めたときや、ソースコードを読ませて文脈を集めるときに、かなりトークンを使っている気がしていました。 セッション開始時点で、すでに固定部分が乗っている 何も作業していない最初のリクエストの時点で、システムプロンプト・ツール定義・CLAUDE.md・MCP などの固定部分が乗っています。 入れている MCP サーバーやスキルの数で大きく変わるので、自分の環境の値は /context で確認するのが確実です。使っていない MCP サーバーや、肥大化した CLAUDE.md は見直す価値があります。 一番効いてくるのは、ファイルの読み込みとコマンドの出力 一度読み込んだファイルや出力は、その後のターンでもずっとコンテキストに残り続けます。 つまり、最初の文脈集めで読み込んだ量が、そのセッションの残りすべてのターンの重さを決めます。 節約するなら、次の3つが開発の速さを落とさずにできます。 方法 効果 依頼するときに、関係するファイルやディレクトリを指定する 探索のための読み込みが減る CLAUDE.md に「どこに何があるか」を短く書いておく 毎回の探索が減る（CLAUDE.md は毎ターン乗るが、キャッシュで安い） テストやビルドの出力を絞る 不要なログがコンテキストに残らない サブエージェントは裏で勝手に起動しているのか 見えないところでサブエージェントが勝手に起動して、トークンを食っている気もしていました。 サブエージェントは、Claude が自分の判断で起動します。ただし完全に裏で動いているわけではなく、起動するときはツール呼び出しとして画面に表示されます。出力が折りたたまれていると見落としやすいだけです。 サブエージェントは親とは別のコンテキストで作業し、親には結果の要約だけを返します。広い調査を任せれば親のコンテキストが膨らまない一方、毎回ゼロから文脈を集めるので、起動しすぎるとその分コストがかさみます。 意外だったのは、調査用の組み込みサブエージェント（Explore）が、デフォルトではメインの会話と同じモデルで動くことです（公式ドキュメント（Subagents））。メインが Opus なら、調査も Opus で行われます。 気になる場合は、開発の速さを落とさない範囲で次のような手が打てます。 方法 強さ 内容 サブエージェントを安いモデルで動かす 弱 環境変数 CLAUDE_CODE_SUBAGENT_MODEL=haiku を設定する。カスタムエージェントなら定義に model: haiku と書く CLAUDE.md にルールを書く 弱 「サブエージェントは広い調査のときだけ使う」など 起動前に確認を求める 中 権限設定で Agent ツールを ask にする まずは、安いモデルで動かす設定だけで十分だと思います。 「作り直し」が起きる3つの場面 ここからは、普段自分が何気なくやっていて「これって損してない？」と気になっていた3つの操作を見ていきます。 セッションの途中でモデルを切り替える /compact する セッションを放置して、翌日そのまま再開する この3つはどれも、キャッシュやコンテキストを作り直す操作です。 どれも「最初に1回、余分なコストを払う代わりに、その後の1ターンあたりが安くなる」という形をしています。 なので考え方は共通で、「最初に払った分を、その後の安くなった分で取り戻せるか」で損得が決まります。 例えば /compact に$0.31かかっても、その後1ターンあたり$0.024安くなるなら、13ターン続ければ取り戻せます。逆に、5ターンで作業が終わるなら、払った分を取り戻せずに損をします。 以下の試算は、すべて Opus 5.5 の単価・キャッシュの有効期限1時間を基準にしています（API キーで使う場合は有効期限5分・書き込み1.25倍なので、金額はもう少し下がります）。 セッション途中のモデル切り替え 結論: 負担は「切り替えた直後の1回」。ちょっとした用事のために切り替えると元が取れません。 キャッシュはモデルごとに別管理なので、モデルを切り替えると、次のターンでそれまでの履歴をすべて新しいモデル用に書き込み直すことになります。 一方で、元のモデルのキャッシュは1時間残っているので、1時間以内に戻るなら戻る側の負担はほとんどありません。 ログでも、この挙動を確認できました。 操作 キャッシュから読めた割合 Opus → Sonnet に切り替えた直後（約17万トークン） 14% その3分後に Sonnet → Opus に戻した直後 98% 10万トークンのセッションで試算すると、次の1ターンの入力コストはこうなります。 操作 次の1ターンの入力コスト Opus のまま続ける 約$0.02 Sonnet に切り替える 約$0.40 1時間以内に Opus に戻す 約$0.02（＋Sonnet で増えた分の書き込み） 1時間以上たって Opus に戻す 約$0.80 Sonnet に切り替えて節約できるのは、1ターンの出力を2Kトークンと仮定すると、出力とキャッシュ読みを合わせて約$0.03です。 つまり、切り替えで払った分を取り戻すには、十数ターン Sonnet で作業を続ける必要があります。 切り替えるなら、セッションの冒頭か /clear の直後にします。コンテキストが小さいうちなら、作り直しの負担はほとんどありません。 作業の途中で切り替えたくなったときは、計画や進捗をファイルに書き出してもらってから /clear し、新しいモデルにそのファイルを読ませると、文脈を引き継ぎつつ負担を小さくできます。 /compact は節約になるのか 自分はよく /compact を使うのですが、これが節約になっているのかは正直分かっていませんでした。 結論: その後も作業を続けるなら得。終わりかけのタイミングでやると損です。 /compact は、それ自体が「全履歴を読んで要約を出力する」1回分のリクエストです。公式ドキュメント（Manage costs effectively）にも、大きなコンテキストの compact はそれ自体が大きなリクエストになる、と書かれています。要約は出力トークン扱いなので、単価も高めです。 その代わり、終わった後はコンテキストが小さくなり、1ターンあたりのコストが下がります。 要約の大きさの目安として、ログに残っていた自動 compact（1件）を見ると、約40万トークンの履歴が約1.2万トークンの要約になっていました。 これをもとに、15万トークンのセッションで、要約が1万トークン、compact 後のコンテキストが固定部分を含めて3万トークンになると仮定して試算します。 操作 コスト そのまま続けた場合の1ターンの入力 約$0.03 /compact 1回 約$0.31（読み込み$0.03 + 要約の出力$0.20 + 要約の書き込み$0.08） compact 後の1ターンの入力 約$0.006 1ターンあたり約$0.024安くなるので、この試算では13ターン前後で元が取れます。 思っていたより取り戻すのに時間がかかるので、「あと数ターンで終わる」タイミングの compact は損です。 また、要約から漏れた情報を取り戻すために Claude がファイルを読み直すことがあり、その分のトークンもかかります。 /clear との使い分けは次の通りです。 状況 おすすめ 別のタスクに移る /clear（コストゼロで、一番小さくなる） 同じタスクをまだしばらく続ける 指示つきの /compact（例: 「〇〇の実装方針だけ残して」） 同じタスクだが、あと数ターンで終わる 何もしない（compact しても元が取れない） セッションを何日も使い続けるのはアリか 自分はセッションを閉じずに放置して、翌日そのまま再開することがよくあります。作業が途中のこともありますし、何よりコンテキストが残っている方が早いからです。 結果として、1つのセッションをタスクが終わるまで何日も使い続けています。 結論: お金の面では大きな損ではありません。問題になるのは、コンテキストの「重さ」と「古さ」です。 再開した最初の1ターンだけ割高になる 翌日にはキャッシュが必ず切れているので、全履歴を書き込み直します。15万トークンのセッションなら1日1回約$1.20で、一から説明し直すコストと比べると大差ないこともあります。 コンテキストが膨らみ続ける 毎ターンの入力が重くなり、自動の compact も発生しやすくなります。そのたびに要約で文脈の精度が少しずつ落ちます。 コンテキストの情報が古くなる（一番危ない） pull や他の人の変更があっても、Claude は前日に読んだファイルの内容のまま作業します。古いコードを前提に編集してしまう可能性があり、これはトークンではなく品質の問題です。 そこで、「コンテキストがあるから早い」というメリットを残しつつ、重さと古さを避ける運用にすることにしました。 タイミング やること 帰る前 進捗・決まったこと・次にやることをファイルに書き出してもらう 翌朝 /clear してそのファイルを読ませる 再開時 pull などで変更があれば「関連ファイルを読み直して」と一言添える ポイントは、書き出しを翌朝ではなく帰る前にやることです。最後の作業から1時間以内ならキャッシュがまだ有効なので、全履歴を安く読めます。 タイミング 全履歴（15万トークン）を読むコスト 帰る前（キャッシュ有効） 約$0.03 翌朝（キャッシュ切れ） 約$1.20 同じ操作でも、タイミングだけで料金が大きく変わります。 迷ったら「払った分を取り戻せるか」だけ考える モデルの切り替えも、/compact も、翌日の再開も、損か得かは「最初に払う分を、その後の安くなった分で取り戻せるか」で決まりました。 冒頭の4つは、どれもこの判断基準を普段の開発に当てはめたものです。 作業中に迷いやすい場面を、判断の流れにするとこうなります。 ルールを全部覚えておく必要はなく、迷ったときに「これは払った分を取り戻せるか」と考えるだけで十分です。 そして、トークンの節約は、あくまで開発体験を損なわない範囲でやるものです。まずは自分のログや ccusage で使い方を見てみると、どこを削るべきかが見えてくると感じました。 参考 Prompt caching - Claude Code Docs Manage costs effectively - Claude Code Docs Subagents - Claude Code Docs Prompt caching - Claude API Docs Pricing - Claude API Docs ccusage

learnt new thing about cc github.com/ryoppippi/dotfiles/commit/006ee95fd419…

I wanted to know what my $20 AI plans were actually worth, so I built a tool to find out I pay $20 a month each for Claude Pro and ChatGPT Plus, and I use Claude Code and Codex for side projects. I kept wondering which plan was the better deal. Both just say “usage limits apply.” Neither tells you how much you’re getting compared to paying for the API directly. Both tools already save every session to files on your computer, with token counts for each request. So I wrote something that reads those files and prices every request at the official API rates. I compared each tool’s busiest month: ||Busiest month|Tokens|API-equivalent cost|vs. the $20 plan| |:-|:-|:-|:-|:-| |Codex (ChatGPT Plus)|September|223M|$125|~6×| |Claude Code (Claude Pro)|October|582M|$203|~10×| Both plans are worth far more than $20 if you actually use them. My Codex month was also only about two and a half weeks of use, and my claude code usage was about 3 weeks of use. Along the way it turned into a full terminal dashboard. It shows usage per agent, project, session and model, and suggests ways to cut token waste. Everything runs on your machine with no account. It’s called TokenManager: ht2803-max/tokenmanager How is this different from ccusage? ccusage is great, and I used it before building this. It’s the standard tool for quick usage reports, and it now supports more agents than TokenManager does. TokenManager isn’t trying to beat it at reports. It answers a different question: where is my money going, and what should I change? - A dashboard you can move around in: It’s a full-screen terminal app: jump between agents, projects, sessions and models, open any session to see its cost breakdown, and filter by date. It updates live as your agents work. - It keeps your history. Usage is saved to a local SQLite database, so it’s kept even after Claude Code cleans up its old session files (by default after 30 days). Month-over-month comparisons like my Codex-vs-Claude table need that. - It tells you what to change. tokenmanager optimize looks at the last 30 days and points out waste, like oversized context loaded into every request or expensive models used for small tasks, with an estimated saving for each. - Budgets and alerts. Set monthly or daily budgets for everything, or per agent or project. A small background process sends a desktop notification when you get close. - One binary, no Node. brew install and run. There’s also a standalone HTML dashboard if you’d rather look at it in a browser.

why the hell we need this - @bot doesn't know the reset time&usage of subs - @t3code mcp doesn't return it yet - ccusage doesn't use the official api so, i tell @bot to check my limit of subs ryoppippi/t3-limits

/usage を何度も開くのが面倒で、Claude Code のステータスラインを自作してみた ここ数か月、Claude Codeに任せる作業がだいぶ増えました。業務でも個人でも毎日のように使っていて、個人のほうは今のところProプランです。 以前の使用頻度では上限に届くことはほとんどなかったのですが、最近は上限に達することが増えてきました。そうなると、「上限まであとどれくらい残っているか」「自分は実際どれくらい使っているのか」が気になってきて、作業の合間に /usage を開くのが癖になっていました。 1日に何度も開いているうちに、それなら常に見えている場所に出しておけばいいのでは、と思って今回作ったのが tallyline です。 左から、使っているモデル、今の会話のコンテキストの大きさ、5時間と7日間の利用上限に対する使用率、今月の累計トークン数と、それをAPIの従量課金で払った場合の金額です。 pipx install tallyline && tallyline init tallyline init で Claude Codeの設定に登録されます。Claude Codeは設定の変更を自動で読み込むので、再起動しなくてもすぐに表示されます。 作ろうと思った理由 もともと、よく紹介されている簡単なスクリプトを軽くいじってステータスラインを出していました。モデル名やコンテキストの使用率は見られるものの、利用上限の残りや、セッションを横断した使用量などは出せておらず、改めて自分が欲しいものを全部出すものを作ろうと思いました。 上限の残りを見るたびに /usage を開いていた 一番の理由はこれです。上限に達することが増えてからは、長めの作業を始める前や、エージェントに大きめの作業を任せる前に、5時間枠があとどれくらい残っているかを確認したくなります。/usage を開けば分かりますが、作業中の画面から離れて、見て、閉じて、という手間が地味に積み重なっていたため、何かを開かなくても自分が知りたい情報だけを常に見えるところに出しておきたい気持ちがありました。 定額でも、自分がどれくらい使っているかは知りたかった 定額プランなので、請求額という形では使用量が見えません。/usage では上限に対する割合や、直近24時間・7日間の内訳は見られますが、「今月どれくらい使ったか」「先月より増えているのか」といったセッション横断での月単位の量や推移は分かりませんでした。 自分が客観的にどれくらいAIを使えているのかも把握したかったため、上限の何%かではなくトークン数という絶対量が知りたかったです。それも今の会話の分だけでなく、すべての会話を合わせて、月や年の単位でどれくらい使っているかが分かれば、使い方が変わったときにも気づけます。金額は、その量をAPIの料金に換算した目安として添えています。 コンテキストの大きさも、毎回確かめていた 今の会話のコンテキストがどれくらい膨らんでいるかは /context で見られます。ただ、これも打たないと分かりません。長い会話を続けていると、気づいたらかなり大きくなっていることがあって、それも常に見えていてほしいと思っていました。 既存のツールとの違い ステータスラインを作るツールはすでにいくつもあります。代表的なのは次の2つでしょうか。 ccstatusline：ウィジェットやテーマが豊富で、表示する内容を細かく設定できる ccusage：日別・月別・会話別の使用量を、表で詳しく集計できる どちらもよくできていて、ccstatusline はGitのブランチ名からキャッシュの残り時間まで、ほとんど何でも出せます。ただ自分の場合は見たいものがはっきり決まっていて（利用上限の使用率、今の会話のコンテキストの大きさ、月の累計の3つ）、なかでも月の累計をステータスラインに常に出しておけるものは見つかりませんでした。 そのうえで欲しかったのは、次のような点でした。 見たいものだけが、設定しなくても最初からその形で出る 今の会話だけでなく、すべての会話を合わせた月や年の累計が、ステータスラインで常に見える。古い会話の記録が消えても、累計は減らない シンプルで軽い。依存パッケージがなく、使用量などをどこにも送らない 表示の中身 表示 意味 [Opus 5.5] 使用中のモデル ctx 120k (12%) 今の会話のコンテキストの大きさと、上限に対する割合 5h 23% 7d 41% 5時間・7日間の利用上限に対する使用率（Pro / Max プランのみ） Oct 22.1M tok (≈$14.92) このマシンの全会話の、今月の累計トークン数と API 換算の金額 APIの従量課金で使っている場合は、利用上限の代わりに、今の会話で使ったトークン数と金額が出ます。 作るときに工夫したこと 何を出さないかと並び順を決めた ステータスラインは1行しかないので、情報を足すほど読みにくくなります。途中でキャッシュが切れるまでの残り時間も出そうとしましたが、表示が長くなるわりに、作業中に見る場面がほとんどありませんでした。結局、出すのは上の4つだけにしています。また、作業中に気にするのはコンテキストと利用上限で、月の累計はときどき見るくらいなので、作業中に見るものを左にまとめ、累計を右端に移しました。 軽く、手元だけで動く ステータスラインは、応答が届くたびに描き直されます。毎回すべての記録を読み直すわけにはいかないので、前回どこまで読んだかを覚えておき、追記された部分だけを読むようにしました。1回の描画は約0.02秒です。 今回はPythonの標準ライブラリだけで書いていて、ほかのパッケージは使っていません（本体は約34KB）。また、通信するのは1日1回PyPIにtallylineの新しい版が出ていないかを確かめるときだけです（設定で止めれます）。会話の内容や使用量をどこかに送ることはないようにしています。 記録が消えても累計を残し、できる限り小さく保つ Claude Codeは、古い会話の記録を既定では30日で消します（cleanupPeriodDays で変更可能）。そのまま集計すると、年の累計は記録が消えるたびに減ってしまうため、tallylineでは集計した使用量を記録として残し続けるようにしました。 残すのはトークン数だけで、会話の中身は持ちません。自分の個人の環境では、約3か月分で261MBある会話の記録に対して、tallylineの記録は2.1MBでした。1年使っても10MBに届かない見込みです。月や年の累計は日ごとにまとめた表から計算するので、記録が増えても表示は遅くなりません。 使ってみて 実際に使ってみると、作業の合間にステータスラインへ目をやる機会は思っていた以上に多く、常に見えていることの便利さを実感しています。/usage や /context を開くことはほとんどなくなりました。単純に便利になって、作ってよかったというのが一番の感想です。 月の累計が見えるようになって、APIの従量課金との差も実感するようになりました。個人用では現状Proプランではあるのですが、10月は月末を前に10億トークン以上を使っていて、APIの従量課金なら約500ドルになる量でした。Proプランの月額（20ドル）の25倍以上で驚きでした。 コンテキストの大きさが常に見えているのも、思った以上に効いています。最近は、20万トークン前後を目安に、作業の切れ目で /compact するか、新しい会話に切り替えることを意識しています。まだ試している途中ですが、数字が見えているので、切り替えるタイミングを判断しやすくなりました。 使っているうちに、どこに多くのトークンを消費しているのか、効率化の余地はあるのかというところも気になってきました。そこで、使用量を原因ごとに分けて表示する tallyline diagnose と、開いている会話を再開したときの費用を一覧にする tallyline sessions を後から足しました。調べてみると、キャッシュが切れた後の再開など、意外なところに使用量の多くが使われていることがわかり、その対策をこちらもいくつか試している途中です。対策や実際の効果については、また別の記事にできたらと思っています。 今後 これからも、使いながら気になったところを少しずつ直していくつもりです。要望や不具合があれば、GitHubのIssueで教えてもらえるとうれしいです。 /usage を毎回開いて確認しているなど、似たことで手間を感じている人がいればぜひ試してみていただけると幸いです。

i still keep blink for auto completion for command mode, but i don’t need copilot completion anymore dotfiles#6056

i don’t think i need relying on auto completion on neovim anymore. neovim is still great code viewer for me, and still a good editor. i’m still using it for blogging! but i don’t code by hand anymore. it’s time to remove LSP from nvim dotfiles#6054

nostalgic pre-ai era.... github.com/ryoppippi t.co

Хватит ли лимита до сброса? Как я считаю прогноз расхода Claude Code, Codex и Kimi Code У подписки на Claude Code два лимита: пятичасовая сессия и недельное окно. Codex и Kimi Code считают похоже, но окна у них свои: у Kimi бывает месячное, а недельного у новых планов нет. Посмотреть остаток можно командой /usage, но только внутри открытой сессии и только для того аккаунта, под которым она запущена. А меня обычно интересует другое: хватит ли до сброса. 60% к среде — это много или нормально? Если я и дальше буду работать в том же темпе, упрусь ли я в лимит в пятницу вечером? Для этого я сделал claude-limits: маленький локальный сервер, который раз в несколько минут спрашивает лимиты всех найденных логинов и показывает их на одной странице. Главное в ней — прогнозы. Статья о них и о том, как утилита написана на Nova, языке, который я делаю. Страница claude-limits над выдуманными аккаунтами: спокойный, тот, что закончится раньше сброса, заблокированный, Kimi Code и Codex Что видно на странице Каждая карточка — один логин, каждая строка — одно окно лимита. Толстая полоса показывает, сколько уже потрачено: зелёная, с 70% жёлтая, с 90% красная. Под ней тонкая линия: какая доля окна уже прошла. Если полоса обгоняет линию, вы тратите быстрее, чем идёт время. Поверх этого два прогноза, оба штриховкой. На толстой полосе: где окажется расход к моменту сброса, если темп не изменится. Подпись: → 46% at reset. На тонкой линии: до какой доли окна хватит квоты. Если до самого сброса, штриховка зелёная до конца. Первый отвечает на вопрос «сколько останется», второй — «когда кончится». Дальше о том, как они считаются и где я ошибался. Прогноз первый: процент к сбросу Самое простое, что можно сделать, — линейная экстраполяция: взять скорость расхода и продолжить её до сброса. Вопрос только в том, какую скорость брать. Если брать среднюю за всё окно, прогноз будет помнить, что в понедельник вы почти не работали, и врать в четверг. Поэтому скорость считается по свежей истории: для сессии за последний час, для недели и месяца за последние три дня. Скорость — это темп работы, а не свойство окна, так что если окно сбросилось внутри этих трёх дней, хвост прошлого окна тоже идёт в расчёт. Отрезается только участок, где лимит был исчерпан и расход стоял на месте. Сам сброс утилита замечает по резкому падению процента. Дальше арифметика (src/model/forecast.nv): ro rate_x1e6 = (used_percent * 1000000) / window_min // rate <= 0 means the spend did not grow over the window: the honest forecast is // "it stays where it is", not a fall (§2.7). if rate_x1e6 <= 0 { return { available: true, percent_at_reset: percent_now, runs_out_in_min: -1, rate_per_hour_x100: 0, basis, warning: false } } ro at_reset = percent_now + (rate_x1e6 * remaining_min) / 1000000 ro left = 100 - percent_now ro runs_out = if at_reset < 100 { -1 } else { (left * 1000000) / rate_x1e6 } sourcecraft.dev Скорость хранится целым числом, в миллионных долях процента за минуту. Почему не f64: у утилиты есть эталонная реализация на Python, и обе версии должны выдавать одну и ту же подпись до последней цифры. Плавающая точка добавила бы ещё один способ разойтись в последнем знаке. Сначала точность была в сотых, и на одном примере 2,06% в час превращались в 1,80%: при делении 7400 на 2160 целое даёт 3. На десятитысячных момент исчерпания всё равно отставал от эталона на 46 минут. На миллионных расхождение исчезло. Ещё два правила. Прогноз никогда не обещает, что расход упадёт: если за интервал он не вырос, честный ответ — «останется как есть». И если к сбросу выходит больше 100%, считается момент, когда лимит кончится. Подпись тогда становится длиннее: → 103% at reset, ends Fri ~18:40 (14h 58min). Цвет штриховки зависит от прогноза к сбросу: от 80% жёлтый, от 95% красный. Поэтому бывает зелёная полоса на 40% с красной штриховкой до 95%. Так и задумано: сейчас всё хорошо, а к пятнице будет плохо. Когда прогнозу верить рано Первой версии хватало получаса истории. После первого часа работы с 1% недельного лимита она уверенно рисовала красное: если тратить так всю неделю, лимит кончится через четыре дня. Арифметика верная, но один час работы ничего не говорит о неделе. Теперь прогноз появляется, только когда история покрывает хотя бы 5% окна, но не меньше получаса: ro span_ms = now_ms - first.at_ms ro min_span_ms = MIN_SPAN_MS.max(((l.window_sec + 19) / 20) * 1000) if span_ms < min_span_ms { return None } sourcecraft.dev Для сессии это 30 минут, для недели 8 часов 24 минуты, для месячного окна Kimi 36 часов. До этого на странице нет штриховки, а у процента подсказка forecast later. В спецификации это правило прямо названо эвристикой достаточности истории, а не обещанием точности. Прогноз не считается и тогда, когда цифрам нельзя доверять: аккаунт заблокирован, токен просрочен или сервер ответил 429. Прогноз второй: на какую долю окна хватит Когда лимит кончается раньше сброса, процент к сбросу говорит мало. Важнее, сколько ещё можно работать. Для этого тонкая линия под полосой тоже получает штриховку: от точки «сейчас» до момента, когда при текущем темпе кончится квота. Если она не кончится до сброса, штриховка идёт до конца окна и остаётся зелёной. Если кончится раньше, чем пройдёт 95% окна, она жёлтая, раньше 80% — красная. Здесь нашлась ошибка, которую поймал тест. Длину окна сначала брали из ответа сервера, а прогресс — из типа окна (5 часов, 7 дней, 30 дней). Штриховка и заливка мерились разными линейками и расходились на краях. Теперь обе считаются от одного и того же окна. Есть и нерешённый вопрос, он записан в docs/open-questions.md. Две штриховки одной строки красятся по разным шкалам: верхняя по проценту к сбросу (80/95), нижняя по доле окна (80/95 от окна). При прогнозе 97% верхняя уже красная, а нижняя ещё зелёная: лимит кончится, но за считанные минуты до сброса. Обе правы, но рядом это выглядит как противоречие. Пока оставил как есть. Ночь и выходные Линейный прогноз не знает, что ночью вы спите. В пятницу вечером он смотрит на темп рабочего дня и обещает, что к понедельнику лимит кончится. В спецификации так и сказано: без графика прогноз в пятницу вечером всегда «не хватит». Поэтому есть ручной график работы: рабочие дни, часы и доля темпа вне их. Минута внутри графика весит полностью, минута вне его — меньше. Скорость считается по таким «эффективным» минутам, и момент исчерпания тоже ищется проходом вперёд с весами. По умолчанию график выключен: я не хочу, чтобы утилита гадала о чужом расписании. У этого подхода есть слабое место. Если вся свежая история записана ночью, при включённом графике эффективных минут получается ноль. Раньше в таком случае выходил ровный выдуманный прогноз, теперь честное «пока нет данных». У меня ритм задаётся вручную. Учиться ему автоматически — следующий шаг. Откуда берутся цифры Цифры утилита берёт те же, что показывает /usage: у Claude это OAuth-эндпоинт использования, у Kimi Code и Codex свои. Все три не документированы, и это главное ограничение: любое обновление может их сломать. Об этом сказано в README и в описании релиза. Какие логины читать, утилита не угадывает: каталоги с кредами задаются в настройках, как это сделать — в конце статьи. Список перечитывается каждый раунд, так что новый логин появляется без перезапуска. Файлы Claude утилита только читает. Если токен просрочен, она обновляет его запуском самого Claude Code под нужным каталогом и ничего не пишет в его файлы. Токен Kimi обновляется напрямую, а Codex не обновляется совсем. Живые запросы принесли сюрпризы, которых не было в тестах: без заголовка anthropic-beta: oauth-2025-04-20 эндпоинт Claude отклоняет запрос, а моки этого, конечно, не знали; ответ приходит кусками (Transfer-Encoding: chunked), тело начиналось с 9fc, и разбор JSON падал, пришлось написать свой разбор; при ответе 429 первая версия стирала цифры с экрана, ровно когда они нужнее всего. Теперь последний удачный снимок остаётся на месте, приглушённый, с пометкой 429 · retry HH:MM · data HH:MM: когда будет повтор и от какого времени цифры. Почему на Nova claude-limits — первая настоящая программа на Nova: около 17 тысяч строк кода и почти столько же тестов, HTTP-клиент с TLS, веб-сервер на Polaris, веб-фреймворке, который тоже написан на Nova, история в DuckDB. DuckDB — встраиваемая база, как SQLite, только с упором на аналитические запросы. Она собрана прямо в исполняемый файл, ставить отдельно ничего не нужно. Три возможности языка здесь пригодились больше всего. Эффекты в сигнатуре. Функция, которая собирает данные по всем аккаунтам, объявляет, с чем работает: fn collect_round(rounds Rounds) Http Dirs Creds Time -> Round. Dirs и Creds — свои эффекты для каталогов и токенов, и у них нет операций записи. Записать в файлы Claude такой код не может: соответствующую операцию просто нечем вызвать. Тесты без мок-фреймворка. Сеть и время подменяются обработчиком прямо в тесте: fn poll_against(raw str) -> AccountState { mut state = AccountState.Unknown with Http = effect Http { send(host, port, secure, request) -> Result[str, HttpError] { Ok(raw) } } { state = fetch("api.example.com", 443, true, "/v1/usage", "t").outcome.state } state } sourcecraft.dev Функция fetch та же, что в боевом коде, только сеть отвечает заранее заданной строкой. Так проверяются и 429, и разбор кусков, и истёкшие токены. Токен как ресурс. Тип Secret объявлен consume: его нельзя скопировать, а при отладочной печати он выводит Secret(hidden). Токен нельзя случайно положить в лог или передать в два места. Было и трудное: язык молодой, в компиляторе пока есть ошибки. Несколько типов пришлось переименовать: Outcome столкнулся с другим именем в сгенерированном C, Token — с одноимённым типом из стандартной библиотеки JSON, а Forecast путал проверку типов с типом настроек config.Forecast. Был дефект, из-за которого все моменты времени читались как полночь. Эти ошибки чинились в компиляторе, а утилита работала тестом для них. Чем это отличается от аналогов Прогнозировать расход умеют и другие утилиты. ccusage в режиме blocks --live показывает скорость и прогноз на пятичасовое окно. Он считает по локальным логам и сравнивает с лимитом, который вы задаёте сами. claumon берёт те же официальные цифры и даёт прогноз к сбросу с интервалом. Claude Code Usage Monitor и ReserveGauge тоже прогнозируют, второй помнит несколько аккаунтов. Claude Tuner считает скорость по активным часам и сам учитывает недельный ритм пользователя. По данным автора, переоценка днём от этого упала на 63%. Что есть в claude-limits: все логины на одной странице, причём сразу трёх сервисов: Claude Code, Codex и Kimi Code; официальные цифры /usage, те же, что в самом Claude Code; два прогноза на каждое окно: процент к сбросу и доля окна, на которую хватит; рабочие дни и часы задаются в настройках, и ночь с выходными не раздувают прогноз; история с сохранением; уведомления в браузере на 70% и 90%. Ограничения Эндпоинты не документированы и могут сломаться. Прогноз — линейная экстраполяция по двум точкам, без сглаживания. Ритм дня учитывается только через ручной график. Готовая сборка есть для Windows x64. На Linux пока работает эталонная реализация на Python из того же репозитория, а на macOS токены лежат в Keychain, и это вне рамок. После ответа 429 утилита пока не делает паузу для отдельного аккаунта: все аккаунты опрашиваются с общим интервалом, по умолчанию раз в 5 минут. Как попробовать Скачайте claude-limits-0.1.1-windows-x64.zip со страницы релизов и распакуйте. Запустите claude-limits --serve и откройте в браузере 127.0.0.1. Сначала страница пустая: логины утилита сама не ищет. Откройте настройки (кнопка вверху страницы), в разделе Login folders вставьте путь к каталогу, где лежат креды, нажмите Check, затем Save: Claude Code — каталог с .credentials.json, обычно %USERPROFILE%.claude. Можно указать и папку, в которой лежат несколько таких каталогов, тогда подхватятся все логины сразу; Kimi Code — ~/.kimi-code; Codex — ~/.codex, где лежит auth.json. Раздел Login folders в настройках: папка с несколькими логинами, одиночный ~/.claude, каталог без кредов и поле для нового пути с кнопкой Check Аккаунты появятся со следующего раунда опроса. Те же пути можно прописать вручную в claude-limits.toml в разделах [[folders]]. А как вы следите за лимитами? Хватает ли вам /usage, или тоже упирались в лимит в самый неудобный момент?