tibo-reset-codex

Tibo Reset — ChatGPT/Codex 额度重置速查

这是什么

「Tibo reset」= OpenAI Codex/ChatGPT Work 负责人 Thibault Sottiaux（X: @thsottiaux） 在 X 上宣布的广域额度重置传统。社区昵称「Lord Tibo」，有第三方追踪站 Tibo Radar （codex-reset.com）和「祈祷重置」亚文化。Tibo 官宣没有固定排期；但平台也会在限额 配置切换时不发 reset 帖而直接重置账户。所以「没有 Tibo 帖」只证明没有官宣，不能证明 没有重置。

先分清用户问的是哪种重置：

类型	谁触发	在哪看	性质
官宣广域 RESET	Tibo / OpenAI	官方 X 原帖；追踪站只作公告索引	无固定排期，常用于里程碑或故障补偿
静默平台重置	OpenAI 后端或限额配置发布	产品 usage 状态 + 同时段多账户第一手实测 + 排除各自正常周期；官方限额变更只作上下文	可以没有 reset 帖；未获官方范围声明时只能称「大范围观测到」，不能称「全员」
BANKED reset	Tibo 推文，或官方现场活动	官宣：官方原帖——也可能没有 X 原帖（2026-09-29 DevDay 现场按按钮发放，最先由第三方站运营者记录，随后经用户名下多账号读数证实；此时没有官宣，到账按用户对自己账号的直接观测或同一 account_ref 的前后读数判，都没有则未核实）；到账：逐账号对照产品内备用重置库存前后读数	一次性「存着随你用」的额度包，到账后不自动消耗，由用户在 usage 页手动兑现；官宣 ≠ 人人到账（有过分批延迟）。触发形态含里程碑庆祝与故障补偿——§1 所述 rollout 延迟补偿属后者（按无访问天数累积，可一人多笔；2026-09 GPT-6 Astra 补偿即此形态）
账户级周重置	系统按该账户当前用量窗口	ChatGPT 产品内「Next reset: …」	每人时间不同；使用 Full reset 也会改变周重置日期，不从订阅开通日推算

先判宿主：应用托管的只读研究任务

仅当上层应用明确给出研究问题、上轮完整报告、未决状态、有效纠正、信息截点、 逐条授权的私有来源和结构化输出合同，并明确本轮只做读取与分析、持久交接归应用时走此分支。 即使宿主为获授权的私有来源开放网络和临时工作区写入，也不改变本分支的本地台账边界。 此分支优先于下方「入口分流」 与「监测轮」的本地台账步骤：不用 forecast_log.py summary / handoff 读取用户 目录下可能属于另一研究范围的台账，也不执行 finding / record / review 写入； 不执行裸调用默认的 query_usage、scan_rollouts 或账号登录/恢复路径，除非宿主把 对应账号/usage 来源明确列入本轮授权清单。未授权或无法读取时，到账和账号状态是 unknown，不由公告推断成已到账。

以宿主提供的 state.entries 和上轮报告接替监测轮步骤 1，以最终结构化产物接替 步骤 5：把未决承诺、候选来源、类型、窗口、实际覆盖和下一次复查条件写回 state.entries，在报告中保留原帖、区分新证据与旧事实，不能把缺失的本地台账说成 「过去没有线索」。继续执行中间步骤的 Tibo 信源发现、上下文补证，以及 global / banked / both / 未明的不同用量决策；公开来源清单仍只是起点。 只有宿主明确列出的私人会话才可通过 read-wechat-messages 读取，并先完成该 Skill 要求的账号预检和图片/语音覆盖；未列出、预检失败或只读环境无法处理时标 uncovered。其它任何私有来源（含本机账号状态）同样以宿主逐条授权为前提。 宿主产物中的变化摘要只是待核研究，不冒充已送达、已读或正式账户操作。

需要登录浏览器补读公开 X 来源时，先按当前 ego-browser 指南核对共享资源占用。 在 macOS 受限 Codex 宿主中，优先由工具直接执行 ego-browser nodejs -e；长脚本按 该指南写成本轮新的完整 .mjs，再用 -e 导入绝对 file URL。实测直接调用可读， stdin/heredoc 及 Python/Node 子进程调用却可能报 Failed to start ego lite； 不能把顶层 -e 的成功移植成子进程封装已可用。连接成功后仍须实际读取目标正文； 失败保留覆盖缺口，不自动扩大权限、切号或把空壳页面算作已读。这里是执行者采用的 调用约定，不是应用已机械拦截其它调用形式的保证。

不满足本节全部触发条件的独立调用，按下方普通分流和本地台账流程执行。

エントリーポイントの振り分け

• 呼び出しのたびに、まずローカル予測フィードバックを読み、既存の記録を確認します。関連イベントの証拠を取得したら、未決の予測にフィードバックを記録します。読み取り専用の記録が空の場合はファイルを作成しません。新しい予測を提示する場合は、期間、根拠、今回のフィードバックを保存します。外部データを実際に取得する呼び出しでは、先に findings 記録を作成し、record/review は evidence_refs で関連付けます（スキーマとルールは同ドキュメントの「findings：生データ層」を参照）。

• ユーザーがすでに結果を知っていて、「なぜ見落としたのか／どの段階でカバーできていなかったのか／次回どう防ぐか」と尋ねている場合 → 過去の証拠チェーンの診断に切り替えます。当時入手可能だったインデックス、元投稿の全文、reply / quote / parent のカバー状況、解析結果、findings を段階ごとに確認します。その回の生の記録がない場合は、「取得／解析／抽出／記録のどの段階で失われたか = unknown」のままにします。既知の結果を再検索して診断の代わりにしてはいけません。また、再確認不要とユーザーが明言した banked reset も再確認しません。ユーザーが現在のアカウント状態も明確に求めている場合、または現在の読み取り結果によって今回の診断が変わる場合に限り、アカウント SOP も並行して実行します。この振り分けは、明示的に求められたリアルタイム検索を妨げるものではありません。

• ユーザーが現在の公式発表について、なぜまだ反映されていないのか、なぜ実行シグナルがまだないのかと尋ねている場合 → 監視ラウンド（情報から実行可能なシグナルまで）に従って、反映状況と理由を調べます。これは前回の見落としの原因特定ではないため、過去の findings を再生するだけでは不十分です。

• 具体的な質問を伴わない呼び出し（現在の状況だけを知りたい場合）→ 以下を組み合わせて実行します。台帳の確認 → 発表経路（Radar インデックス + Tibo の独立したメイン投稿タイムライン + 範囲を限定した reply の検出。各経路は §1 に従う）+ 障害経路（§1）→ ローカルでの状態取得（§2 のスクリプト）→ 監視ラウンドの手がかりに基づく判断と台帳への記録。 出力要件に従い、まず現在のリセット状態について結論を示し、次に予測経路に沿って今後の時期を判断します。裏付けられる日付の範囲がない場合は、待つ価値があるかどうかを判断し、形式を埋めるためだけに record を呼び出して期間を作り出してはいけません。発表経路、障害経路、ローカルスキャンによる実際の取得は、その都度まず findings 記録を作成し、記録時に evidence_refs で関連付けます（予測フィードバックの findings 節を参照）。§2 の後には必ずリアルタイムの banked 検索をもう一度実行します（scripts/query_usage.py。読み方とフィールド一覧はアカウント SOPを参照）。§2 の rollout スナップショットには構造上、予備のリセットフィールドがないため、実行しないと「現在の状況」で最もよく尋ねられる項目に回答できません。banked の値を1つだけ取得し、出力の account_ref もあわせて findings に記録します（記録ルールは forecast-feedback.md のプライバシー契約、banked カウントの比較可能な範囲はアカウント SOP を参照）。本項の残りの内容は引き続きリセット状態のみを扱います。 ⚠️ scan と banked を && で連結してはいけません：スナップショットがない場合、scan_rollouts は exit 1 で終了するため、&& で連結すると banked 検索がそのままスキップされます。全処理を実行したように見えても、実際には1つの項目が欠けます（2026-09-19 実測）。2つのコマンドは分けて実行するか、連結する場合は scan に || true を付けてください。ループ実行中は、skill 内のコマンドをそのまま実行すると same-cmd-resend-guard にブロックされます（エンドポイントの一時的な不調で一度失敗した後、バイト単位で同じコマンドを再送するとブロックされます）。コマンドの先頭に cd <skill 絶対パス> && を加えて構造を変えると実行できます（2026-09-19 実測）。 定期ループ（例：/loop）が繰り返し実行される際、前回の確認からの間隔が短く（<10 分）、前回に判断を変えるシグナルがなかった場合は、発表経路で新たな公式発表がないことだけを確認し、incidents/banked/ローカルスキャン一式を省略してもかまいません。これはコストを抑えるための選択であり、確認していない項目は引き続き uncovered として示します。間隔が通常どおりの場合、台帳内の手がかりが再確認条件に達した場合、または前回に新しいシグナルがあった場合は、引き続き全処理を実行します。 時間帯に応じた頻度の引き下げ（間隔に応じた条件とは独立しており、両方を組み合わせます）：Tibo の睡眠時間帯（America/Los_Angeles の 01:00–08:00。毎回、当日のタイムゾーンに合わせて北京時間に換算します）は、発表経路からのリクエストを1件だけ実行して新たな公式発表がないことを確認し、incidents/banked/ローカルスキャン一式を省略します。公式発表によるリセットは彼の睡眠時間帯に発生したことがなく（過去のパターンは「Tibo の時刻表記」節を参照）、補填型のリセットは彼の生活リズムに依存しません。頻度を下げる場合でも、新しい項目の全文確認は省略できません：Radar が前回裁定済みのインデックスより新しい項目を正常に返した場合、まず §1 に従って元投稿の全文を読み、その後、頻度を下げるかどうかを判断します。official_window=null だからといって確認を早期に終了してはいけません。頻度を引き上げる例外には、official_window に明確な期間がある場合、本文に将来の約束が記載されている場合、本文中の時刻、種類、対象範囲によって予定が変わる場合、または台帳に未決の約束があり、フォローアップ条件に達した場合が含まれます。いずれかに該当すれば全処理に戻し、その約束に基づく判断変更条件に従って追跡します。いずれにも該当しない場合は、リクエスト1件のみの頻度引き下げを継続します。代償を明確に伝えてください：睡眠時間帯に公式発表を伴わないサイレントリセットが発生した場合、活動時間帯になるまで検出が遅れます。ただし、サイレントリセットも人為的に発生するものであり、過去のパターンから睡眠時間帯には起こらないと判断できるため、許容可能として扱います。（2026-09-18 ユーザーの判断により、通常の頻度引き下げ分岐を維持。） 通常ラウンドとカバー範囲の自己点検：固定の確認経路は、現在把握している情報源の起点であり、完全な情報源一覧ではありません。また、「新しいリセットを見落とさない」保証もありません。各ラウンドでは、以下の手がかりに基づく判断に従って、新たな証拠、未決の問題、フィードバックを処理します。新しいシグナルが連続してない場合でも、次の通常ラウンドで、追跡する価値のある情報源、文脈、反証が現れていないか確認してください。ユーザーが「シグナルを見落としていないか／他の人はどう予測しているか」と尋ねた場合は、情報源の盲点と当時入手可能だった情報を直接確認します。「全処理を実行した」と答えて済ませてはいけません。 额度/余额そのものを尋ねられた場合は、全項目をアカウント SOP で扱います。本項ではリセット状態のみを扱います。

