# Session: 2026-04-09 23:27:41 UTC

- **Session Key**: agent:main:telegram:direct:8308098400
- **Session ID**: 887ed8f9-2a97-4012-99ec-7a62a6098903
- **Source**: telegram

## Conversation Summary

user: Conversation info (untrusted metadata):
```json
{
  "message_id": "2083",
  "sender_id": "8308098400",
  "sender": "석호 이",
  "timestamp": "Fri 2026-04-10 08:14 GMT+9"
}
```

Sender (untrusted metadata):
```json
{
  "label": "석호 이 (8308098400)",
  "id": "8308098400",
  "name": "석호 이"
}
```

아 그럼 토큰 제한에 걸리면 5시간 쿨다운인거야?
assistant: [[reply_to_current]] **항상 그런 건 아니고, “어떤 종류의 제한이냐”에 따라 달라.**

### 짧게 정리
- **진짜 billing/credit/token exhausted 계열**이면  
  → 네 설정상 **기본 5시간 backoff**로 볼 가능성이 큼
- **일반 rate limit / concurrency / 잠깐 과부하**면  
  → 보통 그 5시간 bucket이 아니라 **짧은 cooldown + profile rotation** 쪽으로 갈 가능성이 큼
- **auth 문제**면  
  → 이번처럼 또 다른 auth cooldown path로 처리될 수 있음

### 왜 이렇게 보냐면
문서상 `5시간`은 정확히:
- `billingBackoffHours: 5`
- 설명도 **billing / insufficient credit** 계열용이야

반면 문서에 따로 나와 있는 것:
- `rateLimitedProfileRotations`
- `overloadedProfileRotations`
- `authPermanentBackoffMinutes`

즉 OpenClaw는 실패를 한 덩어리로 안 보고,
- billing
- rate_limit
- overloaded
- auth
같이 **종류별로 다른 bucket**으로 처리해.

### 그래서 네 질문에 대한 답
**“토큰 제한에 걸리면 무조건 5시간이냐?” → 아니, 제한의 성격에 따라 달라.**

만약 네가 말한 “토큰 제한”이
- **크레딧 소진 / 결제 한도 / 진짜 quota exhausted** 쪽이면  
  → 5시간 가능성 높음

근데 그게
- **짧은 시간당 요청수 제한**
- **동시성 제한**
- **일시적 API rate limit**
이면  
  → 5시간이 아니라 더 짧은 cooldown일 수 있어.

### 실무적으로 보면
`choonarm3`가 실제로 한도에 걸렸을 때
로그에 찍히는 reason이
- `billing`
인지
- `rate_limit`
인지
를 보면 바로 알 수 있어.

원하면 내가 다음으로
**실제 로그에서 어떤 문구가 뜨면 5시간 bucket으로 들어가는지**
문서/코드 기준으로 더 정확히 확인해줄게.
user: Conversation info (untrusted metadata):
```json
{
  "message_id": "2085",
  "sender_id": "8308098400",
  "sender": "석호 이",
  "timestamp": "Fri 2026-04-10 08:15 GMT+9"
}
```

Sender (untrusted metadata):
```json
{
  "label": "석호 이 (8308098400)",
  "id": "8308098400",
  "name": "석호 이"
}
```

그럼 쿨다운 끝났는데도 다시 choonarm3로 전환되지 않는 이유는 뭐야?
assistant: [[reply_to_current]] 가장 가능성 큰 건 **OpenClaw가 cooldown이 끝났다고 해서 즉시 “원래 1순위로 되돌아가는” 방식은 아니기 때문**이야.

### 지금 상태를 해석하면
- `choonarm3`의 cooldown은 끝남
- 근데 직전 성공 프로필이 `choonarm5`
- `lastGood`도 아직 `choonarm5`

즉 내부적으로는
- **“지금 잘 되는 프로필 계속 쓰기”**
쪽 성향이 있는 거야.

### 왜 그럴 수 있냐
보통 이런 이유들이 있어:

1. **lastGood stickiness**
   - 최근 성공한 프로필을 우선 재사용
   - 괜히 다시 1순위로 바꿨다가 실패하는 걸 피하려는 동작

