AI Assistant response error

[samaguire]

Description

I'm getting this error when I run a chat message:

Error getting AI response: HTTP 400 (invalid_request_error: invalid_request_error)
Error from provider (DeepSeek): The reasoning_content in the thinking mode must be passed back to the API.

I'm using a custom (OpenAI compatible) provider:

url: https://opencode.ai/zen/v1
model: big-pickle

It seems to only effect this model; there are a few free ones available that I've been testing.

Documentation can be found here: https://opencode.ai/docs/zen/

Tabular Editor 3 Version

3.26.1

Screenshots

Steps to Reproduce

No response

Expected behavior

No response

Crash Report

No response

Windows Version

Windows 11

[otykier]

Hi @samaguire
Thanks for reporting this. We'll investigate and get back to you.

[otykier]

Thanks for the detailed report, including the screenshots and provider link. That made it quick to track down.

What's happening

The "big-pickle" model on opencode.ai's Zen gateway is a thinking-mode model that exposes its reasoning via a reasoning_content field on assistant messages, and requires that field to be echoed back on subsequent turns. If it isn't, the API returns the 400 you're seeing.

The catch is that reasoning_content is not part of the OpenAI Chat Completions specification, it's a non-standard extension popularised by DeepSeek and adopted by some compatible gateways. OpenAI's own reasoning models (o1/o3/o4) don't use this field at all; their reasoning state is handled differently, on a separate API. So strictly speaking, the model isn't fully OpenAI-compatible despite being served over an OpenAI-compatible endpoint.

That said, the underlying .NET AI library Tabular Editor 3 uses on the Custom provider already reads reasoning_content from responses - it just doesn't write it back out on the next request. So it's also a gap on our side that we can close.

Workarounds for now

• On opencode.ai/zen, switch to a model that doesn't run in thinking mode. Most of the free models there work without this issue, as you noted.
• Or use a different provider that doesn't impose this requirement (OpenAI, Anthropic, Azure OpenAI, and most OpenRouter models work without it).

Plan

We'll add explicit handling for reasoning_content round-tripping on the Custom (OpenAI-compatible) provider in an upcoming release, gated so it doesn't break providers like DeepSeek R1 that forbid the echo. I'll link the fix to this issue when it lands.

Thanks again for flagging it. The fix will benefit anyone using a thinking-mode model behind an OpenAI-compatible endpoint.

[samaguire]

No problem. And I'm glade there is a solve for this; the more I play with this feature, the more I like using it.

Curiously, are there any plans to add a dropdown to select/control the level of thinking to use?

[otykier]

the more I play with this feature, the more I like using it.

That's really great to hear, thank you!

Curiously, are there any plans to add a dropdown to select/control the level of thinking to use?

Not currently. We would have to map out the spec for this per provider/model, as there is no standardized way in the .NET library (Microsoft.Extensions.AI), as far as I know.

[MariaJoseFF]

Hi @samaguire, I looked into this further and couldn't reproduce the issue with the same setup anymore.

Testing against big-pickle on opencode.ai/zen, the prompts (like "list the measures in this model" or "Use the Semantic Model Organization Skill") now complete without the HTTP 400 ... reasoning_content ... must be passed back error.

The model still emits reasoning content, but the provider no longer rejects the follow-up request when it isn't echoed back. big-pickle is a preview/"stealth" model, and its behavior appears to have changed since you filed this, so the specific condition that triggered the error no longer seems to be enforced on the provider side.

Can you confirm if you can still reproduce the error with big-pickle (or any other model)? A confirmation from your side would help us close this out with confidence.