Pitroom

カードをクリックすると、パネルが展開されます。 タスク、ワーカーが実行したステップごとの内容（読み取ったファイル、検索、コマンド、編集とその時刻。失敗したものには印が付きます）、結果、変更したファイルと差分、詳細（モデル、トークン数、コスト、フォールバック、参照チェック）が表示されます。

監査結果とスキップされたワーカーもカードに表示されます。 別のワーカーが再確認した調査結果（監査）には、監査済み · 同意 / 一部同意 / 不同意 のバッジが付き、不同意の場合は異議のある主張が表示されます。クォータ切れで除外されたワーカーは、詳細の下に一覧表示されます（「スキップ … 14:05 までクールダウン中」。pitroom cooldown を参照）。

履歴では、Pitroom がこれまでに実行したすべての内容（タスク、回答、ステップの全文）を検索でき、状態、モデル、期間で絞り込めます。各実行はライブと同じカードで開きます。統計には、ワーカーとモデル別、日別の実行回数、成功率、時間、トークン数、節約額が表示されます。

停止と破棄。 実行中のカードには停止ボタンがあり、まだ適用されていない完了済みの --isolate カードには破棄ボタンがあります（pitroom stop と pitroom discard と同じ動作です。パッチファイルは残ります）。クルーのカードには、すべての実行を一度に操作する同じボタン（すべて停止、すべて破棄）があります。また、一部の実行が失敗、タイムアウト、または停止した場合、コマンドを再試行を押すと、同じクルーで再実行する pitroom run … --bg コマンドが表示されます。端末にコピーするか、エージェントに渡せます（Windows の PowerShell 用、その他の環境では POSIX シェル用に引用符が付けられます）。各操作の前に、もう一度確認を求めます。このページから行える操作はほかにありません。実行を開始することも、パッチを適用することもありません。POST リクエストには、ページの配信時に使われたシークレット（ダッシュボードを起動するたびに変わります）と、そのページ自身のオリジンが必要です。そのため、別のサイトのウェブページからボタンを押すことはできません。

ダッシュボードは React アプリで、dist/ui に一度ビルドされ、2つの静的ファイルとして配信されます。そのため、CLI に実行時依存関係はありません。システムのライトテーマまたはダークテーマに従います（ボタンで切り替えられます）。

ワーカーはコードとドキュメントを550万トークン読み取り（96ステップ、ツール呼び出し179回）、エージェントには7,684トークン（回答1つあたり約960トークン）を渡しました。8回の実行を合わせるとワーカー時間は470秒ですが、一度に4つ（当時の上限。現在のデフォルトは20）実行したため、壁時計時間では156秒で完了しました。これは順番に実行する場合の約3倍の速さです。比較しているのは同じワーカー同士であり、エージェントが単独で読んだ場合との比較ではありません。後者は測定していません。pitroom savings では、Claude Sonnetの定価に基づき、これら8つで3.86ドル節約できたと推定しています。

回答は正しかったのでしょうか？ リポジトリを照合して手作業で確認したところ、8つの回答全体で重要な主張46件（引用された行とその内容）はすべて正しく、2つの網羅性チェックも正しい結果でした（ウィンドウチャネルはinvokeがちょうど6つ、eventが3つで、config_sync_rpc.rs にテストはありません）。i18nの回答は、そのパッケージをインポートするソースファイル12個を挙げていますが、同じくインポートしているテストとフィクスチャのファイル11個は含めていません。ただし、質問ではそれらについて尋ねていませんでした。Pitroom独自のチェッカーが検証済みとして示す参照数は、これより少なくなっています。¹ この2つの回答は、パスを解決できないファイル名だけの参照（transcripts.rs:651）を記載しているため、該当行が正しくても未検証として数えられます。 監査では、手作業による確認より多くの問題が見つかりました。 8つの回答はそれぞれ、後から別の無料ワーカー（space-bunny 上の pitroom audit）によって再確認され、3件は合意、5件は一部正しいと判定されました。食い違いは、引用した行についてではなく、不完全だったり、わずかにずれていたりする回答に関するものです。項目が漏れているリスト（セッション状態：書き込み先がほかにもある、i18n：深いインポート形式で使う別の利用者がいる、RPC テスト：14件のテストが抜けている）、誤った件数、そして宣言から数行ずれた行を引用している例がいくつかありました。1件は手作業でも確認され、監査の判定が正しかったことがわかりました。RPC の mod tests ブロックには59件のテストがあるのに、回答では約40件とされていました。ほかの回答は手作業では確認されておらず、監査役も間違えることがある無料モデルです。そのため、ワーカーのリストや件数は、重要な場合にエージェントが確認するための良い初期回答として扱ってください。これが --audit の目的です。

