Describe the Bug
Reasoning when using r1-1776 model seems to not be always correctly
enclosed in <think>...</think>.
Expected Behavior
I expected the reasoning to always be enclosed in <think>...</think>.
Actual Behavior
I got a response with the end tag </think> missing.
Steps to Reproduce
- I called the API with this request:
{
"stream": false,
"model": "r1-1776",
"temperature": null,
"messages": [
{
"role": "user",
"content": "foo bar baz"
},
{
"role": "assistant",
"content": "<think>\nOkay, so the user wrote \"foo bar baz\". Hmm, I need to figure out what they want. Let me think.\n\nFirst, \"foo\", \"bar\", and \"baz\" are common placeholder names used in programming examples. They don't have specific meanings on their own, right? Maybe the user is testing if I understand that. Or maybe they want me to explain what these terms mean.\n\nAlternatively, they could be referencing something specific where \"foo bar baz\" is part of a code example or a problem statement. But without more context, it's hard to tell. Let me check if there's any hidden meaning or if this is part of a larger question.\n\nWait, sometimes people use these terms in demonstrations, like showing how a function works or explaining variables. Maybe they want an example of code using these terms. Or perhaps they're asking about the origin of these placeholder words.\n\nWait, the user might just be checking if the system is responsive. Sometimes users input random text to see if the AI is working. But I should assume there's a genuine query.\n\nIf I consider \"foo bar baz\" as a sequence, maybe they want a concatenation, transformation, or some operation on these strings. For example, combining them, reversing the order, or changing the case. But they didn't specify.\n\nAlternatively, could this be related to a specific programming problem? Like, maybe manipulating these strings in a certain way, such as splitting, joining, or applying a function. Or perhaps it's part of a regular expression example.\n\nAnother angle: in some contexts, \"foo\", \"bar\", and \"baz\" are used in metasyntactic variables. Maybe the user wants an explanation of that concept. For instance, explaining that these terms are used as dummy variables in programming documentation and examples.\n\nAlternatively, in certain problem-solving contexts, \"foo bar baz\" could be a test case. The user might want to see how the system processes input and provides output. But without additional details, it's unclear.\n\nI should also consider if there's a typo or if the user intended to ask something else but mistakenly sent \"foo bar baz\". But I can't assume that. I need to work with what's given.\n\nGiven the ambiguity, the best approach is to ask the user for clarification. However, since the user might expect a response based on the initial input, perhaps I should explain the possible contexts and offer to help further once more information is provided.\n\nAlternatively, provide a general explanation about metasyntactic variables and their usage in programming. That way, even if the user was testing, they get some useful information.\n\nWait, the user might want to know how to use these in code. For example, in Python, you could have variables named foo, bar, baz assigned to certain values. Or maybe they want to see a function that takes these as parameters.\n\nBut again, without more context, it's hard to proceed. Maybe the user is just playing around. However, as an assistant, I should aim to be helpful. Let me explain the common usage of these terms and invite the user to ask a more specific question if needed.\n</think>\n\nThe terms \"foo,\" \"bar,\" and \"baz\" are commonly used as **placeholder names** or **metasyntactic variables** in programming, documentation, and examples. They serve as generic identifiers when the specific name or value isn't important, allowing focus on the structure or logic of an example. Here's a breakdown:\n\n### 1. **Origin and Usage**:\n - **Foo**: Likely derived from the WWII-era slang \"FUBAR\" (Fouled Up Beyond All Recognition).\n - **Bar**: Often follows \"foo\" in examples (e.g., `foo + bar = baz`).\n - **Baz**: Extends the sequence when a third placeholder is needed.\n\n### 2. **Example in Code**:\n ```python\n foo = 5\n bar = 10\n baz = foo + bar # Result: 15\n ```\n\n### 3. **Use Cases**:\n - Demonstrating functions, variables, or syntax without real-world context.\n - Testing or debugging snippets (e.g., `print(\"foo\")`).\n - Placeholders in regular expressions, database schemas, etc.\n\n### Need a specific example or explanation? Let me know! 🚀"
},
{
"role": "user",
"content": "again"
}
]
}
- I received the following response where
</think>is missing:
{
"id": "4b899c69-ea45-4d2e-835d-cf03a9e460f3",
"model": "r1-1776",
"created": 1747923980,
"usage": {
"prompt_tokens": 908,
"completion_tokens": 263,
"total_tokens": 1171
},
"object": "chat.completion",
"choices": [
{
"index": 0,
"finish_reason": null,
"message": {
"role": "assistant",
"content": "<think>\nOkay, the user just sent \"again\" after my previous explanation about foo, bar, and baz. Let me figure out what they need.\n\nFirst, I should check if they want a repetition of the same information but maybe in a different format. They might not have understood the first explanation or want more details. Alternatively, they could be asking for another example or a different perspective on the same topic.\n\nLooking at the history, the initial question was about foo bar baz, and I provided a detailed breakdown. When they replied with \"again,\" it's a bit vague. Maybe they want the information presented again, but perhaps more concisely or with a focus on another aspect.\n\nAnother possibility is that the user wants to test if I'll repeat the same response or generate something new. To handle this, I should offer a slightly different angle or additional examples without being redundant. Adding some extra context or use cases could be helpful. Also, asking if they have a specific scenario in mind would engage them and clarify their needs.\n\nI should structure the response to include the same key points but perhaps with different examples or a different programming language. Maybe add a list of common variations like qux, quux, etc., and mention their use in different contexts like testing, documentation, or pseudocode. Including"
},
"delta": {
"role": "assistant",
"content": ""
}
}
]
}
Additional Question related to reasoning
Regarding the reasoning, why didn’t you put it a reasoning_content field like DeepSeek does? What are you constraints for not doing it? I’m sure I’m missing some context to understand why.
From a DX perspective, it’s easier (at least to me) to get the reasoning from a field in a JSON response than to parse a string to extract it, separate it from the actual response and then present this information the best way to the user.