Skip to content

Proposal: Pin the re-initialization window of zero-usage Codex accounts with a one-shot shadow request #1977

Closed as not planned
Closed as not planned
Proposal: Pin the re-initialization window of zero-usage Codex accounts with a one-shot shadow request#1977
Labels
account-poolOAuth, credentials, Codex pool, quota, failover, plansenhancementNew feature or requestneeds-infoWaiting on reporter for a concrete spec or reproductionstaleNo activity on a needs-info issue; will close soon unless updated

Description

@dbc-hbin
dbc-hbin
opened on Aug 18, 2026

Area

Authentication and account pool

What are you trying to accomplish?

Keep every Codex account in the pool on a predictable, planable weekly re-initialization cycle. When the pool initializes an account, its next re-initialization should be init time + 1 week, regardless of how much or how little the account is used.

What prevents this today?

Trigger — Tibo resets Codex accounts on an event-driven basis. The account reset/onboarding happens outside OpenCodex, event by event. After Tibo performs a reset, the backend does not anchor the next re-initialization to the reset event (reset time + 1 week). Instead, it anchors to the account's first usage after the reset (first use + 1 week).

Consequence: an account that is reset but never used has no active clock; the 1-week countdown only starts when rotation finally selects it. Under any rotation strategy (round-robin, fill-first, quota) a zero-usage account therefore re-initializes at first real use + 1 week — an unpredictable point that drifts out of sync with the pool's planned lifecycle.

What should OpenCodex do?

  • Track per-account usage.
  • For any account that has been initialized/reset but shows zero usage, send exactly one short shadow request to pin its initialization point:
    • cheap model (e.g. Luna low),
    • minimal prompt / low token cost,
    • short timeout,
    • one-shot — never repeated per sweep.
  • Fire it shortly after the account is initialized (or at the next idle sweep), so first use ≈ init time and every account's weekly window becomes init + 1 week.

Example usage or interface

No new user-facing interface is required; the behavior applies pool-wide. Example timeline with the feature:

t0      account added + initialized (zero usage)
t0 + 1m one shadow request (Luna low, trivial prompt) -> first use pinned ~ t0
t0 + 7d re-initialization due (previously drifted to first real use + 7d)

Alternatives or workarounds

  • Manually warm each new account with a throwaway request once — error-prone and easy to forget.
  • Track last-use timestamps in a periodic sweep and reschedule re-initialization from them — more complex, and the anchor still sits at first use.
  • Do nothing: re-initialization timing stays unpredictable for idle accounts.

Additional context

Checks

  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.