• この Skill が改善するのは、呼び出しのたび、またはホストが設定したループの実行時における読み取り、判断、記録です。それ自体には、バックグラウンドスケジューリング、能動的な通知、ACK の仕組みはありません。これらの実行レイヤーを別途導入して実測していない限り、継続的な検出、配信、既読確認が保証されていると主張してはいけません。

• ユーザーが「複数アカウントはどうなっているか／全部使い切ったか／上限に達したものがあと2つあるか／Full reset はあと何回か」と尋ねた場合 → まずアカウントごとの利用上限確認とウェブログインの復旧を読みます。

• ユーザーが「Tibo は何と言ったか」と尋ねる、または公式発表のみを明確に求める場合 → 発表経路を調べます。

• ユーザーが「次はいつか／明日リセットされるか／待つ価値があるか」と尋ねる場合（直前のラウンドでリセットされた後の質問も含む）→ 発表を確認してから次回のリセット予測を読み、主な判断、根拠、更新時刻を示します。デフォルトでは前後の文脈にあるリセット種別を引き継ぎます。個人の周期について明確に尋ねられた場合は、引き続きアカウント SOP に従い、個人の週次リセット日を全体予測の代わりに用いてはいけません。

• ユーザーが自分の weekly/5h が 100% に戻った、Next reset が変わったと伝える、または usage のスクリーンショットを貼った場合 → まずそのアカウントの直接観測として記録し、その後、個人周期によるものか、アカウント横断のイベントかを調べます。

• ユーザーが「間違いなくまたリセットされた」と明言し、アグリゲーターに記録がない場合 → 直ちにサイレントリセット経路に進みます。同じアグリゲーターを再検索し、結果が空だったことを理由にユーザーの発言を再び否定してはいけません。

• ユーザーが現在の残量または次回の周期リセットのみを尋ねる場合 → 同様にアカウント SOP のリアルタイム検索を実行します。過去の変化を説明する必要がある場合にのみ、§2 の rollout スナップショットを使います。現在の残量を調べるために、まず過去の履歴全体を再構築したり、発表を再確認したりする必要はありません。

• ウェブ上での手動ログインを省略し、日常使用している Chrome にログイン済みの Google アカウントを分離された検索 profile に直接接続したい場合 → scripts/launch-usage-profile.sh <a|b> で分離された Chrome profile を作成／起動し、scripts/import-google-cookies.py --profile <a|b> で .google.com の Cookie を移行します（仕組みとセキュリティ上の根拠はスクリプト自身の docstring を参照。2026-09-15 に検証済み）。

• 分離された Chrome を自動操作して第2アカウントの使用量を調べたい場合 → node scripts/read-usage-profile.cjs を実行します（~/.chrome-profiles/tibo-cdp/ の playwright に依存。デフォルトの profile は a です）。読み取りモードでは、現在ログインしているアカウントの usage を直接解析します。--drive-login を付けると、未ログインの場合に Continue with Google を自動でクリックして Google アカウント選択画面を表示し、すべてのアカウントを一覧表示します。実測上の制約（2026-09-16）：分離された profile には Google セッションの token がないため、アカウント選択画面では各アカウントが Signed out と表示され、パスワードなしの直接ログインはできません。パスワードや確認コードの入力は人手で行う必要があります。初回ログイン後は、読み取りモードを完全自動化できます。実際の手順に関する詳細（プロキシ、どのボタンにどの実入力経路が有効か、ログイン状態の判定方法、OAuth のポーリング）は、account-usage.md の分離 Chrome 自動化節を参照してください。

出力契約：先に結論を示し、その後に境界を説明する

ユーザーの原文（2026-08-26）：「結論を出すのはあなたです。私に結論を出させてはいけません。」

• 最初の段落の最初の文で、現在の証拠が裏付ける唯一かつ最も強い結論を必ず示してください。「A/B/C の可能性があります。もう一度確認してください」のように、分類の責任をユーザーに戻すことは禁止です。
• 不確実性は、結論の属性を絞り込むために使い、結論を取り消すために使ってはいけません。
  • 1 つのアカウントの現在の読み取り値だけが確認できている場合 → 「現在のアカウント残量は X％です。Next reset は … です。リセットが発生したかどうかは未確認です」。
  • 同じ account_ref の前後の読み取り値に使用量の減少とアンカーの変化が見られるものの、直接的なイベントの証拠がない場合 → 「2 つの観測点の間の期間に変化が発生しました。原因は未確認です」。両端のアカウント ID が同じでも、途中で A→B→A と切り替わった可能性は排除できません。「このアカウントはすでにリセットされた」とは書かないでください。
  • 複数アカウントについて、ID と結び付いた読み取り値が通常のタイミングより早く変化し、それぞれの通常周期でもアカウント切り替えでも説明できない場合 → 「未告知の大規模なサイレントリセットが発生しました」。
  • 公式に all/every と明記されている場合 → 「公式が全員のリセットを確認しました」。
• 「リセット済み／アカウント切り替え／全員のリセット」と結論付ける前に、アカウント SOP の機械的な帰属判定基準に従って scripts/reset_attribution.py を実行してください。claim_gate が block の主張は提示してはいけません。帰属が unknown でも、現在の残量、Next reset、banked の現在値を報告することは妨げられません。
• 証拠、競合する説明、確認待ちの項目は、結論の後に記載してください。あるアカウントの Next reset または banked の状態を取得できない場合でも、まず判明している事実について結論を示し、その後、どの属性を確認できないのか説明してください。「確認してご自身で判断してください」で回答を終えることは禁止です。
• アカウントの現在値だけではイベントの帰属を証明できません：現在の残量、Next reset、banked の在庫が示すのは、照会時点の状態だけです。原因が確定していないアカウントの読み取り値を、そのアカウントに公式発表のリセットが適用されたことを示す補助証拠として扱ってはいけません。通常の周期と追加のリセットが相次いで発生する可能性があるため、アカウント SOPに従ってそれぞれ個別に確認し、前のイベントを理由に後のイベントを説明または否定しないでください。
• ユーザーから、実現していない約束、適用の遅れ、またはイベントの時系列について追及された場合は、結論の後に、判断を変える可能性のある時点を時系列順に列挙してください。該当する場合は障害と復旧、公式投稿での約束の時刻と文言、約束後のアカウントの読み取り値、その後の完了または説明を示してください。各時点にはタイムゾーン、一次情報源、実際に証明できる範囲を明記してください。確認できない時点は不明のままとし、告知時刻を適用時刻として扱わないでください。
• その後の確認作業は、この結論を裏付ける、または反証するためだけに行ってください。ユーザーにエージェントの代わりに判断させる選択問題にしてはいけません。
• 将来の時期を問われた場合は、予測に基づく判断を示してください。 明確な予告がある場合は、まず換算後の公式発表ウィンドウを示してください。予告がない場合も、最近の類似イベントと現在の兆候を分析し、予測手順に従って、根拠のある主な予測期間、確信度、判断を変更する条件を示してください。「未告知／固定スケジュールなし／There is no schedule」は告知状況を示すだけで、それだけで回答を終えてはいけません。資料が不足して日付を裏付けられない場合は、待つ価値があるかどうかの判断と不足情報を示し、日付や精密な確率を捏造しないでください。

监测轮：从信息到可行动信号

适用于裸调用、预测询问和宿主重复调用本 Skill 的正常轮；明确只问账户余额、只问已知帖原文 或历史漏报归因时，按入口分流缩小范围。降频轮保留上述取舍，但不能丢掉未决线索；未决线索 到达复查条件时升级为正常轮。每轮按以下顺序执行，停止于证据已足够改变或维持当前行动、 且下一次需要什么新信息已经写清，而不是停止于固定端点返回空值。

