feat(zai): adopt tier framework for plan-aware rate limiting

[Societus]

Summary

Wire Z.AI provider into the generic tier framework from #82. Adds plan-aware rate limiting based on Z.AI subscription tier (Lite/Pro/Max) with environment variable configuration.

Depends on: #82 (generic tier framework -- merge that first)

Changes

Z.AI Provider (zai.py)

• Define RATE_LIMIT_TIERS with Lite/Pro/Max configs derived from Z.AI support guidance (April 2026)
• Use resolve_rate_limiter() from BaseProvider in constructor
• Add tier parameter to constructor and docstring
• Bump retry budget: 5 retries / 30s max wait (from 3/4s) for Z.AI load-shedding tolerance

Rate Limiter (rate_limiter.py)

• Update PROVIDER_DEFAULTS["zai"] to conservative Lite-tier default (10 RPM / 50K TPM)
• Add ZAI_TIER_DEFAULTS dict for reference and documentation

CLI Helpers (helpers.py)

• Add ZAI_TIER env var reading in both explicit and auto-detect provider resolution paths

Tests (test_zai_provider.py)

• 13 new tests: tier creation, per-tier limits (lite/pro/max), case-insensitive matching, tier precedence over explicit limiter, invalid tier error, no-tier edge case, explicit limiter without tier, tier stored, and cross-provider empty tiers check

Rate Limit Context

Z.AI support provided the following guidance (April 2026):

• Lite: 2-3 concurrent, lower tolerance -> 10 RPM / 50K TPM
• Pro: 5-8 concurrent, moderate tolerance -> 30 RPM / 150K TPM
• Max: 10-15 concurrent, highest tolerance -> 60 RPM / 300K TPM

Key facts:

• Limits are aggregate across all models (not per-model)
• Advanced models (GLM-5 family) consume 2-3x quota per prompt due to reasoning tokens
• Limits are dynamic and load-dependent; these are conservative estimates
• Ref: https://docs.z.ai/devpack/usage-policy

Configuration

# Required
export ZAI_API_KEY="***"

# Optional -- defaults to conservative (Lite-equivalent)
export ZAI_TIER="pro"           # lite | pro | max
export ZAI_PLAN="coding"        # coding | general
export ZAI_THINKING="disabled"  # enabled | disabled
export ZAI_BASE_URL="..."       # override plan-based URL

Test Plan

uv run pytest tests/unit/test_providers/test_zai_provider.py -v
# 34 passed (21 existing + 13 new tier tests)

PR Stack

#	PR	Description	Status
1	#82 -- Generic tier framework	BaseProvider + resolve_rate_limiter()	Ready for review
2	#83 -- Z.AI adopts the framework (this PR)	RATE_LIMIT_TIERS + ZAI_TIER env var	Depends on #82
3	#84 -- MiniMax provider	New provider using the framework	Depends on #82

Related

• Depends on: feat: add generic tier-aware rate limiting framework #82 (generic tier framework)
• Supersedes: feat(zai): add Z.AI provider with tier-aware rate limiting #80 (monolithic PR, now split into layered approach)
• Ref: Feature: Add Z.AI (Zhipu AI) provider support #68

[swati510]

Nice work on the generic tier framework, it's the right shape. Two things worth fixing before merge:

1. ZAI_TIER_DEFAULTS in packages/core/src/repowise/core/rate_limiter.py duplicates the same values as ZAIProvider.RATE_LIMIT_TIERS. Nothing imports ZAI_TIER_DEFAULTS since resolve_rate_limiter reads from the class attribute. It's dead code waiting to drift. Drop it or have the provider read from it, one source of truth.

2. The base URL normalization in zai.py concerns me. _PLAN_BASE_URLS values end with /v4, then init force-appends /v1, so the client hits https://api.z.ai/api/coding/paas/v4/v1/chat/completions. Has this been tested against the live API? Z.AI's OpenAI-compatible endpoint is /paas/v4 as-is, the SDK adds /chat/completions itself.

[swati510]

Confirm this works against the live Z.AI API. Their OpenAI-compatible endpoint is /v4 as-is, the SDK tacks on /chat/completions. Adding /v1 here produces /v4/v1/chat/completions which I'd expect to 404.