隔離されたコピーでの変更： 「resolveUpdateMode の上に1行コメントを追加する」は、16秒、4ステップ（142,491トークン）で完了しました。パッチは1つのファイルに1行だけで、コメントはコードに合致しており、適用するまでは作業ツリーに影響しません。

3つの大規模リポジトリにおける無料モデルと gpt-6-sol の比較。 固定したコミットを使い、React（7,252ファイル）、Django（7,091ファイル）、Kubernetes（31,353ファイル）で同種の作業を行いました。各リポジトリにつき3問、合計9問の範囲を限定した質問です。関数を定義するファイルと行、単語を含むファイル数、その単語を含むファイルを尋ねました。各回答は意見ではなく、git grep と照合して評価します。正確な path:line（ファイルは正しいが行が違う場合は半点）、正確な件数、そしてリストについては見落としたファイルと誤って追加したファイルの両方を減点する F1 スコアを使います。各ワーカーは、読み取り専用で、フォールバックなしに9問へ1回ずつ回答しました。そのため、対応できないモデルは別のモデルに差し替えられず、失敗となります。

4つの無料モデルが、これらの質問で gpt-6-sol と同等の結果を出しました。すべてのモデルが定義箇所をすべて見つけており、間違いは件数を尋ねる質問（誤った数）と、2つのモデルでのリスト問題に限られています。後者のうち1つは、django/ 配下にない docs/ ファイルを追加していました。gpt-6-sol は最速の無料モデルと同じくらい速く、ここでは effort を下げても精度は落ちませんでした。nemotron-3.5-lightning-free は、リスト問題の1問で無関係な文章を出力し、別の1問では10分の制限時間に達しました。スコアリング用ハーネスとすべての生の回答は、benchmarks/multi-repo にあります。

表には実行されたワーカーのみを記載しています。まったく回答できなかったモデル（プロバイダーエラー、または OpenRouter の無料枠に共通する1日のクォータ制限）は省略しています。また、プロバイダーエラーで終了した gpt-oss-20b の2回の実行も省いています。タイムアウトは記載しています。

無害な変更をそのままにできるでしょうか？ さらに16個のパッケージは、同じ「tidy」というメッセージで1行または2行の比較式が変更されており、一見すると同じですが、コードの動作は変わりません。比較の左右を入れ替え、演算子を反転した変更です（i < nがn > iになるなど）。同じ式になる場合に限っています。これらに対するCriticalまたはImportantの指摘は誤警報です。

ほぼすべてのモデルが、ほぼすべてのバグを見つけました。そのため、バグを見つけられるかどうかではモデル間の差はほとんど分かりません。差が出るのは、無害な変更をそのままにできるかどうかです。big-pickleは誤警報を一度も出しませんでした。nemotron-3-ultraとmimo-v2.6-flashは、それぞれの言葉で変更が何も変えないと説明しながらも、Importantとして指摘しました（「Yoda条件であり、ファイルのほかの部分と一貫していない」）。レビューのテンプレートでは、スタイルに関する指摘はMinorに分類されます。Importantの指摘に基づいて動作するエージェントなら、無害なコミットを取り消していたでしょう。muse-sparkは正しいバグを説明しましたが、引用した行番号が誤っていることがよくありました（正確な行の割合は62%）。ダッシュが付いているモデルは、無害なパッケージを追加した時点ですでに利用できないか、クォータを使い切っていました。Codex gpt-6-solは9件のレビュー後にプランの利用上限に達し、ほかのモデルも省略されたレビューが無料枠の上限に達していたため、未検出として数えていません。各変更はわずか2～5行で、簡単なものです。また、無害な編集はすべて同じ種類（比較式の反転）です。さらに、React、Django、Kubernetesがモデルの学習データに含まれている可能性もあります。ハーネス、編集を無害に保つルール（とそのテスト）、およびすべての生のレビューは、benchmarks/review-bugsにあります。

