I am involved in building Is It Reset Yet?, an independent, unofficial public-reset records site. It is not affiliated with OpenAI, Anthropic or xAI. The design problem I want feedback on is how to show a public event without implying that the reader’s account has recovered.
I separate an announcement, its stated scope and the user’s own account state. A source link lets readers examine what was said. Missing scope or timing must remain unknown. A public record cannot validate a personal allowance, and a historical interval is not an official schedule.
You can inspect the Codex records here. The public catalog currently uses whenreset.dev as an upstream directory with original-post links; it is not an independent official feed. For private usage, follow OpenAI’s account guidance.
Does that separation make the page’s purpose clear? I am looking for feedback on event labeling and scope, not individual billing cases or account details. Please do not share credentials or private logs. The site has public-event notification options, but a notification is not evidence of account recovery or a promise of immediate delivery.
Oct 2 follow-up from the site maintainer: the upstream public directory now has a source-linked Codex usage-reset record timestamped 2026-10-02 21:18 UTC. The entry’s applicable plan and account scope remains unknown. Reports of different balances make the distinction concrete: a public record cannot confirm that any one account has recovered.
Would a more prominent ‘check your own Usage page’ notice alongside the event help, or is the current unknown-scope label clear enough? No private account details needed.
I checked the current Structured Outputs documentation, and I don’t see a documented $ref depth limit. Definitions are explicitly supported, and the docs even show recursive schemas using $ref, so a hard failure specifically at a 3-level reference chain would be surprising as an intended limitation.
Since the same schema works when you inline the intermediate definition, your workaround also points more toward schema-reference resolution/validation than an unsupported JSON Schema keyword.
For now, flattening/inlining the intermediate refs seems like the safest workaround. I’d keep the failing request ID and, if possible, add a minimal A → B → C reproduction to the post—it would make this especially easy to verify as a validator regression.