Skip to content

fix(usage): let operator Kimi/Z.AI limits reach the Piri lane - #984

Merged
jinon86 merged 1 commit into
mainfrom
feat/piri-usage-service
Aug 6, 2026
Merged

fix(usage): let operator Kimi/Z.AI limits reach the Piri lane#984
jinon86 merged 1 commit into
mainfrom
feat/piri-usage-service

Conversation

@jinon86

@jinon86 jinon86 commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

문제

Piri 노드의 /usage는 운영자가 CCC_USAGE_KIMI_5H_REQUEST_LIMIT / CCC_USAGE_KIMI_WEEKLY_TOKEN_LIMIT을 설정해 두어도 항상 Rate limits: unavailable을 출력했습니다. 한도 값이 조용히 죽어 있었습니다.

원인은 서비스 식별입니다. 윈도우 합성(synthesize_service_windows)은 service로 키잉되는데, Claude 레인은 ANTHROPIC_BASE_URL 호스트에서 이를 유도하는 반면 Piri 스냅샷에는 service가 아예 없었습니다. Piri는 provider와 직접 통신하고, 백엔드는 per-node 런처의 --model 인자로 고정되는데 브리지는 그 값을 보지 못합니다.

실제 영향: 방통·순욱·등애 3대가 이 상태입니다(kimi-usage-limits.conf 배포됨, 소비되지 않음).

변경

CCC_USAGE_PIRI_SERVICE로 서비스를 명시합니다. 의도적으로 한도 env와 같은 drop-in에 둡니다 — 둘은 같은 사실을 주장하므로 함께 편집되고, 그래서 서로 어긋나지 않습니다. _SERVICE_WINDOW_SPECS에 이미 있는 이름만 받아들이므로 오타가 엉뚱한 한도를 선택할 수 없습니다.

렌더러는 수정하지 않았습니다. Rate limits: 블록이 Piri 텔레메트리 경계 early-return 에 있어서, 윈도우를 가진 스냅샷은 이미 정상 렌더됩니다 — "Piri는 provider 텔레메트리를 보고하지 않는다"는 경계 문구도 그대로 유지됩니다.

배선은 get_usage의 미터 기반 합성 블록을 _fill_local_service_windows로 추출해 Piri 런타임 분기에 적용했습니다. 그 분기는 이전까지 bare 스냅샷을 반환하며 미터를 통째로 버리고 있었습니다.

안전 경계

미설정/미인식 값은 Piri /usage 출력을 이전과 바이트 동일하게 유지합니다. 테스트로 고정했습니다:

  • test_local_piri_environment_snapshot_is_inert_when_unconfigured
  • test_get_usage_piri_lane_unconfigured_stays_bare
  • test_get_usage_non_piri_runtime_provider_unchanged (crush 등 다른 런타임 provider 무영향)

테스트

  • tests/test_usage.py 70 passed
  • 전체 브리지 스위트 2341 passed, 5 skipped (tests/test_skill_candidate_inventory.py 제외)
  • 제외한 파일은 origin/main 원본에서도 3건 실패하는 기존 환경 의존 실패(root 실행)이며 이 PR과 무관함을 pristine worktree로 확인했습니다

배포 메모

머지만으로는 아무 노드도 동작이 바뀌지 않습니다(플래그 미설정). 실제 적용은 Piri 노드 drop-in에 CCC_USAGE_PIRI_SERVICE를 런처와 일치시켜 넣는 별도 롤아웃이 필요합니다 — kimi-coding/*Kimi Code, zai/*Z.AI.

🤖 Generated with Claude Code

`/usage` on a Piri node always said "Rate limits: unavailable" even when the
operator had configured CCC_USAGE_KIMI_5H_REQUEST_LIMIT and
CCC_USAGE_KIMI_WEEKLY_TOKEN_LIMIT. The limits were silently dead: window
synthesis is keyed by `service`, the Claude lane derives that from the
ANTHROPIC_BASE_URL host, and the Piri snapshot carried no service at all —
Piri talks to its provider directly and its backend is pinned by the per-node
launcher's `--model` argument, which the bridge never sees.

Name the service explicitly via CCC_USAGE_PIRI_SERVICE, deliberately
co-located with the CCC_USAGE_*_LIMIT values it selects so the two are edited
together and cannot drift apart. Only names already in _SERVICE_WINDOW_SPECS
are accepted, so a typo cannot silently select the wrong quota limits.

The renderer needed no change: the "Rate limits:" block already runs before
the Piri telemetry-boundary early return, so a snapshot carrying windows
renders them while still stating that Piri reports no provider telemetry.

Wiring: extract the meter-backed window synthesis from get_usage into
_fill_local_service_windows and apply it to the Piri runtime branch, which
previously returned a bare snapshot and dropped the meter entirely.

Unset or unrecognized leaves Piri /usage byte-identical to before, pinned by
test_local_piri_environment_snapshot_is_inert_when_unconfigured and
test_get_usage_piri_lane_unconfigured_stays_bare. Other runtime-backed
providers are untouched (test_get_usage_non_piri_runtime_provider_unchanged).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@jinon86
jinon86 requested a review from seoseo-ai as a code owner August 6, 2026 07:43

@seoseo-ai seoseo-ai left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved after explicit operator authorization using the local seoseo-ai credential.

@jinon86
jinon86 merged commit ef706e3 into main Aug 6, 2026
8 checks passed
@jinon86
jinon86 deleted the feat/piri-usage-service branch August 6, 2026 07:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants