Oh My Pi में मॉडल बदलते समय प्रगति कैसे बचाएँ: /model, /fork या /new

लंबे Oh My Pi session में मॉडल बदलना केवल response quality का सवाल नहीं है। पुराने provider की tool-call IDs, reasoning signatures, image blocks या दूसरे history fields ऐसे target API को दोबारा भेजे जा सकते हैं जो उन्हें स्वीकार नहीं करता।

सबसे सुरक्षित नियम है: code progress और session evidence को अलग-अलग save करें, फिर नए मॉडल को केवल उतनी history दें जितनी उसे सच में चाहिए। History compatible लगे तो /model उपयोग करें, reversible experiment के लिए /fork, और पुरानी history संदिग्ध हो तो /fork के बाद /clear या clean /new session चुनें।

स्विच करने से पहले दो checkpoints बचाएँ

Session transcript Git checkpoint का विकल्प नहीं है, और Git agent की reasoning trail नहीं बचाता। दोनों को सुरक्षित रखें।

1. Working tree की स्थिति दर्ज करें

पहले देखें कि वास्तव में क्या बदला है:

git status --short
git diff --stat

फिर local commit, patch या टीम द्वारा स्वीकार किया गया कोई recovery point बनाएँ। उद्देश्य अधूरा काम shared history में डालना नहीं है; उद्देश्य यह है कि अगला मॉडल गलत files बदल दे तो pre-switch state वापस मिल सके।

2. Session export करें

/export चलाएँ। Oh My Pi की official session operations reference के अनुसार यह session को बदले बिना HTML file बनाता है। Success signal वह path है जो terminal में दिखता है; TUI सामान्यतः file भी खोल देता है।

इस export को sensitive material मानें। HTML export में automatic secret redaction या encryption नहीं होती और इसमें raw context, images तथा extension payloads हो सकते हैं।

3. छोटा handoff file बनाएँ

Repository में temporary OMP-HANDOFF.md रखें और इसमें लिखें:

• मौजूदा objective और पूरा हुआ काम;
• बदली हुई files;
• चलाए गए checks और उनके results;
• अगला intended step;
• exact error, model, provider और API route।

Clean session को दर्जनों पुराने chat turns की जरूरत नहीं होती। Project instructions और यह छोटा handoff पढ़ाना अधिक नियंत्रित तरीका है।

History risk के अनुसार command चुनें

स्थिति	सुझाया गया रास्ता	क्या बचेगा	मुख्य सीमा
वही provider या निकट मॉडल, protocol error नहीं	/model	मौजूदा session और history	Target को पुरानी history मिलती रहेगी
दूसरा मॉडल आज़माना है और original session सुरक्षित रखना है	/fork → /model	Original और history वाला अलग fork	Incompatible history भी copy होगी
Original record रखना है, लेकिन पुराना model context नहीं भेजना	/fork → /clear → /model	Original intact; fork में reset boundary के बाद audit trail	Task intent handoff से वापस देना होगा
History पहले से 400 दे रही है या provider/protocol बदल रहा है	/new → /model	Working tree और पुराना session रहते हैं; नई conversation खाली	Todo, checkpoint और tool state अपने-आप transfer नहीं होते
केवल provider stream या server-side conversation फँसी है	/fresh	Visible और model-facing conversation दोनों बनी रहती हैं	Incompatible history नहीं हटती

रास्ता 1: History compatible हो तो /model

Oh My Pi README साफ कहता है कि /model active model को session के बीच बदल सकता है। इसे तभी चुनें जब existing context जरूरी हो और target provider द्वारा पुराने tool calls, reasoning blocks या multimodal content reject होने का संकेत न हो।

इस क्रम में काम करें:

1. Current response पूरा होने दें या उसे abort करें। Tools चल रहे हों तो switch न करें।
2. /model खोलें, target provider/model चुनें और active role को assign करें।
3. Oh My Pi picker या status में दिख रहे provider/model को verify करें। Model की self-reported identity को प्रमाण न मानें।
4. Read-only task दें, जैसे किसी known file को पढ़कर दो verifiable facts बताना।
5. एक छोटा tool task चलाएँ। Tool call, result और अगला model turn तीनों सही हों तभी लंबा काम जारी रखें।

पहला request ही HTTP 400 दे तो उसी history को बार-बार retry न करें। Error और export बचाएँ, फिर fork-and-clear या new-session path पर जाएँ।

रास्ता 2: Reversible experiment के लिए /fork

/fork current session से नई session file बनाता है और active identity को उस पर switch करता है। Official documentation के अनुसार full fork conversation और usage attribution बचाता है तथा artifacts directory को best effort पर copy करता है। Original session उपलब्ध रहता है, इसलिए model comparison और audit के लिए यह उपयोगी है।

लेकिन full fork पूरी history भी copy करता है। यदि error history में है, तो केवल /fork वही problem दोहराएगा।

अधिक सुरक्षित क्रम:

1. /fork चलाएँ और confirm करें कि नई session identity active है।
2. Fork के अंदर /clear चलाएँ।
3. /model से target model चुनें।
4. Model को project instructions और OMP-HANDOFF.md पढ़ाएँ।
5. Write permission देने से पहले read-only task से validate करें।

/clear live/model conversation context हटाता है, पर session ID, title, working directory, model settings और transcript file रखता है। यह reset_boundary जोड़ता है; persisted JSONL और full export में reset से पहले की history बनी रहती है। इस तरह evidence बची रहती है, लेकिन नए मॉडल को पुराना context नहीं भेजा जाता।

