लागत और सीमाएँ

OpenRouter Integration को दूसरे API Gateway पर कैसे Migrate करें

Requirements matrix, isolated credentials, protocol-specific endpoints, contract tests, controlled canary और स्पष्ट rollback triggers के साथ reversible OpenRouter migration plan करें।

BetterToken

संपादकीय टीम

10 अग॰ 202611 मिनट पढ़ने में

OpenRouter integration migrate करने का अर्थ production में एक साथ Base URL बदल देना नहीं है। पहले उस contract को दर्ज करें जिस पर application अभी निर्भर है: protocol, SDK method, Model ID, response schema, streaming behavior, tool calls, errors, retries और usage fields। इसके बाद isolated key और छोटे canary से candidate gateway की जाँच करें।

अगर मौजूदा OpenRouter integration ठीक चल रही है और उसका model catalog या routing behavior application के लिए महत्वपूर्ण है, तो वहीं रहना सही निर्णय हो सकता है। Primary route बदले बिना दूसरे gateway को tested backup के रूप में जोड़ना भी संभव है। Full migration तभी करें जब candidate workload से जुड़ी वही सभी checks पास कर ले।

इस tutorial में BetterToken को दूसरे gateway के एक verifiable example की तरह इस्तेमाल किया गया है। यह OpenRouter का clone नहीं है, और OpenAI-compatible label समान models, features, errors या usage data की guarantee नहीं देता।

पहले migration scenario चुनें

OpenRouter पर रहें, जब मौजूदा integration, billing path, model availability और operational behavior application की requirements पूरी करते हैं।
Tested backup जोड़ें, जब दूसरा route उपयोगी है, लेकिन primary integration बदलने की जरूरत नहीं है।
Migration canary चलाएँ, जब candidate gateway protocol और model requirements पूरी करता है और आप controlled traffic पर वास्तविक behavior compare करने के लिए तैयार हैं।

BetterToken OpenRouter accounts नहीं बेचता और OpenRouter keys या balance transfer नहीं कर सकता। Test के लिए अपना BetterToken account और API key बनाएँ, फिर Workspace या current documentation से मौजूदा Model ID और key requirements लें।

Configuration छूने से पहले requirements matrix बनाएँ

“OpenAI-compatible” interface के एक हिस्से को बताता है, service के पूरे behavior को नहीं। दो gateways समान requests स्वीकार कर सकते हैं, फिर भी available models, streaming events, tool-call payloads, error bodies, retry headers, rate limits या usage accounting में अलग हो सकते हैं।

Candidate test करने से पहले हर requirement का current behavior और acceptance criterion लिखें।

Requirement	Current OpenRouter contract	Candidate से जुटाने वाला evidence	Acceptance question
Protocol और method	Production में इस्तेमाल exact endpoint और SDK method	Documented protocol तथा production SDK से successful request	क्या client वही API shape call करता है?
Model	Current Model ID और required capabilities	Live catalog या Setup से current candidate Model ID	क्या required model या approved substitute अभी उपलब्ध है?
Authentication	Environment variable, header और secret-loading path	Isolated test key और documented authentication field	क्या key को code और logs से बाहर रखा जा सकता है?
Base URL behavior	Client resource paths append करता है या नहीं	Test में देखा गया effective candidate URL	जहाँ जरूरी है, क्या `/v1` ठीक एक बार जुड़ता है?
Response schema	Application द्वारा parse किए जाने वाले fields	Saved non-sensitive response structure	क्या existing parser इसे सुरक्षित रूप से पढ़ सकता है?
Streaming	Event format, finish signal और disconnect handling	Timestamps वाला complete streamed test	क्या stream बिना content खोए या duplicate किए पूरा होता है?
Tool calls	Tool name, arguments, IDs और result flow	Controlled tool-call test	क्या arguments और identifiers सुरक्षित रहते हैं?
Errors	Status, body, request ID और retry metadata	Invalid-key और invalid-model tests	क्या application terminal और retryable errors अलग कर सकता है?
Usage	Input, cached input, output और अन्य consumed units	SDK response, application log और provider record	क्या billing और alerts के लिए usage पर्याप्त रूप से reconcile होता है?
Reliability	Timeout, retry और concurrency behavior	Representative load पर canary observations	क्या route application की operational threshold पूरी करता है?
Rollback	Current route, configuration और deployment procedure	Tested switch-back action	क्या side effects replay किए बिना new traffic पुराने route पर लौट सकता है?

