jlcodes99/cockpit-tools · error

[CodexModelProviders] 额度类型探测失败

Error message

[CodexModelProviders] 额度类型探测失败

What it means

Non-fatal warning path in the add-account flow of useCodexAccountsAccessController: after saving a model provider, queryCodexModelProviderUsage was called to probe whether the endpoint is sub2api/new_api so the detected integration type could be persisted; any failure here is caught, logged as '[CodexModelProviders] 额度类型探测失败', and deliberately ignored — the account addition continues with the provider as originally configured.

Source

Thrown at src/pages/useCodexAccountsAccessController.tsx:2508

            };
            try {
              const usageSummary = await queryCodexModelProviderUsage({
                baseUrl: savedProvider.baseUrl,
                apiKey: validation.apiKey,
                integrationType: savedProvider.integrationType ?? null,
              });
              if (
                (usageSummary.mode === "sub2api" ||
                  usageSummary.mode === "new_api") &&
                usageSummary.mode !== savedProvider.integrationType
              ) {
                await saveCodexModelProviderDetectedIntegrationType(
                  savedProvider.id,
                  usageSummary.mode,
                );
              }
            } catch (usageErr) {
              console.warn("[CodexModelProviders] 额度类型探测失败", usageErr);
            }
            await reloadManagedProviders();
          } catch (providerErr) {
            console.warn(
              "[CodexModelProviders] 添加账号前写入供应商失败",
              providerErr,
            );
            throw providerErr;
          }
        }
        const account = await codexService.addCodexAccountWithApiKey(
          validation.apiKey,
          validation.apiBaseUrl,
          finalProviderPayload.apiProviderMode,
          finalProviderPayload.apiProviderId,
          finalProviderPayload.apiProviderName,
          finalProviderPayload.apiModelCatalog,
          finalProviderPayload.apiSupportsVision,

View on GitHub (pinned to 1ed8b77992)

Solutions

  1. Check provider baseUrl/apiKey reachability if usage-based features misbehave
  2. Ignore when offline — the probe is best-effort and the saved integrationType still applies
  3. Re-save the provider later to re-trigger detection once the endpoint responds
Defensive patterns

Strategy: try-catch

When it happens

Trigger: Thrown at src/pages/useCodexAccountsAccessController.tsx:2508 when the library encounters an invalid state.

Common situations: See trigger scenarios.


AI-assisted analysis of jlcodes99/cockpit-tools@1ed8b77992 (2026-09-05). Data as JSON: /api/errors/f9382915d57c12e4. Report an issue: GitHub.