# update
claude plugin update pitroom@pitroom
codex plugin marketplace upgrade pitroom
npm i -g pitroom@latest

# uninstall
claude plugin uninstall pitroom@pitroom
codex plugin remove pitroom@pitroom
pitroom uninstall && npm rm -g pitroom

レビュー用パッケージには、レビュー対象の差分と前後10行のコンテキストが含まれます。レビュアーの CLI は、その内容を作業者のモデルプロバイダーに送信します。Pitroom は内容をフィルタリングしません。レビュー対象の範囲にコミットされたシークレットも、そのまま送信されます。

階層を使って、計画のタスクを作業者に割り当てます。"tiers": {"cheap": "opencode", "standard": "codex", "capable": "claude"}。pitroom plan status PLAN は、実行記録から計画の進捗状況を再構築します（コンテキストの圧縮後も維持されます）。また、pitroom plan note を使うと、完了内容や判断をリポジトリの外に保存できます。

• コスト： デフォルトでは無効です。監査は監査担当者による読み取り実行なので、ワーカー自身が使うトークン数に率を掛けた程度のコストがかかります。audit ティアが使われ、設定されていない場合は cheap ティアが使われます。つまり、cheap ティアが無料モデルなら無料です。監査によって実行が遅れたり、失敗したりすることはありません。
• 監査担当者そのものではありません： 監査担当者が、回答を生成したワーカーやモデルと同じになることはありません。別のワーカーが設定されていない場合、監査は行われません（pitroom doctor にその旨が表示されます）。監査対象は読み取り実行のみです。変更には pitroom review を使います。
• 表示場所： 回答のカードと pitroom show に、判定と異議のある主張が表示されます。Stats タブには、監査された回答のうち確認済みとなった数がワーカーごとに表示されます。監査は実行回数に含まれず、何も保存しません。
• 保証ではなく、サンプルです。 監査担当者もモデルであり、同じ盲点を持つことがあります。また、数回の監査だけではワーカーについてほとんどわかりません。DISAGREE は確認するきっかけとして、AGREE は判断材料のひとつとして扱ってください。

{"event":"started","run":"20260930-102812-a65d","mode":"read","task":"Where does Pitroom enforce the maxParallel queue, and how d…"}
{"event":"progress","run":"20260930-102812-a65d","steps":3,"tools":4,"last":"grep SIGINT|SIGTERM|stop.*queued|stopped.*queued"}
{"event":"done","run":"20260930-102812-a563","time":"21s","worker":"opencode (default model)","summary":"The shim resolves `alias.<sub>` via `real git config --get` in a loop …","refs":"5/5"}
{"event":"all-done","runs":4,"ok":4,"failed":0}

$ pitroom status -g v04-demo
RUN                   STATE  MODE  TIME  STEPS  WORKER                    NOW / RESULT
20260930-102812-0c0d  done   read  30s   5      opencode (default model)  Parser `src/backends/opencode/events.ts` reads …
20260930-102812-7642  done   read  27s   5      opencode (default model)  `pitroom apply -g NAME` applies finished isolat…
20260930-102812-a563  done   read  21s   2      opencode (default model)  The shim resolves `alias.<sub>` via `real git c…
20260930-102812-a65d  done   read  39s   7      opencode (default model)  maxParallel is enforced by file-based slots (`s…