केवल model count देखकर gateway न चुनें। असली सवाल यह है कि इस application के लिए जरूरी current Model ID और response contract काम करते हैं या नहीं। Model availability और prices dynamic हैं, इसलिए migration के समय provider का current catalog और rate card पढ़ें।

Scenario 1: OpenRouter पर रहें

जब हल करने के लिए कोई concrete gap न हो, तो मौजूदा route पर रहें। अगर application OpenRouter के current catalog, routing, headers या response behavior पर निर्भर है, तो migration किसी बराबर benefit के बिना नए failure modes जोड़ सकती है।

फिर भी future portability के लिए तैयारी की जा सकती है:

Base URL, API key और Model ID को configuration में ले जाएँ;
application द्वारा इस्तेमाल response और error fields document करें;
provider-specific headers को shared request logic से अलग रखें;
isolated key पर चलने वाले contract tests जोड़ें;
rollback owner और allowed retry policy लिखें।

इससे production traffic बदले बिना आगे की migration का risk कम होता है।

Scenario 2: Tested backup जोड़ें

Backup route तभी उपयोगी है, जब वह primary route जैसे contract tests पास कर चुका हो। Provider configurations अलग रखें; सिर्फ दूसरी request के सफल होने का प्रमाण पाने के लिए OpenRouter settings overwrite न करें।

ठीक-ठीक तय करें कि कौन-सी failures fallback के योग्य हैं। Authentication failures, invalid Model IDs, unsupported methods, malformed requests और अधिकांश दूसरे client errors को अपने-आप किसी दूसरे provider के जरिए retry नहीं करना चाहिए। Transient failures में भी fallback idempotency, retry limits, timeout budgets और candidate feature support की सीमाओं में रहना चाहिए।

एक ही mutating operation दो gateways पर न भेजें, जब तक application में verified idempotency mechanism न हो और destination state confirm न किया जा सके। Backup हर request के पूरा होने या identical output की guarantee नहीं देता।

Scenario 3: Canary से migrate करें

Canary तब इस्तेमाल करें, जब candidate isolated tests पास कर चुका हो और primary route बदलना लक्ष्य हो। पहले non-critical traffic का केवल छोटा, controlled हिस्सा भेजें। Observation window और rollback checks पूरी होने तक current route उपलब्ध रखें।

Canary शुरू होने से पहले success तय करें:

expected response schema fallback code के बिना parse होता है;
required streaming और tool-call behavior पास होता है;
error types classify किए जा सकते हैं;
usage records application की accepted boundary में reconcile होते हैं;
latency, timeout और retry behavior defined threshold पूरा करते हैं;
duplicate या missing side effects नहीं आते।

कोई required condition fail हो, तो expansion रोकें और new traffic को known-good configuration पर वापस भेजें।

पाँच चरणों की migration प्रक्रिया

चरण 1: Current contract की inventory बनाएँ

Exact protocol, SDK और method, OpenRouter Base URL, Model ID, authentication variable, provider-specific headers, streaming mode, tool use, timeout policy, retry policy, error fields, request ID और usage fields दर्ज करें।

तय करें कि कौन-से items hard requirements हैं और कौन बदल सकते हैं। Logging field replace हो सकता है; production automation में इस्तेमाल tool-call contract शायद नहीं।

Worksheet में API keys copy न करें। केवल secret का variable name और storage location दर्ज करें।

