@ServeurpersoCom, we don't need to concern ourselves with the tags. Just sending back the reasoning_content field is sufficient. The parsing in common should ensure it gets populated in the template.

If it's a matter of returning the reasoning_content exactly as it was received on frontend, it's trivial.

this is what the old webui did with "Exclude thought process when sending requests to API" setting OFF, right?

this is what the old webui did with "Exclude thought process when sending requests to API" setting OFF, right?

Not quite. In the old WebUI, it relied on extracting the thinking tags from the assistant message. The option simply turned this off. The CoT was still received in the content field.

It is now preferred to parse the reasoning on the backend and pass it to clients in the separate reasoning_content field.

I would like to have exactly that option back...

It won't simply be enough to just put reasoning_content back into the server. In most cases, jinja chat template simply don't know how to handle it, and it will be removed from the message.

I doubt if we can really have a good balance approach for interleaved thinking models. For these model, we probably need to also send and store the non-parsed version of the message (bypass chat parsing).

It won't simply be enough to just put reasoning_content back into the server. In most cases, jinja chat template simply don't know how to handle it, and it will be removed from the message.

Just like the parsing extracts the reasoning traces, the chat init/formatting can transform them to the appropriate field in the template. The specialization already exists for a particular template, so no generalized approach is necessary. The only thing is to standardize the field, which has settled to reasoning_content now.

This is already done for Command R7B, GPT-OSS, and Ministral. Templates for MiniMax M2 and Kimi K2 already look for message.reasoning_content, so no additional work is needed for them.

Of course, this falls apart if models start emitting other artifacts.

Sure. If we move to a class-based API (#18215), then the chat template lifecycle can match the server process and provide functions to query its capabilities. I'm guessing you'll need this information upfront to present a warning. Or copy how it's done in supports_thinking().

I wonder what's the benefit of the check, though. It's added complexity for information that can be inferred after detecting the chat format.

I think for now, the main benefit would be to report to the webui if the chat template supports feeding back the reasoning content. Just to make it more visible to end-user, maybe?

I think it's a great idea.

I was thinking we could just return a known set of capabilities depending on the chat format. Honestly, though, the checks are only a few lines of code so there's no harm in implementing them.