이번 버전은 "멀쩡한 계정이 있는데 자동 전환이 안 되는" 문제를 잡았어요. 한도에 자주 부딪히며 여러 세션을 동시에 돌리는 분일수록 만나기 쉬운 종류라, 그렇게 쓰고 계시다면 업데이트를 권해요.
🔀 한도가 남은 계정을 "다 썼다"고 착각하던 문제
계정을 바꾸고 나면, 바꾸기 직전에 이미 시작돼 있던 요청이 뒤늦게 한도 에러를 남깁니다. 그 에러는 이전 계정 것인데, Mobius는 그때 활성이던 새 계정 것으로 기록했어요.
그래서 이런 일이 생겼습니다.
- 7일 사용량이 16%밖에 안 되는 계정에 주 계정의 리셋 시각이 덮어씌워지고
- 자동 전환은 그 계정을 "이미 다 쓴 계정"으로 보고 후보에서 빼고
- 갈 곳이 없어져 "모든 계정 한도 소진" 알림만 반복되고
- 그 상태가 가짜 리셋 시각이 만료될 때까지 몇 시간 이어졌어요
사용자 입장에선 "한도 남은 계정이 분명히 있는데 전환이 안 된다"로 보이는 증상이었습니다.
왜 시간으로 못 걸렀나 — 에러가 도착한 시각만 보면 전환보다 나중이라 구분할 수가 없어요. 제보해 주신 분이 각 에러에 대해 "그 요청이 시작된 시각"까지 되짚어 재 주셨는데, 요청이 실패로 끝나기까지 최대 2분 7초가 걸리고 있었습니다. 저희가 이런 경우를 막으려고 둔 대기 시간은 2분이었으니, 한 번의 요청도 못 덮고 있었던 거예요.
이제는 시간이 아니라 계정에 직접 물어봅니다. 세션 기록의 한도 에러는 "확인해 볼 이유"로만 쓰고, 진짜 소진 여부는 그 계정의 로그인 정보로 사용량을 조회해 판단합니다. 계정별로 따로 묻기 때문에 다른 계정 것과 섞일 수가 없어요.
덤으로 리셋 시각이 정확해졌습니다. 기록에 적힌 "9pm"을 해석하는 대신 실제 값(20:59:59)을 쓰거든요.
통신량은 평소와 똑같이 0이에요. 한도 에러가 실제로 났을 때만 한 번 확인하고, 같은 소진에 대한 이후 에러는 확인 없이 넘어갑니다.
🏷️ "이 모델만 막힘"과 "이 계정을 못 씀"을 구분해요
특정 모델의 주간 한도(예: Fable)에 걸린 것과 계정 자체를 다 쓴 것은 전혀 다른 상황인데, 지금까지 같은 것으로 다뤄 왔어요. 그래서 며칠짜리 모델 한도 하나 때문에 멀쩡한 계정이 폴백 후보에서 통째로 빠지곤 했습니다.
이제 둘을 나눠서 봅니다.
| 계정 한도 | 모델 한도 | |
|---|---|---|
| 뜻 | 이 계정으로 아무것도 못 함 | 그 모델만 못 씀 |
| 다른 계정으로 옮길 때 후보가 되나 | 안 됨 | 됨 |
| 메뉴바가 빨개지나 | 빨감 | 안 빨감 |
알림 문구와 계정 카드, mobius list 표시도 함께 나눴어요. 계정이 멀쩡한데 "계정 한도 소진"이라고 말하는 건 거짓말이니까요. 모델 한도 때문에 옮길 때는 "이 모델의 한도에 걸려 옮겼어요"라고 정확히 알려 드립니다.
⚠️ 모델 전용 한도가 실제로 100%까지 차는 상황은 아직 아무도 관측하지 못했습니다. 이 부분은 응답 형식을 보고 만든 대비책이라, 실제로 겪으시면 제보해 주시면 고맙겠습니다.
📖 문서를 정정했어요 — 세션 재시작, 안 하셔도 됩니다
README와 앱 알림이 이렇게 안내하고 있었어요.
이미 실행 중인 세션은 이전 계정을 계속 쓰므로, 새 계정을 적용하려면 세션을 새로 시작하세요.
사실이 아니었습니다. 실행 중인 claude 세션도 다음 입력부터 새 계정으로 이어집니다. 이전 계정이 쓰이는 건 전환하는 순간 이미 진행 중이던 답변 하나뿐이에요.
원래 측정한 것은 "전환해도 세션이 안 끊긴다"였는데, 그 옆에 "그러니 재시작이 필요하겠다"는 추측이 붙어 그대로 문서와 알림 문구로 퍼졌습니다. 필요 없는 재시작을 안내해 온 셈이라 죄송합니다. 문서·알림·CLI 안내를 모두 고쳤어요.
(Codex는 반대입니다 — 실행 중인 codex 세션은 종료해야 새 계정이 적용돼요. 두 안내를 따로 표시하도록 나눴습니다.)
이번 문제는 개발 환경에서는 사실상 발견이 불가능했어요. 한 달치 세션 기록을 전부 뒤졌는데 한도 소진 이벤트가 0건이었거든요. 여러 세션을 동시에 돌리며 주간 한도까지 쓰는 환경에서만 드러나는 종류입니다.
이 문제를 재현 로그와 함께 제보하고, 이후로도 라이브 응답 원문, 요청별 재시도 시간 측정, 그리고 저희가 후보로 보던 방법이 왜 막다른 길인지까지 세 차례에 걸쳐 실측으로 알려 주신 분은 @Phantomn 님이에요. 특히 "요청이 시작된 시각"을 되짚어 재 주신 측정은 저희가 볼 방법이 없던 각도였습니다. 덕분에 추측이 아니라 숫자를 근거로 고칠 수 있었어요 🙏
English — This release fixes "there's an account with headroom but auto-switch won't use it."
When you switch accounts, requests that were already in flight can log their rate-limit errors after the switch. Those errors belong to the old account, but Mobius recorded them against the newly active one — so an account at 16% weekly usage would inherit the primary's reset time, drop out of the fallback pool, and leave you with repeating "all accounts exhausted" notifications for hours.
Timestamps couldn't separate them: the error lands after the switch. The reporter traced each error back to when its request started and measured retries taking up to 2m07s — longer than our 2-minute guard, so it never covered even one request. Mobius now treats log errors as a reason to check and asks the account itself, querying usage with that account's own credentials, so answers can't be crossed. Reset times got more accurate as a side effect, and idle network traffic stays at zero — one check when a limit error actually occurs, none for follow-ups on the same exhaustion.
Also: model-specific limits (like Fable's weekly cap) are no longer treated as "account unusable." Such an account stays a valid fallback, the menu bar doesn't go red, and notifications say what actually happened. (Nobody has observed a model limit actually reaching 100% yet — this is built from the response shape, so please report it if you hit one.)
And a correction: you don't need to restart running claude sessions after switching. They pick up the new account with your next prompt; only the reply already in flight uses the old one. Our earlier docs said otherwise — that was a guess appended to a measurement, and it's fixed everywhere now. (Codex is the opposite: close running codex sessions for a switch to stick.)
This was effectively undiscoverable on our own machine — a full month of session logs contained zero window-exhaustion events. Reported and measured three times over by @Phantomn, including the request-start timing that we had no way to see 🙏
