Two UsageProvider cases: stepfun-cn (global, platform.stepfun.com) and stepfunCN (China, platform.stepfun.com). StepFun issues separate accounts and API keys per region – a China-issued key only authenticates against the .com host.
Data sources + fallback order
- API token (single source, one fetch strategy per region).
Endpoint
GET <baseURL>/v1/accounts(https://api.stepfun.comorhttps://api.stepfun.com)- Headers:
Authorization: Bearer <token>,Content-Type: application/json.
Unverified response schema. StepFun’s exact JSON shape for /v1/accounts is not publicly documented in detail. StepFunUsageFetcher parses defensively with JSONSerialization and looks for the first numeric value under common balance-shaped keys (available_balance, balance, total_balance, remaining_balance, quota, remaining) rather than a strict Decodable struct. If none match, the provider shows “Connected (balance format not recognized – check dashboard)” instead of failing – update StepFunUsageFetcher.balanceKeys once the real shape is confirmed against a live account.
Credentials
Token resolution order (global):
- Keychain token (stored from Preferences -> Providers -> StepFun).
- Environment variable
STEPFUN_CN_API_KEY.
Token resolution order (China):
- Keychain token (stored from Preferences -> Providers -> StepFun (China)).
- Environment variable
STEPFUN_CN_API_KEY.
Keychain locations
- Service:
com.sriinnu.athena.Runic.provider-credentials.v2 - Accounts:
stepfun-api-token,stepfun-cn-api-token
Key files
Sources/RunicCore/Providers/StepFun/StepFunUsageFetcher.swiftSources/RunicCore/Providers/StepFun/StepFunProviderDescriptor.swiftSources/RunicCore/Providers/StepFun/StepFunCNProviderDescriptor.swiftSources/Runic/Providers/StepFun/StepFunProviderImplementation.swiftSources/Runic/Providers/StepFun/StepFunCNProviderImplementation.swift
Read the source ↗ Checked against Runic 2.13.5 · 9730f91