2. **cooldown 종료 ≠ 즉시 선호도 리셋**
   - cooldown이 끝나면 “다시 후보에 들어올 수 있음”일 뿐
   - “무조건 다음 요청에서 1순위 복귀”는 아닐 수 있음

3. **세션 단위로 현재 붙은 auth profile 유지**
   - `/status`는 그 세션이 최근에 실제로 붙은 프로필을 보여줄 수 있음
   - 그래서 새 요청 몇 번 없이 바로 안 바뀔 수 있음

### 핵심
즉 지금은
- `choonarm3`가 **막혀 있어서 못 쓰는 상태는 아니고**
- OpenClaw가 **이미 잘 붙은 `choonarm5`를 계속 유지하는 쪽**으로 보이는 거야

### 한 줄로 말하면
**쿨다운이 끝나도 자동으로 원복되는 게 아니라, 최근 성공한 프로필(choonarm5)을 계속 쓰는 sticky 동작 때문일 가능성이 가장 커.**

원하면 내가 다음으로
- auth-state/로그 기준으로
- **강제로 choonarm3를 다시 lastGood으로 만들 수 있는지**
안전한 방법까지 확인해볼게.
user: Conversation info (untrusted metadata):
```json
{
  "message_id": "2087",
  "sender_id": "8308098400",
  "sender": "석호 이",
  "timestamp": "Fri 2026-04-10 08:23 GMT+9"
}
```

Sender (untrusted metadata):
```json
{
  "label": "석호 이 (8308098400)",
  "id": "8308098400",
  "name": "석호 이"
}
```

다음과 같은 결론이네. 이 내용도 노션 투두 codex 계정 2개 항목에 추가해줘.

자동으로 다시 `choonarm3`로 돌아가지 않는 이유는, 그 **30초 쿨다운이 “다음 요청부터 다시 3번을 우선 사용하라”는 뜻이 아니라, 그 프로필을 잠시 후보에서 제외하는 시간표시**에 가깝기 때문입니다. OpenClaw의 failover는 기본적으로 **세션에 선택된 auth profile을 고정해서 재사용**하는 쪽으로 동작합니다. 문서에 따르면 OpenClaw는 캐시 효율 때문에 세션별로 선택된 auth profile을 pin하고, 그 pinned profile은 실패 시 다른 프로필로 회전할 수 있지만, 성공적으로 다른 프로필로 옮겨간 뒤에는 그 새 프로필이 계속 우선 사용됩니다. ([OpenClaw][1])

조금 더 정확히 말하면, OpenClaw는 auth profile 선택에서 next, lastGood, 세션의 현재 override/pin을 함께 봅니다. 그런데 **직전 성공 프로필이 `choonarm5`이고 `lastGood`도 `choonarm5`**라면, 30초가 지나도 라우터 입장에서는 “현재 잘 되는 프로필이 5번”이므로 굳이 3번으로 되돌릴 이유가 없습니다. 문서의 “Session stickiness (cache-friendly)” 설명도 이 점을 분명히 말합니다. 한 번 선택된 프로필은 매 요청마다 round-robin으로 바꾸지 않고, 세션 reset이나 특정 상태 변화가 있을 때까지 재사용합니다. ([OpenClaw][1])

즉 지금 관찰하신 현상은 대체로 이렇게 해석하면 됩니다.

* `choonarm3`가 실패해서 30초 cooldown에 들어감.
* 같은 요청 흐름 또는 직후 요청에서 `choonarm5`로 failover 성공.
* 성공 결과가 저장되면서 세션 선호와 `lastGood`가 `choonarm5` 쪽으로 굳어짐.
* 30초가 지나 `choonarm3`의 cooldown이 끝나도, “다시 probe해서 원래 계정으로 복귀”하는 로직은 기본 동작이 아님.
* 그래서 이후 요청도 계속 `choonarm5`를 사용. ([OpenClaw][1])

