AI Created Issue: Implement Extended Thinking

[issue-hemingway]

Originates from #72

Quality assessment

The issue is now sufficiently scoped and actionable. The key product decisions are resolved: the feature is configured on AI integrations, applies to every LLM interaction, and should expose provider-specific controls only for providers that support them. The only remaining unknowns are implementation details about which exact provider fields to expose first, but these can be tracked as explicit sub-decisions without blocking the issue.

Title

Add provider-specific reasoning / extended thinking settings to AI integrations

Summary

Add persistent provider-specific reasoning/thinking settings to AI integrations and apply them to every LLM request made through that integration.

This feature should support providers that expose native reasoning/thinking controls (currently Anthropic and OpenAI). Providers without such support must not show any related settings and must continue working unchanged.

Current behavior

• An AI integration lets the user choose an LLM provider and model.
• There is no way to configure provider-native reasoning/thinking features.
• As a result, all requests use the provider defaults, even for tasks that benefit from additional reasoning effort such as code reviews and issue implementation.

Expected behavior

• AI integrations can store provider-specific reasoning/thinking settings.
• These settings are applied to all requests sent through that integration.
• Supported providers expose their native settings in the admin UI.
• Unsupported providers do not expose any reasoning/thinking configuration.

Requirements

1. Configuration location

• The setting belongs to the AI integration, not to the bot.
• The configuration is persistent and reused automatically for every workflow that uses that AI integration.

2. Supported providers

Anthropic

• Expose Anthropic extended thinking settings in the AI integration create/edit UI.
• Persist the configured Anthropic values on the AI integration.
• Include those values in every Anthropic request made through that integration.

OpenAI

• Expose OpenAI reasoning-related settings in the AI integration create/edit UI.
• Persist the configured OpenAI values on the AI integration.
• Include those values in every OpenAI request made through that integration.

3. Unsupported providers

• Providers without equivalent support must not show any related configuration.
• Requests for unsupported providers must remain unchanged.
• The absence of support must not cause errors or fallback hacks.

4. Provider-specific design

• Do not replace provider-native capabilities with a single generic boolean toggle.
• Use provider-specific fields so the full provider functionality can be used.
• Only fields relevant to the selected provider may be saved and applied.

5. Scope of application

The configured reasoning/thinking settings must be applied consistently to every LLM interaction using that AI integration, including but not limited to:

• code review flows
• issue implementation flows
• bug analysis / bug implementation flows
• any other feature that routes requests through the selected AI integration

Out of scope

• Bot-level overrides
• Per-request or per-run overrides
• Adding no-op settings for unsupported providers
• Unifying all providers behind one generic “deep thinking” switch

Acceptance criteria

1. AI integration UI

   • When creating or editing an Anthropic AI integration, Anthropic-specific extended thinking settings are shown.
   • When creating or editing an OpenAI AI integration, OpenAI-specific reasoning settings are shown.
   • When creating or editing an unsupported provider integration, no reasoning/thinking settings are shown.
   • Changing the provider in the form updates the visible advanced settings accordingly.

2. Persistence

   • Supported provider settings are saved on the AI integration.
   • Reopening the same AI integration shows the previously saved values.
   • Existing AI integrations created before this feature remain valid and editable.

3. Request mapping

   • Every Anthropic request sent through an AI integration with configured thinking settings includes the saved Anthropic fields.
   • Every OpenAI request sent through an AI integration with configured reasoning settings includes the saved OpenAI fields.
   • Unsupported-provider requests do not include unsupported reasoning/thinking fields.

4. Isolation between providers

   • Anthropic settings are never sent in OpenAI requests.
   • OpenAI settings are never sent in Anthropic requests.
   • Unsupported providers never receive unknown provider-specific fields.

5. Backward compatibility

   • Existing integrations with no new settings continue to work without user intervention.
   • Supported providers continue to work when the new settings are left unset.

6. Validation

   • Invalid provider-specific values cannot be saved.
   • The backend rejects or ignores incompatible provider-specific fields for the selected provider in a controlled way.

7. Documentation

   • User/admin documentation is updated to describe:
     • where these settings are configured
     • which providers support them
     • that the settings apply to every LLM interaction using that AI integration

Suggested implementation areas

• admin/AiIntegration* for persistence, service logic, and UI/controller handling
• provider metadata classes for advertising available advanced settings
• ai/anthropic/* request building and payload mapping
• ai/openai/* request building and payload mapping
• any shared AI client abstractions impacted by passing provider-specific options

Test scenarios

• Create an Anthropic integration, configure extended thinking settings, save it, reopen it, and confirm the values persist.
• Create an OpenAI integration, configure reasoning settings, save it, reopen it, and confirm the values persist.
• Create an Ollama or Llama.cpp integration and verify that no reasoning/thinking settings are displayed.
• Execute a code review using an Anthropic integration and verify the outbound Anthropic request contains the configured thinking fields.
• Execute an issue implementation flow using an OpenAI integration and verify the outbound OpenAI request contains the configured reasoning fields.
• Verify an older integration without any new fields still loads and works.
• Switch an integration from a supported provider to an unsupported provider and verify requests no longer include stale provider-specific reasoning fields.

Open questions / follow-up decisions

• Which exact Anthropic fields should be exposed initially?
• Which exact OpenAI fields should be exposed initially?
• When switching providers, should no-longer-applicable provider-specific values be cleared immediately or only ignored at runtime?

Target branch

develop

Assumptions

• AI integration is the correct persistence boundary for provider-specific advanced model settings.
• All relevant LLM workflows resolve requests through the AI integration, so applying settings there will cover all intended interactions.
• The concrete Anthropic and OpenAI fields exposed in the UI will match the APIs already supported by this codebase at implementation time.

Open questions

• Which exact Anthropic fields should be exposed initially?
• Which exact OpenAI fields should be exposed initially?
• When switching providers, should obsolete provider-specific values be cleared or simply ignored?

---

This issue was automatically drafted by the AI technical-writer agent.