AIHOT — List Tibo Codex reset and reset-credit events

Current full public calendar snapshot, sorted by updatedAt descending. Includes explicit announcements and confirmed direct resets or reset-credit grants, Chinese source quotes and original links. No query parameters. Replace your previous snapshot; event grouping and receipts may be corrected, withdrawn events disappear. Timestamps use +08:00 (Asia/Shanghai). confirmedAt is the confirmation post time, not an exact execution time; occurredOn is a separately verified date or null. schedule remains the original estimate even after confirmation. Unknown times remain null. No account quota or predictions. Collection runs every 10 minutes; checkedAt is the last successfully verified scan, not request time. For polling use /api/v1/codex-resets/recent, which has the same shape and is a few KB instead of the whole history; poll it every 10 minutes using If-None-Match and Accept-Encoding: gzip or br. The Link header advertises that polling alternative. This endpoint keeps every event, but full texts, thread context and activities only for posts of the last 30 Beijing days; older posts keep their excerpt and link. Each client may read it once every 10 minutes (the collection cadence); reading more often answers 429 with Retry-After, and the response is private to the client.

Read https://openany.si/SKILL.md, then use AIHOT — List Tibo Codex reset and reset-credit events through openany
Selected price
$0 / callPublished pricing
Providers / implementations
1 / 1
Requests · 30d
—Loading...
Success rate · 30d
—Loading...
ProviderPrice / callRequests · 30dPerformanceAccess
aihotCurrent
AIHOT — List Tibo Codex reset and reset-credit events · GET
$0 / call—
—successP50—
Loading...

Statistics use persisted gateway logs from the last 30 days up to now, including today.
Success rate = successful requests / all requests;
P50 = median latency of successful requests.
Prices reflect the published API contract. Contract revision: 2. Price update time: not supplied.

Loading related APIs…

Common questions

Do I need a separate key for every provider?

Use your OpenAny API key for standard API access. Read it from OPENANY_API_KEY in your environment and keep it out of prompts, source code and logs.

Are these providers interchangeable?

No. Each offering has its own inputs, pricing and response contract. Selecting a catalog offering does not establish automatic routing or fallback. Confirm the service contract before calling.

How is this API billed?

API-key calls use your shared balance at the selected implementation's published rate. Check the billing unit and request-specific pricing rules before making a paid call. Recorded usage determines the final charge under that contract.

Where do the price and contract come from?

The selected implementation publishes its provider, request contract, revision and billing rules through OpenAny's public API catalog. A revision number identifies a contract version, not a price update date. A price update timestamp is not supplied; do not treat a page date as one.

How do OpenAny Balance and x402 differ?

OpenAny Balance uses an API key and one shared balance. Card, USDC and x402 top-ups, card auto top-up and USDC subscriptions fund that balance; available routes appear on the Credits page. Direct x402 is a separate pay-per-request flow, available only on listings that show it and requiring an authorized payment client.

Does Playground send a paid request?

Yes. After you sign in, Run sends a real API request using an active OpenAny API key. Charges follow the published API contract and use your shared balance. Selecting an implementation, editing inputs and viewing sample responses do not send requests.