1. 接上上轮的问题。 读 forecast_log.py summary，先看 due_for_followup（窗口已过期或 即将关闭、尚无定论的预测——到期跟进项从这里第一眼读，不用翻 rationale；closing_soon 的 阈值定义见 forecast-feedback.md）；若有 withdrawal_conflicts，先核对冲突的撤回与旧版核验； 若有 recent_withdrawn，先排除已撤回的旧窗口；也看 snapshot.status——lagging 表示台账 的 git 快照落后（原因与处置见 forecast-feedback.md 的 findings 节），要在本轮汇报里说明； 再从同一 state-dir 运行 forecast_log.py handoff 读取最新一条 invocation=monitor 的完整原始行；findings 子命令的紧凑列表不显示 notes，不能用它代替交接正文。handoff 返回 null 表示尚无监测交接，不能推断此前 没有值得追的线索。 其中的 notes 记录上轮尚未解决的具体问题、候选来源、下一次复查条件和用户反馈。上轮 没有记录就从当前问题与现有预测的 revision_trigger 建立这些项，不把空台账说成已覆盖。 本轮即使只做降频查询，也要在新 finding 的 notes 里结转未决项或写明已由哪条证据关闭， 使它始终能从最新轮次读回；逐字读数仍只放 readings，判断不得伪装成原始数据。 同一 state-dir 再运行 forecast_log.py followup，执行其 event_tasks 与 account_tasks，不要把输出清单当成已经查过。confirmed_unscored 表示事件已经确认、 预测仍不可评分，不为它继续问「重置发生了吗」；account_followup 单独保留已绑定账号的 未到账项。官宣的具体时刻用 announce 保存，字段与状态读 本地预测反馈。
2. 先取增量，再问它改变什么。 以 §1 的 Radar、Tibo 主帖、reply、故障与社区监测为 基线，比较上次已读的 ID/时间和本次实际覆盖；新发现的旧帖也按首次发现时间进入本轮 判读，不能因为发帖时间早于本轮起点就丢弃。阅读完整正文及承重的 parent / quote / 图片 文字；同一原帖的镜像和群截图只算一份事实，但群截图作为新的发现路径应保留。先判断 「这条信息若为真，会改变哪一个关于时间、范围、类型、到账或使用策略的判断」，再决定 是否追下一跳；不能以 reset 等固定关键词或 tracker 标签作语义闸门。
3. 沿问题扩来源，而非无限抓取。 已知来源空白、未来承诺尚无独立兑现证据、用户追问原因、 上下文指向别处，或候选会改变行动时，先标明公告、服务恢复、账户到账、影响范围与执行原因 哪些已有证据，再列能改变判断的竞争解释。承诺没有截止时间时，本账户暂未变化是待证状态， 不是承诺与产品相矛盾；也不能据此断言后端尚未执行或已在其他账户到账。 从帖子引用、回复对象、官方事故、独立账户观测和用户已授权的社区记录中选最有辨别力的 下一跳。用户已指出「VIP 1群｜一支烟花社区」是本案有效的补充发现源；正常轮若尚无该群 的新鲜覆盖，就用现有 read-wechat-messages 读取其增量，包含纯图片与语音，随后回原帖 核验。相关群会随用户反馈和实际信号增减，不把这个群写成永远完整的来源清单。群消息是 发现与交叉核对渠道，转发次数不是独立证据。每跳写明它要区分的竞争解释；查不到时 保留 unknown 与下一次可执行的复查条件。证据已足以回答用户问的状态或原因， 或追加来源不会改变有界结论时停止扩展；平台内部原因无可读证据时明确保留 unknown。 followup.event_tasks 标为 overdue 时，补查清单里的新鲜账号读数、官方主帖、候选回复链、 有界回复发现和已授权社区增量，分别核对「官方是否改期或完成」「同一账号是否变化」 「其他独立账号是否已有到账」。只看原预告和同一批回复不能完成这轮复查；通道仍不可用时 保存本轮失败与下次可执行条件，不把旧的 unknown 当作本轮已经尝试。具体现有获取路径 仍按 §1 与社区读取 Skill 执行，不为一次失败判通道永久不可用。account_tasks 则只追对应 账号到账，不重开已确认的全局事件；未获授权的社区来源保留 uncovered。
4. 分层输出并保留行动差异。 已核实的事件、未来承诺和行动提示可构成信号；含糊回复、 里程碑或第三方解读先列候选，若会改变当前安排仍及时提示其歧义与补证条件，不升格为 明文承诺。明确区分 global、banked、both、个人周期和类型未明：global 到来前可 评估把原本值得做的工作提前；banked 先关注到账、到期与手动兑现，不因它将发放就建议 提前耗尽现有额度；both 分开跟进两类容量；类型未明时可记录账户基线、准备既有任务， 只在本账户读数与机会成本支持时作可撤销的条件性安排。未发现新信号时只说 「本轮已覆盖范围内无新增可行动信息」，连同 uncovered / unknown 与下一复查条件报告， 不说全域无信号。若本轮有新判断，用原帖、上下文和产品观测说明它比上轮多了什么， 以及是否要通知、等待或改变用量策略；不能把发送回执当用户 ACK。 反向同样成立：官方已明文预告 global 在途时，先等落地再动备用——global 落地即全员回满， 此刻兑现备用等于白扔库存（2026-10-11 实测：4 账号全空 + EOD 官宣在途，官宣后 5h45m 落地、 距 EOD 上限仍提前 ~3h，2 次备用保住未花）。
5. 把下一轮要接的状态落下。 在本轮最后追加一条 invocation=monitor 的交接 finding； query 写当前监测问题，endpoints=[]、readings={}，notes 写本轮 UTC 检查时刻、新线索、已排除解释、 未决问题、候选来源、各来源覆盖、下次触发条件及用户纠偏。重要判断另按预测路径保存或 修订预测，并以 evidence_refs 链接原始读数。没有新信息也更新下一轮应检查的条件；不得以「连续数日 没信号」自行拉长宿主调用间隔。Skill 只能规定被调用时的行为，不能凭一次执行证明未来 定时唤起、消息送达或 ACK 已生效。 完成确认后追加 review，分开记录事件确认与账号读数。只有完成帖时仍用 time_basis=confirmation_only，不得为清空待查队列伪造发生时刻或命中评分；脚本会把已确认 但不可评分的记录移到 confirmed_unscored。官宣时刻是 announce 的单点记录，不加一秒 尾巴凑成预测窗口，也不凭经验添加执行宽限。

查证工作流

1. 公告路径：Radar、Tibo 主帖与 reply

正常轮次必须实际尝试 Radar、Tibo 主帖时间线与下文的有界 reply 发现。 Radar 可能 完全没有索引一条新的独立主帖；主帖时间线也不含 replies，所以前两条都无新仍不能跳过 reply 发现。宿主没有可用的已登录 X 通道时，reply 腿的执行结果是 unknown，不是静默省略。按时段 降频的已批准例外仍按入口分流执行：降频轮只查 Radar 时，把 main_posts 与 replies 都记为 uncovered，不能把结果写成全量无新。

本机已登录且 twitter-cli 可用时，主帖入口使用下面的只读命令（v0.8.5，2026-09-23 实测； 帮助与 JSON 输出均核对过）：

twitter user-posts thsottiaux -n 50 --json 2>/dev/null

CLI 的 WARNING（如 Failed to init ClientTransaction）走 stderr、不影响 JSON；用 2>&1 合流会让 JSON 解析在首字符失败（2026-09-30 实测），所以丢弃 stderr。

返却項目を createdAtISO ／ id と前回の finding のメイン投稿カーソルで比較します。新しいメイン投稿はそれぞれ text 全文を読み、quotedTweet の関係を保持します。2 回の確認の間に投稿数が現在のウィンドウを超え、最古の返却項目が前回のカーソルより新しい場合は、-n を拡大して（最大 200 件）補完します。切り詰められたウィンドウを covered として記録しないでください。user-posts にはメイン投稿だけが表示され、返信を確認することはできません。この CLI がないホストでは、利用可能な既存の Web／X 公式サイトの経路を使用します。これらの経路も利用できない場合は main_posts=unknown と記録し、網羅できたと偽らないでください。

Radar は引き続き構造化インデックス経路として使用します。Tibo Radar JSON API を使って最新の公開告知を取得します（2026-08-26 実測で 200）：

curl -s -m 15 "https://codex-reset.com/api/timeline" | python3 -c "
import json,sys
for e in json.load(sys.stdin)['events'][:5]:
    print(e['announced_at'], '|', e.get('type'), '|', str(e.get('summary'))[:100])
    ow = e.get('official_window')
    if ow: print('   窗口:', ow.get('label'), '=', ow.get('start_at'), '→', ow.get('end_at'), 'UTC')
    print('   url:', e.get('url'))"

新しい項目が先頭です。主なフィールド：announced_at（UTC ISO）、summary（途中で切れている場合があります）、url（元の投稿）、official_window、reset_verification_status。type は内部用の小文字の値です。reset = 広範囲のリセット告知、credits = banked／クレジットパック、boost／promo = 消費ルール関連です。

Radar で新しいインデックス項目を取得したら、まずその項目の元の投稿全文を読んでから、今後の約束、または予定を変更する時間・種類・範囲が含まれているかを判断してください。 要約、type、official_window、検証ラベルは位置の特定と照合のためだけに使います。いずれかが空でも、全文を読む手順を省略してはいけません。全文を読んだ判定結果と未確定のフィールドを finding ／ forecast に記録します。全文にも約束がなく、台帳にも期限が来ていない未確定の約束がない場合に限り、この確認回を「確認済み範囲内に新しい意思決定シグナルなし」と記録できます。

要約の切り詰め部分に予告が隠れていることもあります：2026-09-08 の実測では、最新項目の summary は冒頭の冗談で途切れており、official_window=null、announcement_state=none、検証ラベルは pending でした。しかし、元の投稿全文では、有料サブスクリプション全体のグローバルリセットが、投稿当日の太平洋時間 18:00 頃に行われることが明確に予告されていました。まず全文を読んでから判断してください。インデックスのフィールドだけで「新しい予告なし」と判断してはいけません。この投稿は北京時間 09-08 03:24、太平洋時間 09-07 12:24 だったため、予告の時刻は北京時間 09-08 09:00 に換算されます。これは今回の予告の換算例であり、固定スケジュールでも、リセットが実際に適用された証拠でもありません。

⚠️ type は Radar の編集者が付けたラベルであり、イベントの性質を機械的に判定したものではありません。プラットフォームをまたいだやり取りにも reset が付くことがあります。 2026-09-05 の実測例：Tibo は Anthropic の Lydia Hallie に返信しました（元の投稿：「We've just reset weekly limits for everyone on a Claude Max plan」。Claude 公式のリセット発表に便乗したもの）。Tibo の返信は「Wow, huge, wonder why!」という皮肉な一言だけでしたが、Radar はそれにも type=reset を付けました。曖昧さを解消する唯一の方法は元の投稿を読むことです。fxtwitter のレスポンスに含まれる replying_to（返信先のユーザー）＋ replying_to_status（返信先の投稿 ID）は、この手順のためのフィールドです。

