feat: reasoning_content in API for reasoning models

[Abhijay007]

closes #6192

PR description

This PR adds support for the reasoning_content field used by reasoning models like DeepSeek's reasoner, enabling goose to capture and display the step-by-step reasoning process that these models expose separately from their main response content.

Type of Change

• Feature

AI Assistance

• This PR was created or reviewed with AI assistance, used goose for approach and code

Testing

Tested on the desktop UI using the DeepSeek-Reasoner with sample “thinking” prompts.

Screenshots/Demos (for UX changes)

[Copilot]

Pull request overview

This PR adds support for the reasoning_content field used by reasoning models like DeepSeek's reasoner, enabling goose to capture and display the step-by-step reasoning process that these models expose separately from their main response content.

Key Changes:

• Added ReasoningContent type to the message content system for storing model reasoning steps
• Implemented bidirectional handling in OpenAI-compatible format (both request formatting and response parsing, including streaming)
• Updated all provider formatters to appropriately skip reasoning content for non-OpenAI providers

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
crates/goose/src/conversation/message.rs	Added ReasoningContent struct and enum variant with helper methods (reasoning(), as_reasoning())
crates/goose/src/providers/formats/openai.rs	Implemented full support for reasoning_content in message formatting, response parsing, and streaming responses with comprehensive tests
crates/goose/src/providers/formats/anthropic.rs	Added skip logic for reasoning content (not used by Anthropic)
crates/goose/src/providers/formats/bedrock.rs	Added skip logic for reasoning content (not used by Bedrock)
crates/goose/src/providers/formats/databricks.rs	Added skip logic for reasoning content (not used by Databricks)
crates/goose/src/providers/formats/snowflake.rs	Added skip logic for reasoning content (not used by Snowflake)
crates/goose/src/context_mgmt/mod.rs	Added formatting support for reasoning content in conversation compaction
crates/goose-server/src/openapi.rs	Exported ReasoningContent type for API schema generation
ui/desktop/openapi.json	Added OpenAPI schema definition for ReasoningContent type
ui/desktop/src/api/types.gen.ts	Generated TypeScript types for the new reasoning content variant

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.

[Copilot]

The comment states "DeepSeek requires reasoning_content field when tool_calls are present" but this logic applies to all OpenAI-compatible providers. While OpenAI APIs typically ignore unknown fields, consider clarifying the comment to indicate this behavior affects all OpenAI-compatible providers, not just DeepSeek. Additionally, setting reasoning_content to an empty string when tool_calls exist but no reasoning was provided might not be necessary for all providers.

Suggested change

	// DeepSeek requires reasoning_content field when tool_calls are present
	// Set it to the captured reasoning text, or empty string if not present
	// For OpenAI-compatible providers, include reasoning_content when tool_calls are present
	// Use the captured reasoning text if available, otherwise an empty string for compatibility

[taniacryptid]

Thank you for working on this and the other PRs! Tagging @block/goose-maintainers @block/goose-core-maintainers for each to have a look ❤️

[jamadeo]

thank you @Abhijay007 !

main question is around "thinking" vs "reasoning" -- I think we called it Reasoning in the internal type because it was first modeled after the anthropic format, but I think we could/should use just one for the internal type, unless there are real incompatibilities we'd need to address between providers

[zanesq]

@Abhijay007 checking if still in progress?

[Abhijay007]

@Abhijay007 checking if still in progress?

Will look into this soon, will share an update

[michange]

Which reasoning/thinking models should this PR support?
What about ACP (= Agent Client Protocol) standard for client↔agent communication. Goose is adopting it. May it eventually cover event streaming ?

[DOsinga]

can we get this landed? @Abhijay007 - if you address @alexhancock 's last comments and match main, let's merge?

[Abhijay007]

can we get this landed? @Abhijay007 - if you address @alexhancock 's last comments and match main, let's merge?

Will look into this today will resolve it asap

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.

[Copilot]

format_messages unconditionally adds a reasoning_content field whenever tool_calls are present (and even sets it to an empty string), which will be included in requests for all OpenAI/OpenAI-compatible providers using this formatter and can cause 400s on providers that don’t recognize this non-standard message field. Gate emitting reasoning_content behind an explicit capability check (e.g., model/provider is DeepSeek reasoner) or move this into a provider-specific request mutator similar to openrouter::add_reasoning_details_to_request, and avoid sending the field at all for providers that don’t require it.

Suggested change

	// DeepSeek requires reasoning_content field when tool_calls are present
	// Set it to the captured reasoning text, or empty string if not present
	if converted.get("tool_calls").is_some() {
	let reasoning = reasoning_text.unwrap_or_default();
	converted["reasoning_content"] = json!(reasoning);
	} else if let Some(reasoning) = reasoning_text {
	if !reasoning.is_empty() {
	converted["reasoning_content"] = json!(reasoning);
	}
	}

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

[Copilot]

format_messages only keeps the last MessageContent::Reasoning block (reasoning_text = Some(...)), but streaming aggregation can append many reasoning deltas to a single message id, so earlier reasoning is silently dropped when re-sending conversation history; accumulate/append all reasoning parts instead of overwriting.

Suggested change

	reasoning_text = Some(r.text.clone());
	match &mut reasoning_text {
	Some(existing) => {
	if !existing.is_empty() {
	existing.push('\n');
	}
	existing.push_str(&r.text);
	}
	None => {
	reasoning_text = Some(r.text.clone());
	}
	}

[Copilot]

reasoning_content is currently added to any message that has tool_calls, even though the comment says it’s a DeepSeek-specific requirement; this risks sending a non-standard field to other OpenAI-compatible providers, so gate it behind a DeepSeek/reasoning-model check (e.g., model name/provider capability) rather than only tool_calls presence.

Suggested change

	// DeepSeek requires reasoning_content field when tool_calls are present
	// Set it to the captured reasoning text, or empty string if not present
	if converted.get("tool_calls").is_some() {
	let reasoning = reasoning_text.unwrap_or_default();
	converted["reasoning_content"] = json!(reasoning);
	} else if let Some(reasoning) = reasoning_text {
	// Only include reasoning_content when we actually have captured reasoning text.
	if let Some(reasoning) = reasoning_text {