pitroom run [-r|-w|-i] [-W WORKER] [-m MODEL] [-d DIR] [-f FILE]… [-t 30m] [--verify CMD] [--link a,b] [--bg] "task"
pitroom run --continue <run|last> "follow-up"
pitroom crew [-i] [-g NAME] "task 1" "task 2" …   (or --task-file with --- separators)
pitroom run -i --plan PLAN --step N [--tier T] ["notes"]
pitroom review [run | --range A..B [--plan PLAN]] [--tier T | -W T] [--bg]
pitroom audit RUN [-W worker]
pitroom eval QUESTIONS.json [-W worker]… [--json]   your questions with known answers, scored per worker
pitroom mcp [-d DIR] [--http [--port N]]   # serve Pitroom as MCP tools on stdio, or over HTTP on 127.0.0.1 (bearer token)
pitroom cooldown [--clear]
pitroom plan status PLAN [--json] · pitroom plan note PLAN "Task N: …"
pitroom status|wait|watch [run… | -g NAME]        wait: --any --brief --timeout · watch: --json|--brief --interval
pitroom dash [--detach] [--port N] [--open] [--stop]   a live page of the runs on 127.0.0.1
pitroom history [TEXT] [--model M] [--state S] [--since 30d] [--limit N] [--json]   finished runs, searchable
pitroom history stats [--since 30d] · pitroom history import   per worker and model · take in older runs
pitroom show [run]                                --patch --events --full --json
pitroom apply [run | -g NAME] · pitroom discard|revert [run] · pitroom stop [run | -g NAME]
pitroom ls [--running] [-g NAME] · pitroom clean [--days 14] [--yes]
pitroom savings [--since 7d|30d|all] [--models] [--card file.svg] [--badge]
pitroom models [worker] [--all] [--json]      models, effort levels, your costs, your usage
pitroom statusline [--then CMD] · pitroom hook-card
pitroom doctor [--probe] · pitroom config · pitroom init [--model ID] [--fallback A,B] [--yes] [--force] · pitroom install [--copy] [--force] [--mcp [--client A,B] [--no-skills] [--dry-run]] · pitroom uninstall

終了コード：0 成功 · 1 ワーカー失敗 · 2 使用方法 · 3 拒否／セットアップ · 4 タイムアウト · 5 読み取り専用違反 · 6 検証失敗 · 75 実行中

完了したすべての実行は、SQLiteデータベースにも記録されます（Pitroomの状態ディレクトリ内の history.db。Node組み込みの node:sqlite を使用し、インストールは不要です）。タスク、ワーカーとモデル、時刻、トークン、節約量、ワーカーが行った手順、回答、差分が保存され、検索できます。

pitroom history "login bug"            # full-text search over the task, the answer and the steps
pitroom history --state problem --since 7d
pitroom history stats --since 30d      # runs, success rate, average time and tokens per worker and model

実行中は、未加工のイベントストリームが通常のファイルとして保存されます（クラッシュ後も残る、最もシンプルな方法です）。終了すると、ストリームは圧縮され、標準エラーのログは成功しなかった実行に限って保持されます。pitroom clean は古い実行ディレクトリを削除しますが、履歴は保持されるため、pitroom show <run> で引き続きレポート、手順、パッチを表示できます。履歴機能ができる前の実行は、pitroom history import で取り込まれます（最初の pitroom history と pitroom dash の実行時にも取り込まれます）。ファイルが引き続き情報源となるため、データベースを削除しても、ディスク上に残っている実行については history import で再構築できます。

2 つの設定により、エージェントが言及するかどうかにかかわらず、すべての委任を確認できます。ステータスラインには実行中のワーカーと今週の節約額が表示されます（--then を使うと、独自のステータスラインが先に表示されます）。エージェントが実行する各 pitroom コマンドの後には、フェーズごと（開始、結果を伴う完了、適用）にカードが表示されます。プラグインはカードフックを登録します。pitroom install を使う場合は、両方を ~/.claude/settings.json に追加します。

{
  "statusLine": { "type": "command", "command": "pitroom statusline --then 'your-own-statusline'" },
  "hooks": {
    "PostToolUse": [{ "matcher": "Bash", "hooks": [{ "type": "command", "command": "pitroom hook-card", "timeout": 10 }] }]
  }
}

Claude Code と Codex のアプリでは、フックメッセージもステータスラインも表示されません。これらのアプリでは、セットアップ不要で使える方法が 2 つあります。

• pitroom dash --detach を実行すると、3 つのタブを備えたライブダッシュボードのアドレスが表示されます。ライブ（実行中および最近の実行をアニメーション付きカードで表示します。カードをクリックすると、タスク、ワーカーの作業手順、結果、差分、詳細を確認できます）、履歴（Pitroom がこれまでに実行したすべての内容を検索、フィルタリングできます。各実行は同じカードとして開きます）、統計（ワーカーおよびモデルごとの成功率、時間、トークン、節約額を表示します）。読み取り専用で、127.0.0.1 のみで待ち受け、1 時間リクエストがないと自動的に停止します（pitroom dash --stop を実行すると、より早く停止できます）。ブラウザーまたはアプリ内のブラウザーペインで開きます。スキルは、エージェントがバックグラウンドでワーカーを実行するときにダッシュボードを起動し、アドレスを知らせるよう指示します。
• pitroom watch -g NAME --brief を実行すると、ワーカーの開始時にカードの行が 1 行、終了時にもう 1 行表示されます。Claude Code では、エージェントが Monitor ツールを通じて実行し、行がアプリに表示されます。Codex では、コマンドの出力ブロックが処理に合わせて更新されます。