url は上記コマンドの出力に含まれます（2026-08-31 以降は直接表示されるため、二度目の照会は不要です）。取得したら、まず元の投稿を読んでください。twitter-cli が利用できない（未ログイン／未インストール）場合に限り、X 投稿の本文を取得する最も有効な経路は fxtwitter の公開ミラー API です（2026-08-30 の実測では、ログイン不要で直接アクセスでき、完全な JSON が返されます。本文全文は tweet.text フィールドにあります。full_text ではありません。そのキーは存在せず、そのまま使うと KeyError が発生します。note_tweet の長文も全文が返され、8-29 の公式告知の長文では、2324 文字が自然な結びまで完全に取得できました。ただし、2026-09-24 の実測では、全体を通して利用できない状態が続きました（12 回連続失敗）。一方、ログイン済みの twitter-cli では user-posts --json 自体に本文全文が含まれます。経路は文書の記述をそのまま踏襲せず、機能に基づいて優先順位を付けてください）：

curl -sS --max-time 20 "https://api.fxtwitter.com/<user>/status/<status-id>" \
  | python3 -c "import json,sys; t=json.load(sys.stdin)['tweet']; q=t.get('quote'); print(t['created_at']); print('reply_to:', t.get('replying_to'), t.get('replying_to_status') or ''); print('quote:', json.dumps(None if not q else {'id':q.get('id'),'url':q.get('url'),'text':q.get('text')}, ensure_ascii=False)); print(t['text'])"

予備手段と行き止まり（同日実測）：

• cdn.syndication.twimg.com/tweet-result?id=<id>&lang=en&token=a（公式エンドポイント、200）：本文は 276 文字で途切れ、note_tweet は id のみで内容なし——冒頭とメタデータの照合にしか使えず、長文は取得できません。
• publish.twitter.com/oembed：301 で publish.x.com に転送された後（-L を追加）、200+JSON を返しますが、表示される テキストも同様に途切れます（約273文字、省略記号で終了。切断位置は syndication と同じ）——syndication と同じ水準で、冒頭とメタデータの照合には十分ですが、note_tweet の全文は取得できません。
• Jina Reader 利用可能ですが断続的なため、主経路として依存しないでください：匿名で x.com にアクセスすると、他者による悪用が原因で断続的に全体 BANされます（403、2026-08-30 実測：数時間後に解除され、解除後は匿名でも投稿本文を取得可能。エラーメッセージには悪用を引き起こした第三者アカウントが明記されています）；本リポジトリの jina key は残高切れで 402 です。fxtwitter を優先し、Jina はその予備としてのみ使ってください。
• fxtwitter は返信の内容を返しません（replies フィールドは数値の件数のみ）。返される replying_to（返信先の handle）と replying_to_status（返信先投稿の id）で、既知の投稿が返信かどうかは判断でき、 返信先の投稿自体は同じコマンドでもう一度取得できます。ただし、メイン投稿への返信を列挙することはできません。メイン投稿でヒットがゼロ、メイン投稿のタイムラインに新しい項目がない、あるいは CLI search が 404 を返す場合でも、「返信はない」と書いてはいけません。
• 既知の候補投稿（公式発表投稿、実施報告投稿）の返信チェーン確認には、より安価な方法があります：twitter tweet <id> --json は一度で メイン投稿＋replies を返します（著者フィールドは data[].author.screenName——userName ではありません。2026-09-24 実測 50 items。これに基づき、約束の投稿に対する Tibo 本人の返信がゼロであると確認）。これは「この投稿への返信」のみを返します。「最近、彼が誰に返信したか」の探索的スキャンには、引き続き以下のウェブページをスクロールする方法を使います。twitter search（from: クエリを含む）は実測で HTTP 404 となり、検索経路は利用できません。
• 範囲を限定した返信発見経路（2026-09-23、ログイン済みの X 公式サイトで、メイン投稿の入口から漏れていた古い返信を確認）：
  1. まず起点を固定します。前回の信頼できる返信チェックの UTC を使い、なければ今回のタスク対象期間または現在未解決の約束の起点を使います。 https://x.com/thsottiaux/with_replies を開き、今回の URL、起点、開始時刻を記録します。
  2. ページに実際に表示され、作者が Tibo である項目だけを記録します。各項目の status ID と UTC を保存し、古い方へ続けてスクロールして、 ページが起点を越えるか、読み込み停止／リソース上限／サイト障害が明確に発生するまで続けます。ウェブページを時間境界までスクロールしたことは、その地点を観察したことを示すだけであり、区間を網羅した証明にはなりません。これを根拠に covered と記録してはいけません。
  3. 予定、時刻、種類、範囲を変える手掛かりとなる約束を見つけたら、古い内容の確認を続けずに止め、その内容を候補として記録し、裏付けを追加します。重要な候補ごとに、上記の fxtwitter 単一投稿コマンドで本文、replying_to_status、および quote の id／URL／本文を取得します。parent があれば同じコマンドで parent を取得します。quote があり、その内容が判断の根拠となる場合は、quote URL を使って元の投稿を取得します。 quote: null は正常な引用なしの状態であり、未確認を意味しません。実際に存在する判断根拠ノードを取得できない場合に限り、該当する判断を unknown のままにします。
  4. finding に window_start/window_end、観察した status IDs、最も古く見える UTC、および停止理由を記録します： boundary_observed／loading_stopped／resource_stop／site_failed／not_logged_in。 ログイン状態がない、またはサイト障害が発生した場合は unknown です。境界まで到達していてもウェブページのスクロールによる証拠しかない場合は partial とし、否定的な結果は「今回観察した返信には関連する手掛かりがありません」とだけ記載します。
• 各回、対象ごとに返信の確認範囲を記録します：covered(candidate_chain:<id>) は、既知の候補の本文および実際に存在する parent／quote の判断根拠ノードを完全に確認した場合、またはインターフェースが実際の網羅を示すシグナルを提供し、明確な範囲を記録した場合にのみ使います； partial(<window>) は範囲を限定したウェブ観察に使います；uncovered は返信を構造上含まないメイン投稿／ミラーの入口しか確認していないことを示します；unknown は返信経路が失敗した、または利用できないことを示します。後の3種類はいずれも、その期間に返信がない、あるいは全体として新しいシグナルがないと断定する根拠にはなりません。メイン投稿の入口は常にメイン投稿の coverage としてのみ数えます。返信がゼロ件でも、本文全体が返されても、返信の coverage に格上げしてはいけません。
• 実施報告投稿の返信チェーンは確認してください。tracker の項目数はイベント数と同じではありません（2026-09-10 実測）：09-08 の 「All reset for everyone」公式発表投稿に対し、Tibo は「You forgot the part where I reset usage twice in the middle」と返信しました——正式な実施前に、その日、全体リセットがすでに途中で2回行われたという情報は、この返信にしかありません。 codexrunway はこの返信を、2件目の独立した Completed Global reset（Confidence 93%）として分類しました。予告＋途中の追加措置＋実施は1回のイベントとしてまとめます（統合ルールは next-reset-forecast を参照）。返信の確認には同じ fxtwitter コマンドを使い、返信投稿の id は tracker ページ内の x.com ステータスリンクから取得します（2026-09-10 は codexrunway の静的 HTML から grep で取得）。fxtwitter 自体には replies の一覧がありません。

codexlimitwatch.com/codex-reset-history と Radar はどちらも Tibo の投稿を主な上流情報としているため、同じ情報源の系列 に属します。転記／解析が一致しているかの相互確認にしか使えず、独立した複数情報源とは言えません。LunarWerx Codex Forecast （codex.lunarwerx.com）は両者の中間に位置します。検証経路は独立しています（サイト自身の説明と、meta description の実測値に「checked against OpenAI's own status page」とあります）が、データの上流は依然として公開されているリセット記録（Tibo の投稿を含む。コミュニティの説明では、そのモデルは Tibo の hints に基づく）です。そのため、「Tibo のシグナルの解釈を第三者と照合する」用途には適しています（2026-08-30：celebration 投稿を独自に同じ「明日リセット」と解釈し、95% confident と表示）。一方、「リセットイベントを独立して観測した」2つ目の情報源として扱うことはできません。そうすると、この skill が警告する同一情報源の誤りを犯すことになります。これは SPA であり、静的な取得では meta とシェルしか取得できず、本文は WebSearch の引用を通じて参照します。HTML codex-reset.com/tibo は SPA であり、静的コンテンツは遅れている可能性があります。人間向けの表示にのみ使ってください。 サードパーティの予測ソース：www.codexrunway.com/api/status.json は 2026-09-26 に didcodexreset.com/api/status.json へリダイレクトされます。取得のたびに最終 URL、generatedAt、 lastSuccessfulCheckAt、monitor.status と現在のフィールドを照合し、旧ドメインや旧フィールドが 恒久的に有効であると仮定しないでください。 現在のレスポンスは events[] の kind で reset_scheduled と reset_completed を区別しており、 旧説明にあった Expected next reset フィールドはありません。これも Tibo などの公開情報に対する 同族の解釈であり、独立したアカウント観測ではありません。 JSON 直取得に失敗した場合は最大 3 回再試行します。直近の完了済みイベントを取得するには [e for e in d['events'] if e.get('kind') == 'reset_completed'] を使い、announcedAt で並べ替えます。 予測時刻は必ず元ポストで照合してください：各 reset_scheduled について announcedAt、effectiveAt と 元ポストの時間表現を比較します。2026-09-26 のレスポンスは、期限のない将来時制の約束を scheduleBasis=explicit と しており、effectiveAt は元ポストの announcedAt よりも早くさえあります。発効時刻がソースポストより早い場合、 または元ポストに期限がない場合は、約束は未履行として保持し、サイトが示す日付は採用しません。reset_completed も サイトの分類にすぎないため、元ポストで完了の表現を探すか、製品の読み取り値で検証する必要があります。 status=='completed' でのフィルタリングはイベントの判定基準にはなりません。 このイベントを使う前に resetType と source.origin を確認してください：resetType は global または banked で、 banked は global 予測の検証には使いません。source.origin=operator はサイト運営者が手動入力したことを示し、X の元ポストが ありません（source には内部の postId のみで、handle と x.com リンクはありません）。X 由来のイベントには origin キーがありません。 どちらのタイプも operator 由来であり得ます（global の例：2026-08-25 「Operator-confirmed … without an X announcement」）。この種のイベントは候補として扱います：2026-09-29 DevDay の banked 到着はまさにこの形態で最初に現れ、サイトの自述ソースは元ポストではなく運営者であり、 ユーザーが名下の複数アカウントで受領を確認するまで確定しませんでした。履行済みへの格上げの根拠はタイプ別に分かれます： banked イベント——公式の元ポスト、またはユーザー自身のアカウントでの直接観測、または同一 account_ref の banked 在庫の前後読み取り値。global イベント——公式の元ポスト、または複数アカウントで 自然周期を排除した後の使用量回満読み取り値。事前の読み取り値がない場合は現在値のみを報告します：banked は「到着未検証」、 global は「発生未検証」と記載します。

