코덱스 리셋 시각은
로그에 이미 적혀 있었습니다

30초 요약

정리하면 “몇 시에 풀리나”의 답은 내가 오늘 처음 코덱스에 말을 건 시각 + 5시간입니다. 남이 알려줄 수 있는 값이 아니고, 내 로그에만 있는 값입니다.

로그 어디에 적혀 있나

Codex CLI는 대화 하나당 rollout-<날짜>-<id>.jsonl 파일을 남깁니다. 경로는 ~/.codex/sessions/연/월/일/입니다. 이 파일 안에 token_count 이벤트가 있고, 거기 rate_limits가 통째로 붙어 옵니다.

레코드 한 건은 이런 모양입니다. 값은 제 것이라 지웠지만 구조는 그대로입니다.

창이 열리는 순간이 보입니다

2026년 9월 10일 하루치를 시간순으로 늘어놓으면 구조가 한눈에 들어옵니다. 시각은 모두 한국 시간입니다.

읽는 순서는 이렇습니다.

첫째, 08:44:12에 사용률이 0%입니다. 이때 리셋 예정은 13:44:02, 남은 시간은 299.8분. 거의 정확히 5시간입니다. 즉 아직 창이 열리지 않은 상태이고, 서버는 “지금 시작하면 5시간 뒤”를 알려주고 있습니다.

둘째, 다음 요청부터 리셋 시각이 13:44:11로 못 박힙니다. 사용률이 25 → 49 → 54 → 69 → 84%로 오르는 동안 이 값은 초 단위까지 그대로입니다. 창이 열렸고, 닫히는 시각이 확정된 것입니다.

셋째, 08:44에 열린 창은 13:44에 닫힙니다. 그리고 그 뒤 첫 요청인 14:12:38에서 사용률이 다시 0%가 되고, 새 리셋 시각 19:12가 잡힙니다. 14:12 + 5시간 = 19:12. 정확히 맞습니다.

한번 열리면 요청해도 안 밀립니다

가장 많이 받는 오해가 “계속 쓰면 리셋이 계속 미뤄지는 것 아니냐”입니다. 위 표가 그 답입니다. 08:47부터 09:07까지 다섯 번 요청하는 동안 리셋 시각은 13:44:11에서 1초도 움직이지 않았습니다.

다만 자세히 보면 13:44:02 → 13:44:11처럼 몇 초짜리 차이가 있습니다. 창이 열리지 않은 상태(0%)의 값과 실제로 열린 뒤의 값이 다르기 때문이고, 열린 뒤로는 13:44:11로 완전히 동일합니다. 두 번째 창도 19:12:29와 19:12:30 사이를 오가는데 이건 서버·클라이언트 시계의 1초 오차 수준입니다.

그래서 실무적으로는 이렇게 행동하면 됩니다.

마지막 줄을 강조하고 싶습니다. 08:44에 0%였던 게 09:07에 84%였습니다. 23분입니다. 5시간 창이라고 해서 5시간 동안 균등하게 쓸 수 있다는 뜻이 전혀 아닙니다. 창은 시간 단위이고 한도는 사용량 단위라, 대부분의 경우 시간보다 사용량이 먼저 바닥납니다.

주간 창도 같은 구조입니다

window_minutes가 10080인 레코드, 즉 7일 창도 같은 방식으로 동작합니다. 전환점만 추리면 이렇습니다.

0%인 줄은 전부 정확히 7.00일입니다. 창이 안 열린 상태라 “지금 + 7일”을 그대로 보여주는 것입니다. 반면 사용률 35%인 줄만 5.10일로 짧습니다. 역산하면 그 주간 창은 8월 31일 12시 23분에 열렸다는 뜻이 됩니다.

주간 창도 요일이 고정돼 있지 않다는 점이 중요합니다. 위 표에서 리셋 요일이 화요일, 수요일, 월요일로 제각각입니다. 주간 한도는 ‘매주 월요일’이 아니라 ‘그 주에 처음 쓴 시각’부터 7일입니다.

클로드와는 방식이 다릅니다

같은 날 클로드 쪽 기록도 꺼내 봤습니다. Claude Code는 한도에 걸린 429 응답을 ~/.claude/projects의 세션 로그에 남기고, 거기 resetsAt이 들어 있습니다.

가장 큰 차이는 “미리 볼 수 있느냐”입니다. 코덱스는 한도에 걸리지 않아도 매 요청마다 지금 몇 %인지가 파일에 쌓입니다. 사용량 추이를 스스로 그릴 수 있다는 뜻입니다. 클로드는 걸려야 남습니다. 대신 클로드는 /usage 화면에서 같은 정보를 보여줍니다.

리셋 시각의 성격도 다릅니다. 코덱스는 내가 시작한 시각을 초 단위로 그대로 반영하고, 클로드는 30분 경계로 정돈합니다. 클로드 기록 세 건 모두 1800초의 배수였고, 같은 날 13분 간격으로 두 번 걸렸을 때도 리셋 시각은 13:30:00으로 동일했습니다.

단서는 달아 둡니다. 클로드 쪽은 제 계정 3건이 전부라 항상 30분 경계라고 단정하기엔 표본이 작습니다. 코덱스 쪽은 8,905건이라 패턴이 확실합니다.

내 로그로 직접 확인하기

남의 수치를 믿을 필요가 없습니다. 아래 한 덩어리를 붙여 넣으면 자기 계정의 실제 창 이력이 나옵니다.

판단 순서는 이렇게 하면 됩니다.

자주 묻는 질문

코덱스 한도는 몇 시에 리셋되나요?
고정된 시각이 없습니다. 그 창의 첫 요청 시각 + 5시간입니다. 제 기록에서는 08:44 시작 → 13:44 리셋, 14:12 시작 → 19:12 리셋이었습니다. 자기 로그의 resets_at을 보는 게 유일하게 정확한 방법입니다.

계속 쓰면 리셋이 미뤄지나요?
아닙니다. 창이 열린 뒤에는 초 단위까지 고정입니다. 사용률이 0에서 84%까지 오르는 동안 리셋 시각은 13:44:11 그대로였습니다.

제 로그에는 secondary가 null입니다.
정상입니다. 제 데이터에도 두 창이 동시에 채워진 구간과 한쪽만 있는 구간이 섞여 있었습니다. 플랜과 시점에 따라 달라집니다.

5시간 창인데 왜 30분 만에 다 썼나요?
창 길이와 한도 크기는 별개입니다. 창은 “언제 초기화되는가”이고 한도는 “얼마나 쓸 수 있는가”입니다. 제 기록에서도 23분 만에 84%에 도달한 구간이 있습니다.

주간 한도는 월요일에 풀리나요?
아닙니다. 제 로그의 리셋 요일은 화·수·월로 제각각이었습니다. 그 주에 처음 쓴 시각부터 7일입니다.