すべてのワーカーで次の問題に対処します。opencode run は開いた stdin パイプ上で永久にブロックします。ask 権限によりヘッドレス実行が停止します。デフォルトの出力には ANSI とバナーが含まれます。また、OpenCode v2 では、通常の run が共有バックグラウンドサービスに接続するため、実行ごとの権限と git ガードが適用されません。Pitroom は stdin を閉じ、許可／拒否のみのプロファイルを使用し、--format json を解析し、常にプライベートな --standalone サーバーを実行します。

pitroom models では、各ワーカーが提供する内容（Codex は独自のモデルキャッシュから、Claude Code はエイリアスから、OpenCode は opencode models から、Gemini CLI は組み込みの名前から）、各モデルで指定できる推論レベル、ユーザーが設定したコスト、実際の実行で使われた内容が表示されます。

worker  model        effort (* default)                 cost  runs  avg tokens  $/run   in use
codex   gpt-6.1-sol  low*/medium/high/xhigh/max/ultra   2     20    174k        -       tier standard
codex   gpt-6-sol    low/medium*/high/xhigh/max/ultra   1     1     24k         -       -
claude  haiku        low/medium/high/xhigh/max          ?     -     -           -       -

Pitroom はベンダーの価格情報を独自に持たず、priceFeed を有効にしない限り（設定の説明を参照）、価格情報を取得しません。そのため、コストはユーザーが入力した値です。設定には任意の単位で "costs": {"codex:gpt-6-sol": 1, "codex:gpt-6.1-sol": 2} と記述します（値は比較にのみ使われます。Codex と Gemini の利用明細に記録されるドル価格は workerPrices に設定します。設定の説明を参照）。pitroom doctor は使用中のモデルのコストを表示し、同じワーカーのより安価なモデルを設定している場合はその旨を知らせます。推論レベルだけを指定したターゲット（codex:#low）では、models のモデルが使われます。Codex または Claude Code のワーカーでモデルを固定していない場合は警告が表示されます。ベンダー独自のデフォルトモデルが使われますが、それは変更される可能性があり、コストが高くなる場合もあるためです。--effort LEVEL は1回の実行に推論レベルを設定します。エージェントは pitroom models からモデルとレベルを選びます（条件に合う最も安価なもの：検索には low、通常の変更には medium、レビューには high）。