Radar は公式障害線をインデックスできません——これはアナウンス経路の構造的盲点です。 Radar は @thsottiaux のみをインデックスしており、 ChatGPT/Codex の障害は @ChatGPT アカウントと status.openai.com によって発信されます。リセットが 障害補償に使われることもあります。Tibo のポストだけを確認するとこの手がかりを見落とします。回答のたびに障害線も併せて確認してください。

# 官方状态页（2026-09-01 实测 200，返回 Partial System Degradation + 未解决事故）
# 重试是必须的，不是保险：不带重试的裸命令实测会间歇吐 JSONDecodeError 而不是「站点挂了」
for i in 1 2 3; do
  o=$(curl -s -m 20 -A "Mozilla/5.0" "https://status.openai.com/api/v2/summary.json")
  if printf '%s' "$o" | head -c1 | grep -q '{'; then
    printf '%s' "$o" | python3 -c "
import json,sys
d=json.load(sys.stdin); print(d['status']['description'])
for c in d.get('components',[]):
    if c.get('status')!='operational': print(' 异常组件:', c['name'], '→', c['status'])
for i in d.get('incidents',[]): print(' 未解决事故:', i['name'],'|',i['status'],'|',i['created_at'])"
    break
  fi
  echo "  attempt $i 空响应，重试中"; sleep 3
done

@ChatGPT のポストには fxtwitter の同じコマンドを使い、<user> を ChatGPT に置き換えるだけです。本節のすべての外部エンドポイント （Radar、fxtwitter、ステータスページ）は断続的に不安定になります——本機でプロキシ経由時、同一分内に status.json が空を返す 一方で summary.json は成功し、Radar の初回実行が空のレスポンスボディを返して直接 JSONDecodeError になり、fxtwitter が連続 2 回 SSL_ERROR_SYSCALL で 3 回目に成功した（2026-09-07 独立再測定）——失敗したらまず 2〜3 回再試行してからエンドポイント 利用不可と判定してください。1 回の失敗は「サイトが落ちた」ことを意味しません。

⚠️ summary.json は現在の緑かどうかしか見られず、過去の障害は読めません——必ず incidents.json も併せて確認してください。 summary だけを実行すると、終了済みの補償型 Codex/Work 障害（例：09-14 02:46 UTC「Elevated error rates for Codex and ChatGPT Work」）とサイレント型の使用量異常調査（例： 09-09 17:29「Investigating unexpected usage limit resets」、本文 "Some Codex users may be experiencing unexpected usage limit resets"）を見落とします。後者は使用量に直接関わり、しかも名前に Codex が含まれません。 Codex/Work という名前だけでフィルタリングするとこれを見落とします。毎回、下記のコマンドを summary と一緒に実行してください：

# 近期 incident + 完整正文（summary.json 看不到）。按补偿/额度语义标记：
#   [补偿型] 名字含 Codex/Work
#   [静默型] 名字或正文含 usage limit / unexpected reset / billed / quota（不依赖 Codex 命名）
for i in 1 2 3; do
  o=$(curl -s -m 20 -A "Mozilla/5.0" "https://status.openai.com/api/v2/incidents.json")
  if printf '%s' "$o" | head -c1 | grep -q '{'; then
    printf '%s' "$o" | python3 -c "
