Review: feat: add Novita AI as a bundled LLM provider

The integration follows the established pattern (definePluginEntry, buildSingleProviderApiKeyCatalog, plugin manifest, env var registration) and the code is structurally consistent with other bundled providers like Moonshot and ModelStudio. A few things worth addressing:

contextWindow equals maxTokens for Kimi K2.5

contextWindow: 262144,
maxTokens: 262144,

maxTokens is the per-response output limit, not the context window size. Having them identical (256K) looks wrong — 256K output tokens per request would be an unusually large output budget, and it is likely the Novita API enforces a much smaller output limit. Other models in the codebase (e.g., Anthropic claude-sonnet-4: 200K context / 64K max output) have clearly different values. Please verify these against Novita's API docs. An overestimated maxTokens could cause the agent to pass an max_tokens parameter the API rejects, or to skip truncation it should do.

Prompt caching cost fields for Novita

All three models include cacheRead and cacheWrite costs. Does Novita's OpenAI-compatible endpoint actually support prompt caching? If not, these fields are misleading and could cause the runtime to expect caching behavior that won't occur. Worth checking whether other OpenAI-compatible providers that don't support caching (e.g., NVIDIA, Together) leave these fields out.

novita in BUNDLED_ENABLED_BY_DEFAULT

Adding Novita to BUNDLED_ENABLED_BY_DEFAULT means it is enabled for every openclaw installation. Unlike widely-known providers (OpenAI, Anthropic), Novita is a newer inference marketplace. Is this the right tier? Some providers (like nvidia, modelstudio) are enabled-by-default, others are not. If Novita's service quality is still being established, making it opt-in (not in the default set) reduces user confusion if the API has reliability issues.

buildNovitaModelDefinition type signature

export function buildNovitaModelDefinition(
  model: (typeof NOVITA_MODEL_CATALOG)[number],
): ModelDefinitionConfig {

NOVITA_MODEL_CATALOG is typed as ModelDefinitionConfig[], so (typeof NOVITA_MODEL_CATALOG)[number] resolves to ModelDefinitionConfig — the parameter type is not narrower than ModelDefinitionConfig itself. The function could accept any model config, not just Novita catalog entries. This is not a bug, but the type is doing less work than intended. Consider using a typed catalog (e.g., as const satisfies ModelDefinitionConfig[]) if narrowness is important.

No tests

The PR test plan is manual-only. For a new provider, at minimum a discovery.contract.test.ts fixture and a provider catalog test (like models-config.providers.minimax.test.ts does for MiniMax) would prevent catalog regression. Without automated coverage, a future refactor of buildSingleProviderApiKeyCatalog could silently break Novita without any failing tests.

Minor: onboard.ts exports both applyNovitaProviderConfig and applyNovitaConfig but index.ts only uses applyNovitaConfig. The exported applyNovitaProviderConfig is useful for testing, but a comment noting the distinction (one sets the primary model, one doesn't) would help.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f1ff244415