feat(engine): add configurable reasoning model support in OpenAiEngine

[watashi-00]

Description

This PR introduces configurable support for Reasoning Models in OpenAiEngine (and derived engines like GroqEngine), allowing users to explicitly enable reasoning mode and adjust token allocations for thinking models.

Motivation

Providers like Groq now feature models with reasoning/thinking processes by default. Previously, using these models in OpenAiEngine resulted in empty commits or failures because:

1. They consume output budget during internal thinking steps, exhausting standard max_tokens limits.
2. They expect max_completion_tokens instead of traditional temperature/top_p + max_tokens.
3. They output thought blocks (e.g. <think>...</think>) that need to be stripped from the final message.

---

Key Changes

• New Config Keys (src/commands/config.ts):

  • OCO_REASONING: Boolean flag (true/false) allowing users to explicitly toggle reasoning mode for any model (oco config set OCO_REASONING=true).
  • OCO_REASONING_MAX_TOKENS: Configurable token limit dedicated to reasoning/output (defaults to DEFAULT_TOKEN_LIMITS.DEFAULT_MAX_REASONING = 4096).

• Engine Logic (src/engine/openAi.ts):

  • Checks this.config.isReasoning first; if not explicitly set, falls back to the existing regex (/^(o[1-9]|gpt-5)/).
  • When reasoning mode is active:
    • Switches parameters to max_completion_tokens: reasoningTokens.
    • Adjusts token input validation dynamically (Math.max(inputLimit, reasoningTokens * 2)) to avoid false-positive tooMuchTokens errors under default limits.
    • Strips <think> tags from output via removeContentTags.

---

Observations & Future Improvements

1. Context Window & Large Diffs:
   • Reasoning models generate significantly more internal tokens on larger diffs. Under default input limits, a dynamic calculation fallback was added, with a TODO left for a potential dedicated reasoning input limit config.
2. System Prompt Refinement:
   • Guiding reasoning models to keep thinking concise could further optimize token usage and response latency.

Closes #511
Closes #510

[watashi-00]

Hello!
This is my first time contributing to an open-source project on GitHub.
It took a little bit of head-scratching to get the PR and upstream workflow right, but I hope I got everything in order and that this helps improve reasoning model support;
Let me know if anything needs tweaking

[di-sukharev]

@watashi-00 will take a look, thank you for the contribution

[di-sukharev]

@watashi-00

Thanks for working on this — using max_completion_tokens and omitting unsupported sampling parameters is the right direction.

I don’t think the PR is ready to merge yet because I found two blocking issues:

1. DEFAULT_CONFIG sets OCO_REASONING to false, while OpenAiEngine only falls back to model-name detection when isReasoning is undefined. As a result, fresh/default configs never auto-detect o* or gpt-5 models and continue sending temperature, top_p, and max_tokens. This means [Bug]: GPT5 Doesn't Support max_token, instead use max_completion_tokens instead #510/[Bug]: GPT-5-nano does temperature = 0 #511 remain reproducible for new users. Please preserve a real auto mode — for example, leave the value undefined by default or introduce an explicit auto | true | false mode.

2. Math.max(maxTokensInput, reasoningTokens * 2) silently increases the configured model token limit. With the defaults it turns 4096 into 8192, so local validation may accept a request that exceeds the user’s configured context window and leave the API to reject it. Please keep the total request within the configured limit, or introduce a separate explicit context/input budget and use it consistently in both validation and diff chunking.

Please also add unit tests covering:

• automatic o* / gpt-5 detection through the real config path;
• explicit true/false overrides;
• the exact parameters sent for reasoning and non-reasoning models;
• token-limit boundaries;
• validation of OCO_REASONING_MAX_TOKENS as a positive integer.

Finally, prettier --check and git diff --check currently fail in src/commands/config.ts.

The overall approach looks useful, and I’d be happy to re-review after these changes.

[di-sukharev]

@watashi-00 you should also make master the base branch (not dev). i've just merged master to dev and your PR now got conflicts which also have to be resolved before the merge, please do a git pull 🙏

[di-sukharev]

An explicit override is useful, but the current default disables the existing automatic detection of reasoning models. The PR also conflicts with the current master and fails Prettier. After rebasing, please add regression tests for the default, true, and false cases.

[di-sukharev]

false is always copied into AiEngineConfig, so the typeof this.config.isReasoning === 'boolean' branch selects it and the o*/gpt-5 regex is never evaluated. Reasoning models therefore go back to receiving max_tokens and temperature by default. To preserve automatic detection, the default must be undefined or auto; false should represent only an explicit user override.

[di-sukharev]

Math.max(inputLimit, reasoningTokens * 2) artificially expands the configured or model input limit and can allow a request that does not fit the actual context window. The validation should respect the configured context budget and subtract the output/reasoning budget instead of increasing it.

[watashi-00]

Thanks for the detailed review and for pointing out those issues! I'm changing the base branch to master and resolving the merge conflicts right now. After that, I'll work on fixing the token logic, adding the tests, and correcting the formatting. I'll ping you once everything is updated and ready for another look.

[di-sukharev]

Thanks for the update. The explicit auto mode and the silent input-limit increase are fixed, but the current head still has blocking issues:

1. The defaults make every auto-detected reasoning request fail before the API call. OCO_TOKENS_MAX_INPUT and OCO_REASONING_MAX_TOKENS both default to 4096, so the validation boundary becomes 4096 - 4096 = 0; any non-empty prompt throws TOO_MUCH_TOKENS. Please choose a safe default and keep diff chunking plus request validation on the same total budget. Add a test that uses the real default config and reaches the mocked client for an o* or gpt-5* model.

2. OCO_REASONING_MAX_TOKENS is documented as a positive integer, but the validator only checks !isNaN(parseInt(value)). It currently accepts zero, negative values, fractions, and strings with numeric prefixes. Please require a positive integer and add rejection tests.

3. The PR still targets dev. Please retarget it to master, rebase on the newly updated master, and rebuild the tracked bundle once; the current PR shows a very large generated-bundle diff.

The earlier auto-detection and formatting concerns are otherwise addressed. Happy to re-review after these remaining changes.

[watashi-00]

Thanks for the detailed review! I’ll work on the remaining issues and make the necessary changes and tests. I’ll update the PR once everything is addressed. Thanks again

[watashi-00]

Hi @di-sukharev,

I’ve updated the PR to address the remaining feedback

• Changed the default reasoning token limit to 1000, leaving enough room for the input under the default 4096 token budget.
• Updated diff chunking to use the same reasoning token budget as the request validation.
• Added a regression test to make sure auto-detected reasoning models like o3-mini reach the mocked client with the default config.
• Made OCO_REASONING_MAX_TOKENS require a strictly positive integer and added tests for invalid values.
• Retargeted the PR to master, rebased it, and rebuilt out/cli.cjs.
• Ran the unit tests and format checks successfully.

I also noticed two potential improvements while working on this

1. OCO_TOKENS_MAX_INPUT and OCO_TOKENS_MAX_OUTPUT still use the older parseInt() validation. Would it make sense to apply the same strict positive-integer validation to them as well?
2. For OpenAI-compatible providers that reject reasoning-related parameters with HTTP 400, would it be useful to catch that in engineErrorHandler and suggest enabling OCO_REASONING? (I have explored an implementation for this in a separate branch and would be happy to submit it as a follow-up PR if desired).

Thanks again for the detailed review. Looking forward to your feedback

[di-sukharev]

Maintainer fixes are applied and the updated implementation passes lint, build, and all 163 unit tests.

[di-sukharev]

Thanks again for the contribution! I applied the remaining maintainer fixes directly to the branch: strict positive-integer parsing, restoration of split-diff one-line behavior, removal of the duplicated provider enum, a real default-config-to-engine regression test, a regenerated bundle, and documentation for the new options. Lint, build, and all 163 unit tests pass. I've merged the PR into master.

[watashi-00]

Thanks again for the review and for the help with the final changes! I went through the changes and took a look at the adjustments you made. I really appreciate the feedback and the time you put into reviewing the PR.

[di-sukharev]

Everything is done and the PR is now merged. Thank you for the contribution!