चरण 2: Isolated candidate configuration बनाएँ

Candidate gateway पर अलग test key बनाएँ। Production key reuse न करें और secrets repository में commit न करें।

BetterToken के लिए अपना account इस्तेमाल करें और Workspace या current API documentation में दिखाए गए current Model ID और key requirements चुनें। पुराने tutorial से Model ID hardcode न करें।

Candidate configuration को current OpenRouter configuration के साथ अलग रखें, उसके ऊपर overwrite न करें। यह separation comparison और rollback संभव बनाता है।

चरण 3: Protocol-specific Base URL सेट करें

OpenAI-compatible BetterToken client के लिए इस्तेमाल करें:


TEST_API_KEY=your_test_api_key_here
TEST_BASE_URL=https://www.bettertoken.ai/v1?utm_source=blog&utm_medium=organic_content&utm_campaign=SEO-088&utm_content=analog-openrouter-v-rossii-vybor-i-perenos-api
TEST_MODEL_ID=current_model_id_from_provider_catalog

Anthropic-compatible client के लिए BetterToken Base URL https://bettertoken.ai है, जिसमें /v1 नहीं है। OpenAI-compatible Python request shape को Anthropic-compatible client में reuse न करें; उस path के SDK और protocol documentation का पालन करें।

Confirm करें कि client versioned Base URL चाहता है या path का कुछ हिस्सा खुद append करता है। Duplicate या missing /v1 configuration error है, पूरे gateway के unavailable होने का प्रमाण नहीं।

चरण 4: वही minimal request और contract tests चलाएँ

Application वाला ही SDK family और method इस्तेमाल करें। यह Python example environment variables के साथ OpenAI-compatible Chat Completions request test करता है:


import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["TEST_API_KEY"],
    base_url=os.environ["TEST_BASE_URL"],
)

response = client.chat.completions.create(
    model=os.environ["TEST_MODEL_ID"],
    messages=[{"role": "user", "content": "Reply with: gateway test passed"}],
    max_tokens=32,
)

print(response.choices[0].message.content)
print(response.usage)

Placeholders जानबूझकर रखे गए हैं। Real key को project के secret mechanism से load करें और test के समय provider से current Model ID लें।

Basic request के बाद streaming, tool calls, invalid authentication और invalid Model ID के अलग tests चलाएँ, अगर production application इन behaviors पर निर्भर है। Non-sensitive evidence दर्ज करें: timestamp, status, उपलब्ध होने पर request ID, response shape, usage fields और application result।

चरण 5: Canary भेजें, तुलना करें और निर्णय लें

Non-critical traffic का controlled हिस्सा candidate को route करें। Representative window में दोनों routes compare करें:

success और classified error counts;
latency distribution और timeout behavior;
retry count और उपलब्ध होने पर Retry-After handling;
response और tool-call schemas;
streaming completion;
input, cached input और output usage;
provider-side status और charge records;
duplicate, missing या delayed side effects।

हर hard requirement पास होने के बाद ही traffic बढ़ाएँ। Rollback trigger आए तो new traffic OpenRouter पर लौटाएँ और candidate की offline जाँच करें।

Successful response से आगे की validation करें

Successful HTTP status केवल यह बताता है कि एक request लौटी। यह protocol equivalence, production readiness या सही routing साबित नहीं करता।

Errors को जानबूझकर validate करें

Isolated test key से controlled failures trigger करें:

invalid Model ID;
revoked या जानबूझकर invalid test key;
safe होने पर unsupported method;
non-production environment में timeout।

HTTP status, error body, request ID, retry metadata और client behavior जाँचें। सुनिश्चित करें कि terminal errors अनंत बार retry न हों और logs credentials तथा sensitive request content redact करें।

OpenRouter error reference OpenRouter behavior document करती है। Candidate की current documentation और observed response को अलग contract मानें।

Usage reconcile करें