문서상 cooldown 관련 동작도 “쿨다운 종료 후 자동 복귀”보다는 **skip vs probe behavior**로 설명됩니다. 즉 cooldown은 “현재는 쓰지 마라”는 제한이지, “끝나면 즉시 다시 주 프로필로 승격해라”가 아닙니다. 또 fallback retry는 실패한 provider/profile을 피해 다음 후보를 시도하고, 성공한 fallback 후보를 세션 model/auth override로 저장해 다른 세션 리더도 같은 선택을 보게 합니다. 이 설계 자체가 “성공한 쪽에 머무르는” 방향입니다. ([OpenClaw][1])

당신이 적어준 상태인 **“직전 성공 프로필이 choonarm5, lastGood도 choonarm5”**는 바로 그 증거입니다. 이 상태에서는 3번 cooldown이 풀려도 5번이 여전히 정상 후보이자 최근 성공 후보라서, 자동 복귀가 아니라 **현재 good state 유지**가 우선됩니다. ([OpenClaw][1])

비슷한 이슈들도 이 해석을 뒷받침합니다. OpenClaw 이슈에서는 `lastGood`가 실패한/혹은 최근 성공한 프로필에 계속 남아 있으면, 사용자가 기대하는 “다음에 다른 프로필로 자연 복귀”가 안 되거나 특정 프로필이 계속 선택되는 사례가 보고되었습니다. 특히 `lastGood`와 세션 override 상태가 강하게 작용해, 단순 cooldown 만료만으로는 선택 우선순위가 다시 뒤집히지 않는다는 점이 반복해서 드러납니다. ([GitHub][2])

결론만 정리하면 이렇습니다.

30초 cooldown은 “choonarm3를 30초 동안 제외”하는 의미이고, “30초 뒤 자동으로 choonarm3로 복귀”하는 의미가 아닙니다.
그리고 현재는 세션 stickiness + lastGood=choonarm5 때문에 OpenClaw가 choonarm5를 계속 정상 우선 후보로 쓰는 것입니다. ([OpenClaw][1])

다시 `choonarm3`를 우선 쓰게 하려면 보통 이런 경우가 필요합니다.

* 세션을 새로 시작해서 pin/override를 초기화
* 수동으로 profile/model을 다시 선택
* `choonarm5`가 실패해서 3번이 다시 더 나은 후보가 됨

즉, **쿨다운 해제만으로는 우선권 복구가 자동으로 일어나지 않는다**고 보는 게 맞습니다.

[1]: https://docs.openclaw.ai/concepts/model-failover?utm_source=chatgpt.com "Model Failover"
[2]: https://github.com/openclaw/openclaw/issues/31306?utm_source=chatgpt.com "Auth profile fallback doesn't trigger on OAuth 403 ..."

현재 세션 안에서는 `choonarm5`가 이미 성공했고, OpenClaw는 세션별 auth profile을 **고정해서 재사용**하는 성향이 있기 때문에, `choonarm3`의 cooldown이 풀려도 **같은 세션이 자동으로 다시 3번으로 “되돌아가진” 않습니다. 공식 문서도 선택된 프로필은 세션 reset, compaction, 또는 그 프로필이 cooldown/disabled가 될 때까지 재사용된다고 설명합니다. ([OpenClaw][1])

그래서 같은 세션을 계속 쓰는 한, `choonarm3`로 자연 복귀하려면 보통 두 경우뿐입니다.

* `choonarm5`도 문제를 일으켜서 다시 다른 후보를 보게 되는 경우. ([OpenClaw][1])
* 사용자가 **새 세션(`/new`, `/reset`)**을 시작해서 profile 선택을 다시 하게 만드는 경우. 문서상 새 세션에서는 cooldown이 끝난 primary 프로필이 다시 후보 상단으로 돌아올 수 있습니다. ([OpenClaw][1])

즉 질문에 아주 정확히 답하면,
**“같은 세션에서 자동으로”**라는 조건이면 choonarm5 쪽 문제가 생겨야 다시 바뀔 가능성이 크고,
“전체적으로 다시 choonarm3를 쓰게” 하려면 꼭 5번이 고장나야만 하는 건 아니고 세션을 새로 열면 됩니다. ([OpenClaw][1])