यदि /fork reject हो, streaming खत्म होने दें और सुनिश्चित करें कि session persistent है। Pure in-memory session में whole-session fork उपलब्ध नहीं होता।

रास्ता 3: पुरानी history unsafe हो तो /new

/new नई session identity और खाली conversation बनाता है। Official reference के अनुसार current model और settings बने रहते हैं, लेकिन conversation queues, todo, checkpoint, tool state, inherited cache identity और कुछ promoted memory context साफ हो जाते हैं। यदि model भी बदलना है, तो सामान्य क्रम /new के बाद /model है।

Reliable recovery flow:

1. Confirm करें कि export और working-tree checkpoint मौजूद हैं।
2. /new चलाएँ।
3. /model से target चुनें।
4. उसे project instructions, relevant files और OMP-HANDOFF.md पढ़ाएँ।
5. पहले read-only check, फिर एक minimal write कराएँ।
6. Result को pre-switch Git checkpoint और previous verification output से compare करें।

जब history replay requests तोड़ रही हो, यह repeated retries से तेज होता है। आप automatic chat context खोते हैं, repository नहीं। जरूरी facts code, tests, docs और handoff में होने चाहिए।

/fresh का मतलब history हटाना नहीं है

नाम भ्रम पैदा कर सकता है। Official session reference के अनुसार /fresh provider-facing stream state, cached provider-session handles और prompt-cache state reset करता है, लेकिन local transcript को नहीं बदलता। अगला turn local conversation से फिर बनता है; visible और model-facing conversation दोनों रहती हैं।

इसलिए:

• wedged stream, stale prompt cache या drifted server-side conversation ID के लिए /fresh आज़माएँ;
• पुराने tool-call IDs, reasoning signatures या images हटाने की उम्मीद न करें जिन्हें नया provider स्वीकार नहीं करता;
• किसी issue में “start a fresh session” सामान्य अंग्रेज़ी हो सकती है, Oh My Pi command /fresh नहीं। Empty history के लिए /new; original record रखते हुए context काटने के लिए /fork और /clear उपयोग करें।

दो वास्तविक 400 reports क्या सिखाती हैं

एक failure mode cross-provider tool-call IDs से जुड़ा है। Oh My Pi issue #15056 में reporter और maintainer ने reproduce किया कि Vertex/Gemini की signed tool-call ID OpenAI-compatible Chat Completions target को replay हुई। ID target की 64-character limit से लंबी थी, request HTTP 400 से fail हुई और invalid value history में बनी रही।

10 October 2026 तक issue open है और proposed fix वाला PR #15059 भी open है। Comment में “fix is up” लिखे होने से यह साबित नहीं होता कि installed version में fix है। Version या changelog check करें; नहीं तो clean history से recover करें।

दूसरा मामला, issue #15015, HAI proxy के माध्यम से Google 400 था और report ने historical thoughtSignature को कारण बताया। Maintainer ने स्पष्ट किया कि skip_thought_signature_validator unsigned functionCall parts के लिए जानबूझकर उपयोग होता है और Google public API को इसकी जरूरत है, जबकि उस proxy ने request Google तक पहुँचने से पहले reject किया। Issue wontfix label के साथ बंद हुआ।

निष्कर्ष यह नहीं कि हर Google switch टूटा है। एक ही 400 client-side history conversion या intermediary gateway से आ सकता है। Clean session, client update या proxy fix चुनने से पहले actual provider, model, api, endpoint, full error और history path रिकॉर्ड करें।

Custom OpenAI-compatible provider पर यही workflow

Oh My Pi ~/.omp/agent/models.yml में custom providers स्वीकार करता है, जिसमें api: openai-completions भी शामिल है। README /model में चयन से पहले omp models <provider> चलाकर discovery verify करने की सलाह देता है।

उदाहरण के लिए, BetterToken की official Chat Completions documentation https://www.bettertoken.ai/v1 को OpenAI-compatible Base URL और https://www.bettertoken.ai/v1/chat/completions को full request URL बताती है। Authentication user के अपने Bearer API Key से होती है, और model service का current full Model ID होना चाहिए।

इसे protocol-matching configuration candidate मानें, हर model, tool call या पुरानी history के लिए guarantee नहीं। /new में test करें: पहले बिना tools का छोटा request, फिर read-only tool request। Real API key protected credential configuration में रखें, chat, export या public log में नहीं।

Base URL या provider बदलना उस 400 को repair नहीं करता जो पहले से session history में है। पहले history isolate करें, फिर नए endpoint को अलग से validate करें।

लंबा काम दोबारा शुरू करने से पहले अंतिम जाँच

आगे तभी बढ़ें जब ये results दिखाई दें:

• /export ने controlled location में file बनाई है;
• working tree में recoverable pre-switch checkpoint है;
• चुना path लक्ष्य से मेल खाता है: same session, reversible fork, cleared context या new session;
• Oh My Pi intended provider/model दिखाता है;
• read-only tool task सफल है और result अगले turn तक पहुँचता है;
• original session /resume से मिल सकता है, या आपने उसे न रखने का स्पष्ट निर्णय लिया है;
• 400 के बाद error, version, provider, model, api और endpoint रिकॉर्ड हैं, retries के नीचे दबे नहीं।

निर्णय का नियम सीधा है: history जितनी valuable और स्पष्ट रूप से compatible हो, /model उतना उचित है। Cross-provider risk जितना अधिक हो, original session बचाकर clean context से आगे बढ़ना उतना जरूरी है।