SDK से लौटे usage object को application log और provider account record से compare करें। Required fields में input tokens, cached input, output tokens या provider-specific units शामिल हो सकते हैं।

BetterToken Dashboard request time, model, status, input, output, cache tokens और corresponding charge दिखा सकता है। इसका अर्थ यह नहीं कि complete prompts या responses store या display होते हैं। Record को test time और दूसरे non-secret metadata से match करें; successful reply से route assume न करें।

Streaming और tool calls अलग से test करें

Streaming के लिए first event, content deltas, finish reason, उपलब्ध होने पर final usage, disconnect handling और partial answer तथा completed answer के फर्क को verify करें।

Tool calls के लिए tool name, call ID, serialized arguments, validation failures और result submission flow compare करें। पहले test में read-only tool इस्तेमाल करें। Normal text response से tool-call path compatibility साबित नहीं होती।

Rollback की सीमाएँ

Canary से पहले rollback को explicit और reversible रखें।

इनमें से कोई hard requirement fail हो तो तुरंत rollback करें:

application response या error schema parse नहीं कर पाता;
required stream अधूरा खत्म होता है;
tool-call arguments या IDs corrupt होते हैं;
required billing controls के लिए usage reconcile नहीं होता;
timeout या error behavior agreed operational threshold तोड़ता है;
mutating workflow uncertain, duplicated या missing result देता है।

Rollback करते समय:

candidate traffic बढ़ाना रोकें;
new requests को known-good OpenRouter configuration पर भेजें;
unknown outcome वाले mutating requests अपने-आप replay न करें;
diagnosis के लिए timestamps, request IDs, status codes और redacted logs सुरक्षित रखें;
कारण समझ आने तक candidate key isolated रखें, फिर जरूरत न हो तो revoke करें।

Migration owner के observation window, rollback test और downstream reconciliation confirm करने तक old configuration या credentials delete न करें। दोनों routes active रहें, तो ownership, health checks, eligible fallback errors और maximum retry budget document करें।

Cost और operational checks

Migration runbook में fixed prices न लिखें। Test date पर हर provider का current rate card पढ़ें और actual recorded usage से तुलना करें।

Decision में ये items शामिल करें:

model और feature availability;
input, cached input और output rates;
payment के समय दिखने वाली minimum funding या account requirements;
request और concurrency limits;
timeout और retry behavior;
usage export या Dashboard visibility;
key rotation और per-project control;
support और incident escalation paths।

BetterToken के लिए पुराने screenshot या copied rate के बजाय current pricing page और Workspace इस्तेमाल करें। Service केवल एक candidate gateway है; यह साबित नहीं करती कि हर OpenRouter workload बिना बदलाव migrate हो सकता है।

अंतिम decision checklist

OpenRouter पर रहें, जब:

कोई concrete integration या operational gap नहीं है;
current catalog और contract जरूरी हैं;
candidate ने कोई hard requirement पास नहीं की है।

Backup जोड़ें, जब:

second route की स्वतंत्र value है;
उसने वही protocol, error, usage और feature tests पास किए हैं;
fallback rules bounded और observable हैं।

Migrate करें, जब:

candidate हर hard requirement पूरी करता है;
canary accepted error और latency thresholds में रहता है;
usage और billing records reconcile होते हैं;
rollback test हो चुका है और अभी भी काम करता है।

OpenAI-compatible label test plan की शुरुआत है, complete equivalence का evidence नहीं। सबसे सुरक्षित migration isolated, observable, incremental और reversible होती है।

अगर BetterToken आपकी integration के लिए candidate है, तो current API documentation से शुरू करें, अलग test key बनाएँ और production traffic बदलने से पहले पाँच चरणों वाला canary चलाएँ।

Sources

अपना LLM वर्कफ़्लो बेहतर बनाना चाहते हैं?

एक API से मॉडल जोड़ें, कुंजियाँ प्रबंधित करें और AI खर्च नियंत्रित करें।