import json,sys,re
d=json.load(sys.stdin)
silent=re.compile(r'usage limit|unexpected.*reset|billed|billing|quota|payment',re.I)
for inc in d.get('incidents',[])[:14]:
    name=inc.get('name','')
    body=' '.join((u.get('body') or '') for u in inc.get('incident_updates',[]))
    f=''
    if 'Codex' in name or 'Work' in name: f+=' [补偿型]'
    if silent.search(name) or silent.search(body): f+=' [静默型-额度]'
    print(f\"{inc.get('created_at','')[:16]} | {inc.get('impact',''):6} | {inc.get('status','')} | {name[:52]}{f}\")"
    break
  fi
  echo "  attempt $i 空响应，重试中"; sleep 3
done

候補にヒットしたら incident_updates[].body で本文を読んで判断します：補償/reset/使用量の表現を含む → 強信号に格上げ（09-12 の "reset is also landing by midnight today" と照合）。純粋なエラー率の変動で補償の表現がない → 候補としてのみ記録。 impact: none かつ 2 時間未満で復旧、本文に使用量の意味がないものはノイズとして無視します。

③ コミュニティポスト分類器、通常ポーリングに組み込みます。 これは @thsottiaux のポストを追跡し、Radar が 見落としたポストや異なる解釈を示唆できます。ポストがなくアカウントの使用量変化だけがあるサイレントリセットを 独立に発見することはできません。後者は §3 のアカウントとコミュニティの実測に従います。 毎回、上記と一緒に実行してください（アップストリームとミラーは同源であり、解釈のクロスチェックのみで独立したカウントは増えません。まず成功チェックと時刻を確認し、次に Yes/No を読みます）：

# 社区帖子分类器（提取候选与检查时刻，按下文判读）。http!=200 就跳过，不阻塞。
for u in "https://hascodexratelimitreset.today" "https://lidless.app/did-codex-reset-today"; do
  f="/tmp/tibo_c_$(echo "$u"|md5).html"
  code=$(curl -sS -m 15 -A "Mozilla/5.0" -o "$f" -w '%{http_code}' -L "$u")
  [ "$code" = "200" ] || { echo "  $u http=$code 跳过"; continue; }
  python3 -c "
import re,html
t=open('$f',encoding='utf-8',errors='replace').read()
txt=re.sub(r'<script.*?</script>|<style.*?</style>','',t,flags=re.S)
txt=re.sub(r'\s+',' ',html.unescape(re.sub(r'<[^>]+>',' ',txt))).strip()
m=re.search(r'(No sign.{0,80}|Verdict: (Yes|No))',txt)
mirror='lidless.app' in '$u'
unready=re.search(r'No classification yet|Awaiting first pass|Waiting for first tracked post',txt,re.I)
checked=re.search(r'Last checked.{0,70}',txt,re.I)
if mirror: verdict='unknown: mirror requires upstream and time check'
elif unready: verdict='unknown: first pass incomplete'
elif not checked: verdict='unknown: check time unavailable'
else: verdict='unknown: verify check time'
print('  monitor:',verdict[:90],'| candidate:',(m.group(0) if m else 'none')[:90],'| check:',(checked.group(0) if checked else 'time unavailable')[:90])"
done

No classification yet / Awaiting first pass、検証可能なチェック時刻の欠如、チェックが本轮の承重アナウンスより早い、 またはそのタイムゾーン換算で現在時刻より遅い場合は、いずれも unknown と記録します。ミラーは候補文案を表示するだけで、 アップストリームの成功チェックを補うことはできません。 アップストリームのチェック時刻が有効で候補文案が Yes に変わった場合、または lidless 文案が "No sign" から実証に変わった場合は アップストリームで照合した後、まずそれが引用する元ポストを探し、次にリアルタイム API と同時刻帯のアカウント実測で検証します。 リセットの公式発表があれば公式発表経路で判定し、公式発表がなくアカウント異常なゼロ化であれば §3 のサイレントリセット 経路に従い、いずれも証拠の範囲で命名し、全員に外挿しません。候補 No / 解析不能は このポスト分類器が陽性を示さなかったにすぎず、未履行の公式発表、アカウント異常、またはユーザーが現在問い合わせている原因を 打ち切るものではありません。

2. 本机取证：Codex rollout 快照 = 可脚本化的匿名用量证据

~/.codex/sessions/<YYYY>/<MM>/<DD>/rollout-*.jsonl 在 Codex 运行期间写入 rate_limits 快照，可回溯本机观测到的用量变化区间。快照没有账号身份，也不覆盖未运行 Codex 的账号； 逐账号现值和身份仍以经核对的产品页或实时 API 为准。字段形状：

{"limit_id":"codex","primary":{"used_percent":76.0,"window_minutes":10080,"resets_at":1788753995},
 "secondary":null,"credits":{"has_credits":false,"balance":"0"},"plan_type":"pro"}

本节命令针对默认 ~/.codex 主页；使用自定义 CODEX_HOME 时，将本节 auth 与 sessions 路径 统一替换为同一个已授权主页，不能将两个主页的快照混用。 resets_at 是 epoch 秒；window_minutes 10080 = 周窗口、300 = 5h 窗口。快照中的 credits 与备用重置的区别，见账号 SOP 的字段读法。 要备用重置数量就别在这份快照里找：该键只有 balance/has_credits/unlimited， 它不携带 banked 数量。这是「换源」， 不是「这次没查到」——直接跑 scripts/query_usage.py。

会给出貌似合理错答案的陷阱（每一条都不报错；1–3 于 2026-09-01 同一次会话里连踩，4 于 2026-09-03 补）：

1. primary 槽位不固定指向周窗口。 同期快照里 primary 有时是 300（5h）。按 window_minutes 分桶，别假设 primary = weekly——混着读会把 5h 窗口的 0% 当成周额度重置。
2. limit_id 有多个桶，其中有恒零的诱饵。 实测同期存在 codex、premium、 codex_bengalfox，而 codex_bengalfox 的两个窗口恒为 0%，混进序列会凭空造出几十次 「重置」。先 limit_id == "codex" 过滤再做任何判断。
3. resets_at 每条快照都秒级微漂。 用「resets_at 变了」判重置会得到几百个假阳性； 归零列表使用脚本定义的大幅降幅阈值。自然周期刚过后的额外重置可能只下降几 个点，另列为「低用量锚点前移」候选；采样间隔较长时，后一条快照可能已重新消耗不少额度。 锚点前移也可能是自然周期、账号切换或并发会话， 候选与归零列表都不直接证明平台事件。两处都无命中也不证明没有重置。
4. 目录日期 ≠ 时间戳范围——按 sessions/<Y>/<M>/<D>/ 数天数会静默少采样。 跨午夜的 长 session 把次日的时间戳继续写进前一天的目录，所以「扫最近 N 个日期目录」拿不全 最近 N 天；多账号交错的短时变化也可能因此漏掉。 修法：运行 scripts/scan_rollouts.py；它额外覆盖跨日目录，再按实际时间戳裁剪。

窗口锚点的形状——注意「干净 +7d」本身不是重置的证据：

• 干净 +7d：新 resets_at ≈ 归零时刻 + 窗口长度。这只说明窗口从归零那刻重新起算， 它同时是按钮式重置和「换到另一个有额度的账号」的形状——两者在这个维度上不可分。要 定性必须再过下面的多账号归因检查。
• 非干净 +7d：新锚点没有贴近该条快照时刻加一周；采样间隔长也会出现这个标签， 它不说明锚点相对前一条是前移还是回拨。
• 锚点回拨：新锚点比上一快照的锚点更早。多账号机器上，切回窗口开得更早的账号也会 出现这种形状；先排除账号，再谈窗口配置切换。
• 账号切换：见下面的多账号检查。它可以伪装成上面任何一种。

并发 session 会让同一变化输出多条归零记录。 滞后的 session 先报旧值、再各自更新。 归零列表未去重；同锚点的相邻行要并排核对，不能机械相加或直接认作同一账号。低用量候选 另有去重逻辑，两种列表的条数都不是已确认的重置次数。

⚠️ 别把「并发 session 滞后」当成万能解释——它专门用来掩盖多账号。 按锚点去重合并的是 新锚点相同的两条，机械上碰不到锚点不同的记录；真正的风险在判断层：看到两条时间相邻 而数值矛盾的记录，顺手归给「滞后 session」，就会漏掉账号交错的线索。 used_percent 是已用量，正常使用本来就会上升。短间隔内大幅上升并伴随锚点回拨时， 核对身份、取样间隔、会话来源和限额配置；不能仅凭形状排除其他解释。 用量上升并伴随锚点回拨时，线索在第 1 步的「回跳」输出，不在只收大幅下降的归零列表。 先读回跳，再读归零区间与低用量候选；逐项核对身份和周期后才能数已确认事件。

多账号归因检查

本节采用的 rollout 快照不记 account_id，仅凭这些无身份快照不能区分账号交错与真实重置。

先说清楚一个结构性陷阱：直觉上的那个检查永远返回「只有一个」。 ~/.codex/auth.json 只保存当前登录的那一个账号，切走的账号不留痕；~/.cc-switch/cc-switch.db 只记它自己 管过的条目，手工 codex login 换的账号它完全看不见。拿这两处的当前状态去回答「历史上 用过几个账号」，是用当前快照回答历史问题——它不会报错，只会给一个貌似合理的错答案。 （2026-09-03 实测：一台确有两个 Pro 账号在轮替的机器，这两个探针都报「只有一个」，导致整份 归因写反。）

按下面 A/B/C 检查收集线索，再按 §3 的证据范围命名。身份不一致证明机器用过多个账号； 要判断某次跳变的原因，仍需把前后读数绑定到具体身份。

没有发现异常也不能证明单账户：A 只保留最近刷新时刻，B 不覆盖手工登录，C 看不到锚点 恰好单调的账号轮替。若用户尚未说明该时段是否切号，且答案会改变历史归因，再问一次； 已经确认的事实不重复问。身份无法分离时报告混合记录的归因限制，不把检查全绿当证明。

连带影响：登录/恢复账号会吊销别处持有的同账号 refresh token，而喊疼的只有「老进程」。 早已启动的 Codex TUI 把 token 缓在内存里、不随 auth.json 更新；旧 token 被吊销后， 只有这些进程按各自的定时器每 30~70 秒刷一次 Failed to refresh token: … signed in to another account——报错条数 = 进程数 × 重试频率，不是「出了那么多次问题」。处置是重启 这些老进程（启动时读新的 auth.json），不是全局重新登录；定位哪些进程在刷，查 ~/.codex/logs_*.sqlite（取 mtime 最新的一份；自定义 CODEX_HOME 时为 <主页>/logs_*.sqlite）按 process_uuid（内含 pid）分组计数。 （2026-10-03 实测：25+ 个 Codex 进程里只有 9 天前启动的两个在刷，各 164 次，重启后即止。）

执行顺序：先跑本节最后那段重建脚本，取得归零区间与 C 的回跳；再读 A，只有用户确实 使用 cc-switch 才读 B。A 的刷新时刻需要与归零区间对齐。

A 层 —— 当前身份 +（指示性的）最后一次刷新时刻

分别读取身份与刷新时刻，两者证据强度不同：

1. 当前登录身份（id_token 解出的 email / chatgpt_account_id / plan）——这是硬事实， 在 B 层适用时作身份比对。
2. last_refresh 时刻——指示性，不是判决：
   • 语义未标定：字段名就叫 refresh，token 续期也会写它。它落在归零区间内，仍 无法与一次纯 token 续期区分；归因条件见 §3。
   • 覆盖面只有一个点：它是单个时间戳，更早的刷新已经被覆盖，不能用它解释整段历史。
   • 不落在区间内 ≠ 该层干净：只说明「最近一次刷新不在这个区间」，更早的切换早已被 覆盖掉（这正是 auth.json 只存当前状态的后果）。

python3 -c "
import json,os,base64
d=json.load(open(os.path.expanduser('~/.codex/auth.json')))
t=d.get('tokens') or {}
print('last_refresh:', d.get('last_refresh'), ' <-- 与归零区间对齐')
print('account_id  :', t.get('account_id'))
idt=t.get('id_token')
if idt:
    p=idt.split('.')[1]; p+='='*(-len(p)%4)
    pl=json.loads(base64.urlsafe_b64decode(p))
    a=pl.get('https://api.openai.com/auth') or {}
    print('email       :', pl.get('email'))
    print('plan_type   :', a.get('chatgpt_plan_type'))
"

B 层 —— 这台机器上还存过哪些账号（仅在用户确实使用 cc-switch 时检查）

这是历史归因的可选线索，不是账号盘点入口。用户明确不用 cc-switch 就跳过本层，转官网和 Google 已登录账号。（逐账号额度查询的入口裁定见 account-usage：这批账号 2026-09-08 已 裁定不用 CC Switch 管理——B 层的 providers 记录只作邮箱线索，不为查询额度重开此裁定。） 下面的 providers 只证明其记录里出现过的身份，不能证明账号清单完整。

profiles 表实测可能是空的（2026-09-03 该机 0 行），账号存在 providers 里；每条的 settings_config 内嵌一个完整 auth 对象，解它的 id_token 才能拿到身份。

python3 -c "
import sqlite3,os,json,base64
db=os.path.expanduser('~/.cc-switch/cc-switch.db')
if not os.path.exists(db): raise SystemExit('no cc-switch.db (不构成单账户证据)')
c=sqlite3.connect('file:'+db+'?mode=ro',uri=True)
for pid,name,cur,cfg in c.execute(\"select id,name,is_current,settings_config from providers where app_type='codex'\"):
    auth=(json.loads(cfg).get('auth') or {}); tk=auth.get('tokens') or {}; email=None
    if tk.get('id_token'):
        p=tk['id_token'].split('.')[1]; p+='='*(-len(p)%4)
        email=json.loads(base64.urlsafe_b64decode(p)).get('email')
    mode=auth.get('auth_mode')
    kind='ChatGPT 账号(计入)' if mode=='chatgpt' and email else 'API-key provider(不是账号,忽略)'
    print(f'{name!r} is_current={cur} auth_mode={mode} email={email}  <- {kind}')
"

判读规则（只数真正的 ChatGPT 订阅账号）：app_type='codex' 底下混着 API-key provider （实测该机有一条 DeepSeek，auth_mode=None、email=None）——那不是 ChatGPT 账号，不参与 账号计数。只看 auth_mode='chatgpt' 且 email 非空的行。

• 这类行里出现与 A 层不同的 email → 两个账号的直接证据（2026-09-03 与 2026-09-04 两次 实测都是这样命中的）。
• 只有一行且与 A 层一致 → 该层无阳性证据。
• email=None 或 auth_mode 非 chatgpt 的行 → 忽略，别拿它跟 A 层比「不一致」。

⚠️ is_current=1 不是「当前登录」的判据。 它只表示 cc-switch 自己最后切换到谁；用户绕过 它手工 codex login 之后这个标记不会更新。2026-09-04 实测：该机 is_current 指向的 email 与 A 层 auth.json 显示的实际登录 email 是两个不同的真实账号——同一份 读数同时演示了这条陷阱和 B 层的命中形态（两处 email 不一致本身就是多账号的直接证据）。 当前 CLI 登录身份以 A 层为准；网页身份另从网页核对。is_current 只回答旧工具记录过谁。

B 层安静不代表单账户——它看不见手工 codex login。

C 层 —— 行为签名：锚点回跳（只靠 rollout，A/B 都失效时仍然有效）

回跳检查不依赖 auth 文件，但它只检测快照形状，不输出账号身份。窗口配置、取样间隔与 账号交错都需要核对；判读：

• 回跳次数 = 0 → 没有阳性证据（不等于单账户，见本节开头的闸门说明）

• 回跳带 used% 上升 → 标记需核对的交错/配置线索，不直接写成多账号事实。

• 大幅回跳 → 优先查账号切换与限额配置变化，归因条件见 §3。

• 回跳存在但既不大幅、也没有 used% 上升（中间带）→ 保留待核，不忽略，也不直接定性。 这一带里限额配置切换与账号切换真的不可分；不要因为「看起来不够大」就默默放行。

• 「同分钟 + 同锚点 + 不同 used%」不能判账号交错：并发 session 的轮询滞后也会产生 这个组合，不要把它计作独立账户线索。低用量锚点前移同样只是重置、自然周期和切号的共同 形状，不是新的账号身份检测器。

免费的账号指纹 —— usage-limit 报错里的 try again at

撞上限时 Codex 会写一条 task_complete 错误，正文形如：

You've hit your usage limit. Visit <codex usage settings URL> to purchase more credits
or try again at Sep 7th, 2026 3:23 PM.

try again at 是产生报错的登录上下文当时报告的重置时刻。非单调回退可提示账号交错， 但不携带身份，也不能独自排除窗口配置变化。下面这条 命令扫全量历史并自己标出回退，实测该机打印 17 次（两个桶来回交替时每次切换都记一次， 所以它是「有没有交替」的指示器，不是「切了几次账号」的计数）。最硬的一处是 08-25 14:46 同一分钟内出现 4 个不同取值——几个并发 session 各挂在不同账号上同时撞墙。（不是「聚成两簇」： 每次重置都会生成新窗口，取值本来就一直在变，簇数不是信号，单调性才是。）

⚠️ 用指纹支持某个具体归因前，先核对回退时刻是否落在该区间内。 序列在 A 段单调、在更早的 B 段有回退，不构成 A 段账号交错的证据——「这台机器历史上换过号」和「这次跳变是换号引起的」 是两个命题，共用一条命令的输出不等于共用证据。实测踩过（2026-09-16）：引用 09-09→09-15 的取值论证该区间账号交错，实际该区间零回退、取值单调递增，全部回退都在 08-25→09-08， 即被论证区间之前。这类错误的成本不在算错数字，而在于它把一个「原因未核实」的跳变写成了 确定性归因——这正是 §3 要求先按证据范围命名的原因。

python3 -c "
import json,glob,os,datetime,re
BJ=datetime.timezone(datetime.timedelta(hours=8))
T=lambda x: datetime.datetime.fromisoformat(x.replace('Z','+00:00')).astimezone(BJ)
rows=[]; prevdt=None
for f in sorted(glob.glob(os.path.expanduser('~/.codex/sessions/*/*/*/rollout-*.jsonl'))):
    for line in open(f,encoding='utf-8',errors='replace'):
        if 'usage limit' not in line: continue
        try: d=json.loads(line)
        except: continue
        e=((d.get('payload') or {}).get('error') or {})
        m=e.get('message') if isinstance(e,dict) else None
        if not m or not d.get('timestamp'): continue
        v=m.split('try again at')[-1].strip().rstrip('.')
        try: dt=datetime.datetime.strptime(re.sub(r'(\d+)(st|nd|rd|th)',r'\1',v),'%b %d, %Y %I:%M %p')
        except Exception: continue
        rows.append((T(d['timestamp']),v,dt))
rows.sort(); prev=None; back=0
for t,v,dt in rows:
    if v==prev: continue                      # 只看取值变化
    mark=''
    if prevdt is not None and dt<prevdt:
        back+=1; mark='   <-- 非单调回退：需核对账号或窗口配置'
    print(f'{t:%m-%d %H:%M} | try again at {v}{mark}')
    prev=v; prevdt=dt
print(f'\n非单调回退次数: {back}   （只报告形状，不证明账号数量或归零原因）')
"

归零只能报区间，不能报时刻。 相邻快照可能相隔数小时；写「落地在 A–B 之间」， 别把「首个见到 0% 的快照时间」当成到账时刻。另外快照只更新到用户最后一次跑 Codex 的时刻——下「至今没有重置」之前先看最新快照有多旧，那之后是盲区。 按账号 SOP 读取实时接口或产品页可以确认当前状态，但补不上过去的历史盲区。

rollout 还有一个覆盖边界：每条只观测产生它的登录上下文，历史集合可能混有多个账号，且没有 逐条身份标签。 没运行过 Codex 的其他账号没有快照，不能从集合的最后一行推断全部账号。 用户转述的逐账号产品页读数是对应账号的第一手观测；引用相对倒计时时，折算成绝对时刻并 标注折算所用的观察时刻。

query_usage.py 的 reset_at 与扫描尾部锚点一致，只是窗口时刻相符，不能给匿名快照补上 账号身份；判断当前 CLI 账号时，以经认证身份核对的 API 或产品页读数为准。历史区段的 身份无法建立时保留混合序列的归因限制。

# 重建本机周额度曲线 + 多账号回跳与低用量锚点前移候选
uv run python scripts/scan_rollouts.py --days 7
# 复现历史某时刻的切面（两端均按时间戳裁剪）：加 --as-of "2026-09-12T17:44:00+08:00"
# 自定义 CODEX_HOME 时：--codex-home <已授权主页>（auth 与 sessions 必须同属一个主页，不混用）

3. 静默重置路径：查账户事实，而不是继续等帖子

在用户直接观测与公告索引冲突时，按顺序取证：

1. 定账户事实：记录 weekly 与 5h 是否回到 100%、Next reset 是否移动、banked reset 是否仍在，以及变化是否正好发生在此前已显示的正常重置时刻。产品 usage 页或 /status 只证明该账户，但证据级别高于聚合器的空结果。用户口头或聊天里转述的产品页观测（多账号 额度统计、banked 余额、「有 N 次 full reset」）记为直接观测，与产品页同级——不必为了 「亲眼看」逼用户再截图或跑命令。本机有 ~/.codex 就先跑 §2：它提供历史观测区间与 锚点候选；是否由正常周期解释，按账号 SOP 核对同一账号的前后读数。
2. 找同时段实测：用当前 UTC/PT 日期搜索最近帖子，例如 Codex reset today back to 100%、 Codex reset again 5h、site:reddit.com/r/codex reset today。优先截图、明确的前后百分比、 Next reset 变化和「banked 仍在」；转载同一条消息不增加独立性。用户说「群里看到的」 且当前环境有群聊归档能力时，再搜「重置/reset/Tibo」核对群友实测，并分清截图是产品状态 还是 Radar 转发。
3. 找发布上下文：搜索 Tibo/OpenAI 是否正在切换 5h/weekly 限额、修计量或处理事故。上下文 与重置同刻发生只支持因果推断；官方没说「因此重置」就明确标为推断。
4. 按证据范围命名：
   • 先排除账号轮替。A/B 身份不一致证明机器用过多个账号，不证明某次归零必然由换号引起； last_refresh 落在区间里也只能作提示。能把该次前后读数绑定到不同身份，或用户明确说明这次换号， 才称「这次是账号切换」；否则写「混合账号记录，归零原因未核实」，不升级为平台重置。
   • 只有一个账户的当前读数 → 只报剩余、Next reset 与 banked 现值；发生未核实。
   • 同一 account_ref 的两个端点出现用量下降与锚点变化 → 「两个观测点之间窗口发生变化；原因未核实」。 端点相同不排除中间 A→B→A；匿名 rollout 也不能继承当前 API 的身份。只有账号 SOP 所列的直接重置事件、 明确自然周期形状、banked 直接兑现或范围匹配的官方证据，才可把窗口变化改称为相应重置。
   • 多个不同账户在紧邻时间内回满，但尚未排除各自正常周期与切号 → 「观测到跨账户近同时重置； 是否为同一平台事件未定」。
   • 多个独立账户的身份已绑定读数显示预告 Next reset/正常周期均解释不了这次提前跳变，且已排除切号 → 「观测到大范围静默重置」；同期限额发布只能补上下文，不能代替这项反证。
   • 只有官方明确写 all/every paid account → 才称「全员重置」。

静默事件没有官宣时间戳时，报告「最迟在最早公开证据的时间前已发生」，不要把发帖时间伪装成 精确落地时刻。

4. 告知時刻の換算

official_window が存在する場合は、まずその start_at／end_at を確認し、その後、以下のルールに従って自分でも換算してください。 不一致がある場合は差異を報告してください。オペレーティングシステムのタイムゾーンデータベースが決めるのは、あるタイムゾーンに適用するオフセットであり、投稿者がどのタイムゾーンを使ったかではありません。本人から確認が取れていない場合は、重要な字義どおりの解釈と主解釈の両方を残し、tracker による別の解釈をそのまま計算ミスとは呼ばないでください。

5. チャネルが失敗した場合

Radar API が停止 → twitter-cli（ログイン済みの場合：user-posts で主投稿のタイムラインと全文を取得し、tweet <id> --json で既知の投稿の返信チェーンを取得。2026-09-24 の実測では、Radar が連続 4 回空応答、fxtwitter が 12 回連続で失敗した日に、告知と返信の 2 つの確認経路を単独で支えました）→ fxtwitter で元の投稿を確認（§1 のコマンド）→ syndication 公式エンドポイント（276 文字で切り詰められるため、メタデータの照合にのみ使用）→ codexlimitwatch 単一ソース（同一ソースのミラーであることを明記）+ LunarWerx（Tibo のシグナル解釈との照合のみ。独立した観測を行う第 2 ソースではありません）→ WebSearch で thsottiaux reset の転記を検索します。製品が変更されたとユーザーから報告があった場合は、告知チャネルがすべて空でも、静かなリセットの経路を確認してください。製品やコミュニティの証拠もすべて取得できない場合に限り、「そのユーザーの観測は確認できるが、影響範囲は検証できない」と記述し、「リセットはなかった」とは書かないでください。 外部サイトへのアクセスには、まず curl による直接接続を使ってください。WebFetch がセキュリティ検証で遮断されても、サイトが停止している証拠にはなりません。feed.xml は実測上、API より履歴の反映が遅いため、代替手段として使わないでください。

複数のサイトを繰り返し取得する際、同じ一時ファイルを使い回さないでください。 curl -o /tmp/x.html が失敗（http_code=000）しても、古いファイルは空にならず、削除もされません。次のループで解析スクリプトを実行すると、エラーなく前のサイトの内容がそのまま出力されます（2026-09-01 の実測：codexreset.org から 0 バイトを取得したにもかかわらず、出力されたのは前のループの codexrunway の本文で、まったく成功したように見えました）。サイトごとに別のファイル名を使い、解析の前に必ず http_code を確認してください。

「彼はまだ新しい投稿をしていない」という否定の断言には、明確な限界があります。 fxtwitter には /status/<id> エンドポイントしかなく、ユーザーのタイムラインはありません（api.fxtwitter.com/<user> はプロフィールのみを返し、投稿一覧は含みません）。そのため、「新しい公式告知はない」という判断は、集約サービス（同系列）と WebSearch の照合にしか頼れず、本質的には「これらのチャネルには見当たらない」という意味であり、「彼は投稿していない」という意味ではありません。この確度に見合った表現を使い、「バックエンドで動きがなかったことを意味するわけではない」と補足してください。twitter-cli にログイン済みの場合は、この限界が後退します。user-posts で主投稿のタイムラインを直接確認できるため、「この確認対象期間内に新しい主投稿はない」と具体的に述べられます。ただし、返信は対象外のため、合わせて断言することはできません。

Tibo の時刻表記は大まかです（解釈ルール）

実測した原文：Reset will land around 14pm PST tomorrow.（2026-08-23 06:29 UTC に投稿）

• 「14pm」= 14:00 = 午後 2 時（24 時間制と am/pm を混用しています。字義どおりの時刻を使えば十分です）
• 太平洋現地時間を「PST」と表記することがよくあります。米国の夏時間は 3 月の第 2 日曜日～11 月の第 1 日曜日で、この期間の現地時間は PDT（UTC-7）です。主解釈は、対象日の America/Los_Angeles の夏時間・標準時間に基づいて換算してください。 一方、原文に PST と明記されている場合は、字義どおりの UTC-8 による別の解釈も計算し、本人による確認の有無を示してください。主解釈には過去の実績に基づく根拠がありますが、投稿者の意図が確認済みという意味ではありません。OS の換算だけを根拠に、1 時間の差を相手の誤りと判定してはいけません。 （夏時間の切り替え日に、投稿日のオフセットを使って「tomorrow」を計算すると、1 時間ずれることがあります）
• 「tomorrow / today」は、投稿時点の太平洋時間の日付を基準にします。announced_at（UTC）から 7 時間（PDT）または 8 時間（PST）を引いて投稿時点の太平洋時間の日付を求め、そのうえで tomorrow が指す日を確認してください。
• 「midnight」も同じ基準です（2026-09-12 の実測：「a reset is also landing by midnight today」は 03:20 UTC に投稿 = 太平洋時間では前日の 20:20。「today」= 太平洋時間の 9/11、つまり北京時間の 9/12 15:00 より前です。実際の適用確認の投稿は北京時間 16:09 に行われました）
• 「by EOD」も同じ基準で、太平洋時間当日の深夜を指します（2026-10-10 の実測：「Global reset by EOD」は 22:16 UTC に投稿 = 太平洋時間の 15:16。主解釈 = UTC 翌日 07:00 = 北京時間の翌日 15:00 より前に適用。実際には約 3 時間早く実現しました）。 EOD は期限の上限であり、適用予定時刻ではありません。
• 「予告の主解釈は○時です」と報告し、「その時刻になれば必ず反映される」とは報告しないでください。各回で現在時刻と目標時刻を比較してください。主解釈の時刻を過ぎても完了が確認できない場合は、「予告時刻は過ぎたが、適用は未確認」と報告してください。両方の解釈で時刻を過ぎた後は、タイムゾーンの曖昧さを理由に「まだ時刻になっていない」と説明したり、翌日に繰り越したりしないでください。公式の完了投稿の時刻は、あくまで確認時刻です。
• 過去の傾向（確約ではありません）：リセットは太平洋時間の午前 1 時～8 時（本人の睡眠時間）には行われず、太平洋時間の午後に集中します

タイムゾーン換算（コマンドは 2026-08-23 に実測済み。macOS 専用——BSD の date -j／-f を使用。GNU date にはこれらのオプションはありません）

# 免查时令写法（推荐）：让 OS 自己解 PDT/PST。注意 macOS BSD date 的 -f 不支持
# 直接解析 "PDT" 字样（illegal time format），所以要嵌套
TZ=Asia/Shanghai date -j -r "$(TZ=America/Los_Angeles date -j -f '%Y-%m-%d %H:%M' '2026-08-23 14:00' '+%s')" '+%F %H:%M %Z'
# 输出: 2026-08-24 05:00 CST  ← 太平洋夏令时下午2点 = 北京次日凌晨5点

# 已知时令时的直给写法：夏令时偏移 -0700（PDT），冬令时 -0800（PST）
TZ=Asia/Shanghai date -j -f "%Y-%m-%d %H:%M %z" "2026-08-23 14:00 -0700" "+%F %H:%M %Z"

# 反查：此刻太平洋几点（判断「tomorrow」锚哪天用）
TZ=America/Los_Angeles date "+%F %T %Z(%z)"

エビデンスに関する規律（失敗から学んだ教訓）

• アグリゲーターに記録がない ≠ リセットされていない：Radar と codexlimitwatch が主に答えるのは「Tibo が公に何を言ったか」であり、「バックエンドのアカウント状態に何が起きたか」ではありません。2026-08-25 の実測による反例：両サイトは 8-24 で更新が止まっていた一方、ユーザーは 2026-08-25 14:18 UTC から weekly が 100% に戻ったスクリーンショットや変更前後の数値を次々に投稿し、複数人が、元の Next reset の時刻をまだ迎えていない、または予期せず先延ばしになったこと、banked がまだ残っていることを明言しました。同日、Tibo が公式に発表したのは Plus の 5h 制限の復旧だけでした。正しい結論は「未告知の大規模なサイレントリセットが観測された」であり、「新たなリセットはなかった」でも、公式に対象範囲が確認されていない「全員がリセットされた」でもありません。
• まず、エビデンスがどのレベルを証明するかを見極める：プロダクトページが証明するのは 1 つのアカウントです。異なる複数アカウントで同じ時間帯に実測しても証明できるのは「複数アカウントでほぼ同時に観測された」ことだけで、各アカウントの通常周期も依然として別の説明になり得ます。これらのアカウントが予告されたリセット時刻をまだ迎えていなかったと確認できて初めて、共通のサイレントなプラットフォームイベントを裏付けます。全員が対象だと証明するには、公式の all/every という表現が必要です。結論にはこれらのレベルを明記し、1 枚のスクリーンショットから全体へ外挿することも、アグリゲーターに該当結果がないことを理由にプロダクト上の事実を否定することも禁止します。
• tracker の confirmed ラベルは、将来の予告にも付くことがあります。実際に反映されたことの証拠にはなりません。API の reset_verification_status は、反映を示す信頼できる肯定的シグナルを提供しません。プラットフォームの完了宣言は、Tibo の後続の元投稿とその表現の対象範囲で判断します。特定アカウントに反映されたかどうかは、自然周期の可能性を排除し、アカウントを切り替えた後に同一アカウントのプロダクト上の数値を前後比較して判断します。現在の残量を 1 回確認しただけでは、そのアカウントの現状しか証明できません。
• 彼の言葉で「celebration」とは、リセット操作そのものを指し、投稿で祝うことではありません（2026-08-30 の実地で得た教訓：「This celebration is moved to tomorrow as the button was already pressed today」を「ただのお祝い投稿で、リセットはない」と解釈したところ、独立した 2 つの情報源に即座に反証されました。翌日には完全に実現し、12:24 PT に「reset will land at 6pm PST」と予告、19:34 PT に「hit 25M active users…we have now reset usage for all paid subscriptions」と実施を確認しました）。彼はユーザー数の節目のお祝いとリセットを常に結び付けており、7M／8M／20M／25M の節目はいずれも banked/reset で実現しました。8M のときは「Tomorrow might be 8M active user celebration day」と発言し、9M に近づいた際には「もう一度リセットするか」の投票を実施しています（投票そのものは x.com/thsottiaux/status/2077271889626706300）。したがって、「celebration が明日に延期された」は、明日にリセットがあるという予告と読むべきです。 表現の度合いには注意が必要です。これはあくまで示唆レベルの公式発表です（「we will reset again tomorrow」と明記したわけではありません）。結論は「公式の示唆 + 複数の独立した tracker による一致した解釈 = 実施される可能性が高い」とし、慣例に基づき太平洋時間の午後に実施されると予測します。「公式に確認済み」へ格上げできるのは、公式に明記された場合に限ります。
• 複数の情報源の時刻を比較する前に、まず時刻を換算する：プラットフォームの完了投稿時刻と、各アカウントに反映される時刻は異なることがあります。各時点に元のタイムゾーンを記し、「時刻換算」節に従って換算してください。UTC と北京時間の時計表示が同じだからといって、同時刻の相互確認にはなりません。また、完了投稿が先で一部アカウントへの反映が遅れたことから、全員への反映が遅れたと直接推論することもできません。
• 公式発表 ≠ あなたのアカウントへの反映済み：banked reset には段階的に遅れて反映された履歴があります。ユーザーから「自分にはまだ反映されない」と尋ねられたら、公式発表の時刻を根拠に断言するのではなく、そのアカウントの予備リセット残量を反映前後で確認してください。反映の段階でも実測された不具合があります：2026-09-09、ChatGPT Work/Codex の使用時に一部の banked reset が完全に適用されなかったことを公式が確認しました。影響を受けた時間帯の利用者には 1 回分が追加で付与され、お詫びのメールも届きました。ユーザーから「banked を使ったのに変化がない」と報告されたら、まずその不具合の発生時間帯に該当するか確認してください。
• 「単一アカウント」という前提自体をまず証明する必要があります：auth.json に保存されるのは現在の ID だけで、過去にアカウントを切り替えていないことは証明できません。過去のアカウントに関する結論を出す前に §2 で ID と時間帯の手掛かりを集め、その後 §3 に従って命名してください。該当情報が見つからなくても、単一アカウントだったことの証明にはなりません。
• 公式の完了投稿より先にリセットが反映されることはありますが、reset_at からの逆算だけでは反映イベントの証拠になりません：匿名 rollout から分かるのは、時間帯の変化の範囲だけです。query_usage の reset_at - window_seconds は implied_window_start_at とだけ呼び、reset_landed_at と直接記述してはいけません。直接リセット、自然周期、banked の実行、または対象範囲と一致する公式エビデンスが別にある場合に限り、この逆算を、帰属が確認されたイベントの候補となる反映時刻として扱えます。完了投稿が確認するのは「遅くともこの時点までに処理済み」ということだけで、確認投稿の時刻を反映時刻として扱ってはいけません。 リセット反映から数分以内にアンカーが戻った場合、まずは同時進行中の session が古い値を返したものと解釈します――リセットの瞬間に 0%→100% + アンカーの巻き戻り が起きるパターンは、遅れている session がリセット前の古いウィンドウをまだ報告していることを示しており、アカウントが交錯している新たな証拠ではありません。まず反映の時間範囲とぴったり重なるか確認し、その後で §2／§3 に従って ID を調べる段階へ進めるか判断してください。時間範囲外の巻き戻りについては、引き続き §2 ⚠️ に従って、まず ID を確認してください。