Activity

  1. github-actions
    added
    enhancementNew feature or request
    account-poolOAuth, credentials, Codex pool, quota, failover, plans
    on Aug 18, 2026
  2. dbc-hbin
    changed the title [-]Pin the re-initialization window of zero-usage Codex accounts with a one-shot shadow request[/-] [+]Proposal: Pin the re-initialization window of zero-usage Codex accounts with a one-shot shadow request[/+] on Aug 18, 2026

  3. Ingwannu commented on Aug 18, 2026

    @Ingwannu
    Ingwannu
    on Aug 18, 2026
    Owner

    I would not accept this as an implicit pool-wide behavior. A shadow inference is a hidden authenticated and potentially billed request that consumes user quota, and OpenCodex cannot safely infer that it anchors a provider reset window without a verified provider contract.

    A reviewable proposal would need all of the following before implementation:

    • explicit default-off operator consent, with the model/provider/cost effect documented;
    • evidence that one successful inference actually anchors the reset window for this account type;
    • a durable per-account idempotency key tied to a verified reset/onboarding generation, not merely usage == 0;
    • no retry loop after timeout/failure and no request while the account is unhealthy, rate-limited, or already carrying user traffic;
    • cancellation, usage accounting, and an audit-visible result that never logs credentials or prompt bodies.

    Please provide the reset-event/first-use evidence and confirm the explicit opt-in contract. Marking needs-info; this will not become an invisible default warmup.

  4. Ingwannu
    added
    needs-infoWaiting on reporter for a concrete spec or reproduction
    on Aug 18, 2026

  5. dbc-hbin commented on Aug 18, 2026

    @dbc-hbin
    dbc-hbin
    on Aug 18, 2026
    ContributorAuthor

    Community evidence (Chinese communities)

    The "first-use anchored window" mechanic is independently documented in the Chinese Codex community; users already do exactly the proposed trick manually.

    1. sinovale.com — "用自动唤醒对齐 Codex 额度窗口的一个小技巧" (2026-07-19) https://blog.sinovale.com/7380.html

      • "如果额度窗口是按'首次使用后开始计算，每 5 小时一轮'这样的规则运行，那么每天什么时候第一次唤醒 Codex，会影响后面几个额度窗口落在什么时间段"
      • The author deliberately sends one trivial, minimal-prompt request ("唤醒提示词也应该尽量短，只要能让当前对话保持一次轻量活动即可") at 02:30 to pin the first window start and stop the windows drifting — i.e. a manual one-shot shadow request.

    2. php.cn FAQ — "Win/Mac版Codex额度重置规则" https://www.php.cn/faq/2639649.html

      • "5小时窗口的起点和终点全由你按发送键" (the 5h window start/end is entirely determined by your send button) — usage anchors the window, not a fixed schedule.

    3. codex-reset.com — 蒂博雷达 (independent Tibo reset tracker) https://codex-reset.com/zh/

      • Tracks Thibault Sottiaux's (@thsottiaux) event-driven global resets: "35 次已验证重置", "近期节奏 ≈ 每 2 天", "最长等待 73 天" — resets are irregular/event-driven, which is exactly why zero-usage accounts drift out of sync.

    4. ifanr (爱范儿) — "掌管 Codex 额度的「赛博义父」" (2026-07-16) https://www.ifanr.com/1672101

      • OpenAI resets were announced per milestone ("每增加一百万用户就再重置一次"), i.e. event-triggered rather than a fixed per-account schedule.

    Note: community sources document the usage-anchored window explicitly for the 5-hour rolling window. The weekly (1-week) window anchoring to first use is the empirical behavior behind this proposal.

  6. dbc-hbin commented on Aug 18, 2026

    @dbc-hbin
    dbc-hbin
    on Aug 18, 2026
    ContributorAuthor

    If the automatic shadow request is a concern (extra token usage / unexpected traffic), this could be implemented as an opt-in option with an explicit warning — e.g. a pool config flag disabled by default that, when enabled, sends one minimal Luna low request per zero-usage account to pin the first-use window.

    Users who don't want the extra request can leave it off, so there's no change to existing behavior unless explicitly enabled. Would that be acceptable?

  7. dbc-hbin commented on Aug 18, 2026

    @dbc-hbin
    dbc-hbin
    on Aug 18, 2026
    ContributorAuthor

    Evidence from linux.do:

    https://linux.do/t/topic/2223729 — 5h window and weekly limit:

    5h is first request anchored or fixed time? Weekly limit is calendar week (Mon reset) or rolling 7 days?
    Accepted answer (marked 解决):
    5H starts when payment succeeds, weekly is rolling 7 days, but backend resets exist, after a reset both 5H and weekly recalculate from the reset time.

    https://linux.do/t/topic/2373599 — 5h overrun charged to weekly:

    After 5h window is exhausted, continued usage is charged directly to weekly quota. I observed 5h exhaustion costs about 15% of weekly.

  8. lidge-jun commented on Aug 19, 2026

    @lidge-jun
    lidge-jun
    on Aug 19, 2026
    Owner

    리뷰 · 우선순위 20 / 80

    풀에 넣은 Codex 계정의 주간 재초기화 시각을 init + 1주로 고정하고 싶다. 지금 백엔드는 리셋이 아니라 리셋 후 첫 사용에 시계를 건다. 안 쓴 계정은 시계가 없고, 로테이션이 고른 뒤에야 한 주가 시작된다. 옵트인 풀 수명 제안이고 needs-info라 20이다. 기본 native 경로를 깨지 않는다.

    OpenCodex는 Tibo 리셋 시계를 소유하지 않는다. 할 수 있는 건 “첫 사용”을 우리가 찍는 것이다. 제안은 사용 0인 계정에 짧은 섀도 요청을 한 번 보내는 것이다. 싼 모델, 짧은 타임아웃, 스윕당 한 번, 실패해도 무한 재시도 없음.

    src/codex/warmup.ts의 warmCodexAccount()가 그 골격이다. https://chatgpt.com/backend-api/codex/responses로 워밍업하고 기본 모델은 gpt-5.4-mini다. Luna low를 기본으로 바꾸라는 말은 이 파일과 맞지 않는다. 기존 워밍업을 재사용할 때는 모델/프롬프트를 새로 짓지 말고 이 함수 옵션(model, timeoutMs)만 본다.

    자동으로 사용자 계정에 요청을 보내는 기능이다. 토큰과 쿼터를 쓴다. 풀/config 플래그 기본 off가 맞다. 프롬프트·토큰·계정 id를 로그에 남기면 안 된다. 시도 여부만 계정 상태에 남긴다. 워밍업 실패를 자격 만료로 바꾸면 #2046과 같은 재로그인 루프가 난다.

    첫 사용 앵커가 정말 업스트림 동작인지는 이 이슈만으로 닫히지 않는다. Tibo 리셋 직후 WHAM/사용 창이 언제 시작하는지 한 계정 증거가 더 필요하다. 그 전에는 섀도 요청이 시계를 고정한다고 단정하지 않는다.

    해결방안

    기본은 끄고, warmCodexAccount()를 계정 추가/리셋 직후 한 번만 부르는 옵트인이다. 시도 플래그를 남겨 실패해도 루프하지 않는다. 모델은 이 파일의 기본/FALLBACK_MODELS를 쓰고 Luna를 새로 하드코딩하지 않는다. 프롬프트 내용은 워밍업이 이미 쓰는 최소 바디를 재사용한다. 업스트림이 첫 사용이 아니라 리셋에 시계를 거는 증거가 나오면 이 기능은 필요 없다. 그 증거 없이 새 스윕 스케줄러를 만들지는 않는다. 패치는 추측하지 않음.

    이 댓글은 grok-bot이 작성했습니다

  9. lidge-jun commented on Aug 19, 2026

    @lidge-jun
    lidge-jun
    on Aug 19, 2026
    Owner

    리뷰 · 우선순위 44 / 80

    점수 정정임. 처음 20은 "지금 계획 아님 + 섀도 요청이 사용량 조작처럼 보임"만 보고 내린 거였음. 풀 수명주기 문제는 실재함. Tibo가 첫 사용 기준으로 주간 창을 걸면, 넣어놓고 안 고른 계정은 시계가 안 돔. 로테이션이 나중에 집는 순간부터 7일이라 풀 전체 리셋 스케줄이 어긋남.

    우회는 이미 있음. 계정 넣을 때 사람 손으로 한 번 워밍업하면 됨. src/codex/warmup.ts가 그 자리임. 그래서 지금 머지 열차에 끼울 일은 아님. 다만 "수동으로 하면 됨"이 운영 실수에 열려 있어서 20짜리 아이디어 폐기랑은 다름.

    제안 자체는 아직 needs-info임. 원샷 가드, 실패 시 재시도 금지, 풀 플래그, 실패를 attempted로 남기는 계약이 이슈에만 있고 코드로 고정된 건 아님. 공식으로 Tibo가 init 시각 기준 리셋을 열어주는지도 이 저장소만으로는 모름. 그 전엔 섀도 요청을 기본 on으로 넣지 않는 편이 맞음.

    해결방안: 이슈는 열어두고, 구현은 워밍업 경로를 재사용하되 기본 off + 계정당 1회 + 실패해도 루프 금지로 가드가 문서화되면 그때 봄. 지금은 패치 안 넣음.

    이 댓글은 grok-bot이 작성했습니다

  10. github-actions commented on Sep 3, 2026

    @github-actions
    github-actionsbot
    on Sep 3, 2026 – with GitHub Actions
    Contributor

    This issue has the needs-info label and has had no activity for 14 days.

    It will be closed in 7 days if there is still no reply with the requested details (reproduction steps, logs, or a concrete spec). A comment or edit resets this timer. Maintainers can remove needs-info once the report is actionable — for example when promoting it to roadmap.

  11. github-actions
    added
    staleNo activity on a needs-info issue; will close soon unless updated
    on Sep 3, 2026

  12. lidge-jun commented on Sep 3, 2026

    @lidge-jun
    lidge-jun
    on Sep 3, 2026
    Owner

    Closing in favor of #3375, which carries the remaining scope forward.

    Thank you @dbc-hbin — this report on pinning the re-initialization window of zero-usage Codex accounts was accurate, and part of it shipped.

    What landed. src/codex/warmup.ts provides the manual warmup primitive your proposal depends on.

    What is still missing. durable one-shot scheduling of the shadow request, which is what would actually pin the window.

    Rather than leave four issues open each describing one facet of the same unfinished lifecycle, the surviving scope is consolidated in #3375, which names this issue and credits you for the original analysis. Please follow and comment there; if you think the consolidation dropped something you asked for, say so on #3375 and it will be added.

  13. lidge-jun
    closed this as not plannedon Sep 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    account-poolOAuth, credentials, Codex pool, quota, failover, plansenhancementNew feature or requestneeds-infoWaiting on reporter for a concrete spec or reproductionstaleNo activity on a needs-info issue; will close soon unless updated

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions