refactor!: drop reasoning trace extraction logic

[Pouyanpi]

Stack Info

This PR is part of a stack:

1. refactor!: drop reasoning trace extraction logic #1427 (this PR)
2. feat: add reasoning trace extraction from llm calls #1431
3. feat: emit BotThinking events with reasoning traces #1432
4. feat(logging): improve event logging and add bot thinking display #1434

⚠️ Review order: Start here, then proceed through #1431 → #1432 → #1434

Description

Replaces custom reasoning trace extraction with LangChain's built-in additional_kwargs approach, removing ~1,500 lines of code.

Breaking Changes

• reasoning_config (including start_token, end_token, remove_reasoning_traces) removed from model configuration
• apply_to_reasoning_traces removed from output rails configuration

Migration

Remove reasoning_config sections from config files. Reasoning traces are now automatically extracted by LangChain for supported models (e.g., DeepSeek-R1).

• TODO:
• deprecate reasoning_config from config gracefully

Changes

• Removed: ReasoningModelConfig, ParsedTaskOutput, token extraction logic
• Added: Automatic extraction from response.additional_kwargs['reasoning_content']
• Deleted: 4 test files (~1,085 lines)

[codecov-commenter]

Codecov Report

❌ Patch coverage is 62.50000% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
nemoguardrails/actions/llm/utils.py	50.00%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[tgasser-nv]

Looks good! Just want to check we cover lines 201-3 of actions/llm/utils.py in another of the PRs in the stack

[tgasser-nv]

Lines 201-203 aren't covered by tests in this PR. These are pretty important since they're where we pull out the additional_kwargs and put them in the context var (!) Are there tests in another one of the stacked PRs that cover these?

[trebedea]

@Pouyanpi , shouldn't we keep rails.output.apply_to_reasoning_traces functionality?
Or you are adding it again in one of the follow-up MRs?

[Pouyanpi]

@Pouyanpi , shouldn't we keep rails.output.apply_to_reasoning_traces functionality? Or you are adding it again in one of the follow-up MRs?

Not anymore, now if someone wants to use a specific output rails that checks the reasoning content should include it in the prompt template (see https://github.com/NVIDIA-NeMo/Guardrails/pull/1432/files#diff-1eb0f307d462ecfbe7710b361f4d296d3648a44bfcf85fda895c6942b2e4606dR37-R39 ) and use a rail that supports guardrailing reasoning contents ( for example see how actions.py is modified)

There needs to be a subsequent PR that updates some of the actions.

[trebedea]

Not anymore, now if someone wants to use a specific output rails that checks the reasoning content should include it in the prompt template (see https://github.com/NVIDIA-NeMo/Guardrails/pull/1432/files#diff-1eb0f307d462ecfbe7710b361f4d296d3648a44bfcf85fda895c6942b2e4606dR37-R39 ) and use a rail that supports guardrailing reasoning contents ( for example see how actions.py is modified)

There needs to be a subsequent PR that updates some of the actions.

I don't have anything against it, but for me it seemed like a useful option to be able to run any output rails on response only vs (thinking + response) by only adding a config flag. I agree that with the current implementation even more complex output rails can be defined way easier, but maybe it's not a bad idea to have the flag anyway.