[1]: https://docs.openclaw.ai/concepts/model-failover?utm_source=chatgpt.com "Model Failover"
assistant: 좋아, 저 결론 그대로 Todo 본문에 추가해둘게.
assistant: 추가 스크립트가 quoting 때문에 한번 꼬였어. 바로 고쳐서 1번만 다시 넣을게.
assistant: [[reply_to_current]] 추가해뒀어.

- 대상 Todo: **OpenClaw에서 GPT 계정 2개 연동 및 openai-codex 폴백 구성**
- 새 섹션 제목:
  - **세션 stickiness / cooldown 해석 메모 (2026-04-10)**

네가 정리한 핵심 결론,
- cooldown은 “잠깐 제외” 의미
- 자동 원복은 기본 동작이 아님
- 세션 stickiness + `lastGood=choonarm5` 때문에 계속 5번이 쓰일 수 있음
- 자연 복귀엔 새 세션이나 후보 상태 변화가 필요함

이 내용까지 다 붙여놨어.
user: Conversation info (untrusted metadata):
```json
{
  "message_id": "2091",
  "sender_id": "8308098400",
  "sender": "석호 이",
  "timestamp": "Fri 2026-04-10 08:25 GMT+9"
}
```

Sender (untrusted metadata):
```json
{
  "label": "석호 이 (8308098400)",
  "id": "8308098400",
  "name": "석호 이"
}
```

노션 접근시 계속 문제가 생겨?
assistant: [[reply_to_current]] 아니, **지금은 Notion 접근 자체는 정상**이야.

내가 방금까지 한 작업들,
- Todo 조회
- 본문 append
- 상태 변경 (`보류 → 진행 중 → 완료`)
전부 실제로 성공했어.

아까 잠깐 있었던 건 **Notion 권한/연결 문제라기보다 내가 요청 payload 만들 때 쉘 quoting이 한번 꼬인 것**뿐이야.  
즉 문제 구분하면:

- **Notion API/토큰/권한**: 지금 정상
- **내 호출 스크립트 한 번 실수**: 있었음, 바로 고쳐서 성공

예전에 기록된 Notion 문제도 대부분
- 특정 페이지가 integration에 공유 안 됐을 때의 **page-level permission 문제**
였고,
토큰 자체가 죽은 건 아니었어. Source: `memory/2026-02-24.md#L48-L56`

한 줄로 말하면, **지금 Notion 접근은 멀쩡하고, 방금까지도 잘 썼어.**
user: Conversation info (untrusted metadata):
```json
{
  "message_id": "2093",
  "sender_id": "8308098400",
  "sender": "석호 이",
  "timestamp": "Fri 2026-04-10 08:27 GMT+9"
}
```

Sender (untrusted metadata):
```json
{
  "label": "석호 이 (8308098400)",
  "id": "8308098400",
  "name": "석호 이"
}
```

그럼 여기까지 데일리 요약 크론 한번 돌려줘. 새세션을 열거야
assistant: 좋아, 여기까지 한 번 요약 크론 돌려둘게. 그다음 새 세션 열면 깔끔하게 이어질 거야.
assistant: 실행 넣었어. enqueue 결과만 확인하고 마무리할게.
assistant: [[reply_to_current]] 돌려뒀어.

- cron: `Daily memory auto-summary`
- result: **enqueued 성공**
- runId: `manual:6ef3619b-e82b-4c0c-b39c-7973eaf01422:1775777244743:1`

이제 새 세션 열면 돼.
user: System (untrusted): [2026-04-10 08:27:24 GMT+9] Exec completed (vivid-ti, code 0) :: { "ok": true, "enqueued": true, "runId": "manual:6ef3619b-e82b-4c0c-b39c-7973eaf01422:1775777244743:1" }

Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.
When reading HEARTBEAT.md, use workspace file /home/lagoon3/.openclaw/workspace/HEARTBEAT.md (exact case). Do not read docs/heartbeat.md.
Current time: Friday, April 10th, 2026 - 8:27 AM (Asia/Seoul) / 2026-04-09 23:27 UTC