OpenAI-compatible APIs में अब request के दो मुख्य formats हैं: लंबे समय से मौजूद /v1/chat/completions और नया /v1/responses। GetVibe API दोनों को एक ही key और एक ही base URL, https://getvibeapi.com/v1, के साथ स्वीकार करता है। यहां बताया गया है कि व्यवहार में इनमें क्या अंतर है, किसे चुनना चाहिए, और इनके बीच switch करते समय कौन-सी एक बात ध्यान में रखनी चाहिए।
संक्षेप में
| Chat Completions | Responses | |
|---|---|---|
| Endpoint | POST /v1/chat/completions | POST /v1/responses |
| Input | एक messages array | input: एक string या items का array |
| System prompt | system role वाला message | instructions field |
| Answer | choices[0].message | एक output array: reasoning, message, function calls |
| Output limit | max_tokens | max_output_tokens |
| कौन उपयोग करता है | अधिकांश SDKs, frameworks और chat apps | Codex CLI और नए agent SDKs |
Format बदलने से model, price या token count नहीं बदलता: दोनों ही स्थितियों में आपको model के input और output tokens के लिए bill किया जाता है।
दोनों formats में एक ही request
Chat Completions:
curl https://getvibeapi.com/v1/chat/completions \
-H "Authorization: Bearer $GETVIBE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6-luna",
"messages": [
{"role": "system", "content": "एक वाक्य में उत्तर दें।"},
{"role": "user", "content": "HTTP 429 का क्या मतलब है?"}
],
"max_tokens": 300
}'
Responses:
curl https://getvibeapi.com/v1/responses \
-H "Authorization: Bearer $GETVIBE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6-luna",
"instructions": "एक वाक्य में उत्तर दें।",
"input": "HTTP 429 का क्या मतलब है?",
"max_output_tokens": 300
}'
Chat Completions में text choices[0].message.content में होता है। Responses में यह output के अंदर होता है: reasoning models के लिए पहला item reasoning item होता है और answer message type वाले item में होता है। आपको array को हाथ से traverse करने की आवश्यकता नहीं है; Python SDK में output_text property उपलब्ध है।
import os
from openai import OpenAI
client = OpenAI(base_url="https://getvibeapi.com/v1", api_key=os.environ["GETVIBE_API_KEY"])
chat = client.chat.completions.create(
model="gpt-6-luna",
messages=[{"role": "system", "content": "एक वाक्य में उत्तर दें।"},
{"role": "user", "content": "HTTP 429 का क्या मतलब है?"}],
)
print(chat.choices[0].message.content)
resp = client.responses.create(
model="gpt-6-luna",
instructions="एक वाक्य में उत्तर दें।",
input="HTTP 429 का क्या मतलब है?",
)
print(resp.output_text)
Responses केवल OpenAI models तक सीमित नहीं है। प्रकाशित करने से पहले हमने यही Responses request gpt-6-luna, claude-sonnet-5.5 और deepseek-v4.1-flash को भेजी और तीनों ने उत्तर दिया। DeepSeek ने अपने message से पहले एक reasoning item लौटाया, बिल्कुल ऊपर बताए गए तरीके के अनुसार।
Conversation history: इसे खुद भेजें
Switch करने से पहले जानने वाली यही एक महत्वपूर्ण बात है। OpenAI का अपना Responses API conversation को server पर रख सकता है, इसलिए अगली request previous_response_id के जरिए पिछली request की ओर संकेत करती है। GetVibe API आपकी conversations store नहीं करता, इसलिए previous_response_id supported नहीं है और store को ignore किया जाता है। जब हमने इसे आज़माया, तो request 400 error के साथ reject हो गई।
काम करने वाला pattern Chat Completions जैसा ही है: पूरी history को input में भेजें।
history = [{"role": "user", "content": "मेरा नाम Ana है। इसे याद रखें।"}]
first = client.responses.create(model="gpt-6-luna", input=history)
history.append({"role": "assistant", "content": first.output_text})
history.append({"role": "user", "content": "मेरा नाम क्या है? एक शब्द में।"})
second = client.responses.create(model="gpt-6-luna", input=history)
print(second.output_text) # Ana
Tools: एक अलग structure
Function calling दोनों formats में काम करता है, लेकिन tool definition अलग दिखाई देती है। Chat Completions में function fields एक function object के अंदर nested होते हैं; Responses में वे सीधे tool पर होते हैं। Call एक अलग function_call item के रूप में आता है और आप उसी call_id वाले function_call_output item के रूप में result लौटाते हैं।
import json
tools = [{
"type": "function",
"name": "get_weather",
"description": "किसी शहर का वर्तमान मौसम",
"parameters": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"],
"additionalProperties": False,
},
}]
items = [{"role": "user", "content": "Denver में मौसम कैसा है?"}]
resp = client.responses.create(model="gpt-6-luna", input=items, tools=tools)
for item in resp.output:
if item.type == "function_call":
result = {"city": "Denver", "temp_f": 54, "sky": "overcast"} # आपका function
items.append({"type": "function_call", "call_id": item.call_id,
"name": item.name, "arguments": item.arguments})
items.append({"type": "function_call_output", "call_id": item.call_id,
"output": json.dumps(result)})
final = client.responses.create(model="gpt-6-luna", input=items, tools=tools)
print(final.output_text)
हमारे run में model ने get_weather को {"city":"Denver"} के साथ call किया और दूसरी request ने उत्तर दिया कि Denver में तापमान 54°F है और मौसम बादलों से घिरा हुआ है। इसी loop का Chat Completions version हमारी function calling guide में है।
Streaming
दोनों formats "stream": true को support करते हैं, लेकिन events अलग होते हैं। Chat Completions एकसमान data: lines भेजता है, जिसमें text का हर नया हिस्सा choices[0].delta.content में होता है। Responses named events भेजता है: सबसे पहले response.created, text के हिस्सों के साथ response.output_text.delta, और अंत में response.completed। यदि आप SDK के बजाय खुद stream parse करते हैं, तो आपको specific format के लिए parser चाहिए।
किसे चुनें
- Chat Completions तब चुनें, जब आपके पास पहले से इस पर code हो या आप किसी framework, chat app या no-code platform का उपयोग करते हों। लगभग हर tool इसे support करता है और केवल format बदलने के लिए काम कर रहे code को rewrite करने का कोई कारण नहीं है।
- Responses तब चुनें, जब किसी tool को इसकी आवश्यकता हो। इसका मुख्य उदाहरण Codex CLI है, जो
/v1/responsesसे बात करता है; setup Codex CLI docs और हमारी Codex CLI guide में है।
किसी भी विकल्प में model list और prices समान हैं। हर field के लिए API reference देखें और live prices के लिए models page देखें।
