[Bug] Generated model catalog contains impossible maxTokens > contextWindow values

[jimmyarphs2]

Summary

I found two entries in the generated model catalog where "maxTokens" is greater than the model's own "contextWindow".

This appears to violate the expected invariant:

"0 < maxTokens <= contextWindow"

The affected entries on "main" are:

Provider| Model| contextWindow| maxTokens
huggingface| "thinkingmachines/Inkling-Small"| 524288| 1048576
openrouter| "openai/gpt-3.5-turbo-0613"| 4095| 4096

The first appears to have inherited the output limit from the larger "thinkingmachines/Inkling" model, while the second exceeds its context window by exactly one token.

Why this matters

The catalog values are not purely descriptive metadata.

They flow into request construction.

In particular, "packages/ai/src/providers/simple-options.ts" derives the default output budget from "model.maxTokens", with a 32000-token clamp in the default path.

However, "packages/ai/src/providers/openai-completions.ts" can send an explicitly supplied "options.maxTokens" value without that default clamp.

Therefore, although the normal path currently masks the larger "Inkling-Small" discrepancy, the underlying catalog invariant remains invalid and callers that explicitly provide a budget in the affected range can receive provider-side rejection.

This also means downstream consumers treating these fields as model capabilities can receive an impossible configuration.

Reproduction

1. Open "packages/ai/src/models.generated.ts" on "main".
2. Locate the entries for:
   • "thinkingmachines/Inkling-Small"
   • "openai/gpt-3.5-turbo-0613"
3. Compare "contextWindow" and "maxTokens".

The invariant fails for both entries:

Inkling-Small:
maxTokens = 1048576
contextWindow = 524288

1048576 > 524288

and:

gpt-3.5-turbo-0613:
maxTokens = 4096
contextWindow = 4095

4096 > 4095

A mechanical validation could be as simple as asserting:

0 < maxTokens <= contextWindow

for every generated "Model" entry.

Expected behavior

Every generated model should satisfy:

0 < maxTokens <= contextWindow

If upstream metadata provides values that cannot satisfy this invariant, the generator should either:

1. normalize/clamp the values before emitting the catalog, or
2. fail generation with a clear error so the problematic upstream data is investigated.

For known exceptions, an explicit override table with a comment explaining the correction would also make the behavior auditable.

Possible fix

I think the safest long-term solution is to enforce the invariant in the model-generation pipeline rather than relying on individual consumers to defend against invalid metadata.

For example:

if maxTokens > contextWindow:
report the model/provider
either apply an explicit override
or fail generation

The two currently observed entries could then receive explicit overrides if their upstream metadata is confirmed to be incorrect.

Additional observation

The sibling Hugging Face entry:

"thinkingmachines/Inkling"

declares:

contextWindow: 1048576
maxTokens: 1048576

This makes the "Inkling-Small" value particularly suspicious because its "maxTokens" is identical to the larger model while its context window is half as large.

The OpenRouter GPT-3.5 entry is different: the discrepancy is only one token, so it may simply reflect an upstream metadata/rounding convention. Nevertheless, it still violates the invariant and should be normalized or explicitly handled.

Suggested validation

It may be useful to add a generator-level validation test that scans all generated model entries and fails when:

maxTokens <= 0

or:

maxTokens > contextWindow

This would prevent future upstream catalog changes from silently introducing the same class of problem.

Environment

• Repository: "PrimeIntellect-ai/prime-agent"
• Branch: "main"
• Report originally investigated against commit: "e319a66"

I originally opened this as Issue #1677 before realizing that Prime Agent's current contribution workflow requires bug reports to begin in Discussions.

I'm reposting the finding here so it can be reviewed through the intended workflow.

If useful, I'm happy to investigate the generator path further and prepare a focused patch after maintainer feedback.