フォールバックはバックエンドをまたいで利用できます（例："fallback": ["codex:#low", "opencode"]）。レート制限中、ログアウト中、またはモデルが見つからないワーカーは、タスクを次のワーカーに引き継ぎます。ワーカーの起動後に制限に達した場合（Codex または Claude のプランの利用上限、Antigravity のクォータなど）も、実行を失敗させるのではなく、次のワーカーがタスクを引き継ぎます。編集（-i、-w）は同じツリーで続行され、次のワーカーには、前のワーカーがすでに変更したファイルと、最初からやり直すのではなく作業を完了するよう伝えられます。読み取りの場合は最初からやり直します。両方のワーカーが使用したコストが実行コストになります。監査では別の監査ワーカー（監査層と低コスト層、フォールバック、ワーカー）が使われ、監査対象のワーカーは使われません。フォローアップ（--continue）は常にセッションを所有するワーカーで行われます。アダプターの作成方法については、[docs/backends.md](docs/backends.md) を参照してください。「rate limited」（日次クォータの超過、プロバイダーの過負荷など）と報告したモデルは、メッセージで指定された時間（「retry in 4h」、「try again at 8:56 PM」、「resets 7:40pm (Europe/Istanbul)」）または推定時間（過負荷なら20分、利用枠の超過なら1時間、日次クォータなら4時間）の間、記録されます。フォールバックが残っている場合、次の実行ではそのモデルがスキップされるため、毎回失敗するまで待つ必要はありません。pitroom cooldown ではスキップ中のモデルとスキップが解除される時刻が表示されます。--clear を指定すると再試行し、doctor` にも同じ情報が表示されます。

{
  "worker": "opencode",
  "fallback": ["opencode:opencode/space-bunny-free", "codex"],
  "models": { "codex": "gpt-6.1-sol", "claude": "claude-sonnet-5-5" },
  "costs": { "codex:gpt-6-sol": 1, "codex:gpt-6.1-sol": 2 },
  "tiers": { "cheap": "opencode", "standard": "codex", "capable": "claude", "review": "opencode:opencode/space-bunny-free" },
  "timeout": "20m",
  "primary": "opus",
  "link": ["node_modules"],
  "maxParallel": 20,
  "audit": 0.1
}

• worker と fallback：担当者を指定しなかった場合にタスクを実行する人と、失敗した場合に引き継ぐ人です。models：ターゲットで指定されていない場合に各ワーカーが使用するモデルです。
• tiers：cheap、standard、capable は、プランタスクと --tier で使用するワーカーを指定します。任意の review ティアでは、実行をレビューするワーカーを指定します（デフォルトでは実装者とは別のワーカーで、まず standard が使われます）。
• audit：完了した読み取り実行をバックグラウンドで再確認する確率（0〜1、デフォルトは 0＝オフ）です。監査を参照してください。監査を行うワーカーは audit ティアで指定します（指定がなければ cheap）。
• costs：worker:model ごとの相対コストで、互いの比較にのみ使用されます。maxParallel：同時に実行するワーカー数（デフォルトは 20、最大 30）。
• workerPrices：コストを報告しない CLI（Codex、Gemini）で使用する、ワーカーモデルの 100 万トークンあたりの USD 価格です。"workerPrices": {"codex:gpt-6.1-sol": "1.25,10,0.125"} は「入力、出力［、キャッシュ済み入力］」を表し、backend:model（実行されたモデル。なければ指定したモデル）または backend のみをキーとして指定します。指定がない場合、レシートには worker cost n/a と表示され、節約額の計算では実行コストがゼロとして扱われるため、節約額が実際より大きく見積もられます（pitroom doctor が警告します）。指定すると、トークン数に基づいてコストが推定され、~$0.016 (estimated from your workerPrices) のように表示されて、台帳、履歴、ダッシュボードに記録され、節約額から差し引かれます。Pitroom はベンダー価格を把握しておらず、取得もしないため、この価格はご自身で設定してください。
• priceFeed：価格カタログを最新の状態に保ちます（デフォルトは false、PITROOM_PRICE_FEED=1）。このカタログは、OpenCode も参照する公開の models.dev リスト（約 8,000 モデルの 100 万トークンあたりの USD 価格）です。1 日に最大 1 回（priceFeedHours のデフォルトは 24）、実行後にバックグラウンドプロセスで取得され、実行待機中には取得されません。Pitroom はこのファイルだけに対して通常の GET を送信し（ミラーを使う場合は priceFeedUrl / PITROOM_PRICE_FEED_URL、間隔は priceFeedHours / PITROOM_PRICE_FEED_HOURS で指定）、状態ディレクトリにサイズを抑えたコピー（約 400 KB）を保存します。更新に失敗した場合は古いコピーを保持し、1 時間は再試行しません。これはあくまでフォールバックです。まず workerPrices が優先され、レシートには使用された価格の情報（estimated from models.dev prices）が表示されます。これを有効にすると、節約額の比較対象として "primary": "<model id>" にカタログ内の任意のモデルを指定できます（"primary": "claude-opus-5-5"）。無効の場合は 4 つのプリセットのみ使用できます。pitroom prices ではフィード、カタログ、primary の価格、および使用中の各ワーカーに適用される価格を確認できます（pitroom prices codex:gpt-6.1-sol では指定したモデルの価格を表示します）。pitroom prices --refresh は即時に取得します。送信される情報については、PRIVACY.mdを参照してください。表示される価格は API の標準価格です。サブスクリプションを利用するワーカー（ChatGPT アカウントを使う Codex など）はこの料金を支払わないため、そのようなワーカーでは、同じトークン数を API で使用した場合の料金として見積もられます。
• notify：バックグラウンドに移行した実行（--bg、クルー、MCP 呼び出し）が終了したときにデスクトップ通知を表示します。長時間のジョブを見守る必要がなくなります（デフォルトは false、PITROOM_NOTIFY=1）。正常に終了し、所要時間が notifyAfter 秒未満の実行（デフォルトは 15、PITROOM_NOTIFY_AFTER）と監査については通知されません（失敗は常に通知されます）。クルーの場合は、最後の実行が終了した時点で、全体の結果をまとめて一度だけ通知します。ワーカープロセスが強制終了された場合は、通知を送れません。組み込みの通知機能は macOS では osascript、Linux では notify-send を使用します（Windows はまだ対応していません）。notifyCommand では、代わりにシェル内で独自のコマンドを実行できます。通知文は PITROOM_NOTIFY_TITLE と PITROOM_NOTIFY_BODY に格納されます（ほかに PITROOM_NOTIFY_RUN、PITROOM_NOTIFY_STATE もあります）。例："notifyCommand": "curl -s -d \"$PITROOM_NOTIFY_BODY\" ntfy.sh/my-topic"。
• mcpDash：MCP クライアントが開始した実行が数秒後も続いている場合、ダッシュボードも起動してそのアドレスを返すかどうかを指定します（デフォルトは true。PITROOM_MCP_DASH=0 または "mcpDash": false で無効になります）。MCP サーバーを参照してください。
• auditFix と auditFocus：見解が食い違った回答をワーカーに戻して 1 回修正させるかどうか、および監査対象の抽出を一覧・件数に関する質問と意見が食い違ったワーカーに重点化するかどうかを指定します（どちらもデフォルトは false、PITROOM_AUDIT_FIX、PITROOM_AUDIT_FOCUS）。監査を参照してください。
• budgetDaily：ワーカーが 1 日に使用できる金額（USD）です。CLI の報告値、または workerPrices と価格カタログに基づく推定値が使われます。監査と修正も含まれます。予算の 80％を超えると実行時に警告が表示されます。予算を使い切ると、コストのかからないワーカー（価格が 0 のワーカー、または直近の実行がすべて正確に 0 だったワーカー）のみ実行されます。実行チェーンに該当するワーカーがいない場合は実行が拒否され（終了コード 3）、監査と修正も開始されません。実行中のタスクは、その時点までに使用した金額が計上されます。同時に開始された実行は、最初のステップが完了した時点から計上されるため、クルーの実行によって 1 日の予算を少し超えることがあります。0 を指定すると、無料のワーカーのみが許可されます。デフォルトでは予算の上限はありません（PITROOM_BUDGET_DAILY）。
• rankWorkers：同じ種類の作業（質問、変更、レビュー）について、過去 30 日間の実績に基づき、ワーカーとフォールバックの順序を並べ替えます（モデルは質問には適切に答えても、変更を完了できない場合があります）。実行が正常に終了した割合（レート制限は除外）に、確認済みの作業が問題なく完了した割合を掛け合わせます。確認は 3 件以上必要です（回答の場合は監査、変更の場合は仕様を満たし修正が不要と判断されたレビュー）。該当する種類の実行が 5 回以上あるワーカーのみが並べ替えの対象になります。並べ替えは、そのようなワーカー同士の順位を 10％刻みで変更します。ユーザーが指定したワーカー（-W、-m、ティア）は並べ替えられません。最初のワーカーが変更された場合、実行時にその旨が表示されます（デフォルトは false、PITROOM_RANK_WORKERS=1）。
• autoFallback：独自の fallback が設定されていない場合、設定ですでに指定されているほかのワーカー（tiers、models、worker に含まれるもの）から、ここにインストールされているものをフォールバックとして選びます。costs に基づく安い順（コストの指定がないワーカーはその後に指定順）で、最大 4 つまで選びます。同じワーカーの別の努力レベルは対象外です（デフォルトは false、PITROOM_AUTO_FALLBACK=1）。Pitroom は指定されていないモデルを選ぶことはなく、ユーザー自身が選んだものだけを再利用します。fallback リストが設定されている場合はそちらが優先され、--no-fallback も有効です。フォールバックチェーンがこの機能によって決まった場合は、pitroom doctor に表示されます。
• countRateLimits：レート制限またはクォータ超過で失敗した実行を、pitroom history stats とダッシュボードの「Stats」に含めるかどうかを指定します（デフォルトは false。ワーカーの作業内容を反映しないため、実行数、成功率、時間、トークン数から除外し、レート制限として別に表示します。true にすると、失敗として集計されます）。