Cherry Studio में खर्च कैसे देखें: Requests, Token अनुमान और वास्तविक कटौती

Cherry Studio में चित्र बन चुका है, लेकिन Requests की Cost खाली है या उसमें डैश दिख रहा है—इसका मतलब यह नहीं कि वह मुफ़्त था। रकम दिखे तो भी उसे सीधे प्रदाता का बिल न मानें। पहले सेटिंग्स → उपयोग → अनुरोध (Settings → Usage → Requests) में संबंधित रिकॉर्ड खोजें, फिर लागत का स्रोत, बिलिंग इकाई और खाते से हुई वास्तविक कटौती जाँचें। इससे पता चलेगा कि दर दर्ज नहीं है, क्लाइंट अनुमान नहीं लगा पा रहा है या दोनों ओर अलग-अलग कॉल गिनी जा रही हैं।

मौजूदा अनुरोध और बिलिंग रिकॉर्ड संभालकर रखें; सिर्फ़ Cost में कोई अंक दिखाने के लिए बार-बार चित्र बनाने की ज़रूरत नहीं है। नीचे दिए गए इंटरफ़ेस और गणना के विवरण आधिकारिक रिलीज़ के सोर्स कोड और मर्ज किए गए बदलावों पर आधारित हैं। वे बताते हैं कि क्लाइंट लागत कैसे दर्ज करता है; उनसे किसी खास प्रदाता, मॉडल और खाते के संयोजन की वास्तविक कॉल से पुष्टि नहीं होती।

पहले संस्करण देखें: प्रति-चित्र मूल्य का विकल्प मर्ज हुआ है, पर रिलीज़ मान लेना सही नहीं

2026-10-17 तक आधिकारिक latest रिलीज़ v2.1.6 है; प्रति-चित्र मूल्य दर्ज करने वाला PR #21892 उसी दिन main में मर्ज हुआ। main विकास शाखा है। किसी बदलाव का उसमें मर्ज होना यह साबित नहीं करता कि आपके इंस्टॉल किए गए स्थिर संस्करण में वह सुविधा आ गई है। देखें: आधिकारिक रिलीज़ और प्रति-चित्र मूल्य वाला PR।

2026-10-16 को codeBennyLaw ने Windows v2.1.6 के लिए Issue #21870 में बताया कि मॉडल की मूल्य सेटिंग्स में केवल प्रति दस लाख Token वाले फ़ील्ड थे और कुछ चित्र अनुरोधों की Cost में डैश दिख रहा था। यह उस उपयोगकर्ता के परिवेश का विवरण है; इससे यह निष्कर्ष नहीं निकलता कि सभी चित्र मॉडल मुफ़्त हैं। PR मर्ज होने के साथ Issue बंद हो गया है, लेकिन अपने इंटरफ़ेस का आकलन करते समय इंस्टॉल किया गया संस्करण ही देखें।

आपके सामने कौन-सा इंटरफ़ेस है	उसमें क्या कर सकते हैं	अगला कदम
v2.1.6 का मॉडल मूल्य संपादक	इनपुट, आउटपुट, कैश Token की दरें और इनपुट-आधारित मूल्य स्तर बदल सकते हैं; प्रति-चित्र मूल्य फ़ील्ड नहीं है	Token के हिसाब से बिल होने वाले मॉडल की Token दरें जाँचें; प्रति-चित्र बिलिंग के लिए प्रदाता के रिकॉर्ड से मिलान करें
ऐसा बिल्ड जिसमें PR #21892 शामिल है और Price unit तथा Image price वास्तव में दिखते हैं	हर जनरेट हुए चित्र की कीमत दर्ज कर सकते हैं	पहले प्रदाता की प्रति-चित्र बिलिंग की पुष्टि करें, फिर सही दर भरकर नए अनुरोध से जाँचें
नया या कस्टम बिल्ड जिसका इंटरफ़ेस अलग है	सुविधाएँ उस बिल्ड पर निर्भर हैं	उसके विवरण और वास्तविक फ़ील्ड देखें; दूसरे संस्करण के स्क्रीनशॉट से सेटिंग्स का अनुमान न लगाएँ

इस तुलना के आधार हैं v2.1.6 का मूल्य संपादक और मर्ज किए गए संस्करण का मूल्य संपादक। आगे विकल्प पहचानने के लिए अंग्रेज़ी इंटरफ़ेस के नाम दिए गए हैं; क्लाइंट की भाषा के अनुसार लेबल बदल सकते हैं।

Requests में उसी अनुरोध को खोजें

रकम की तुलना करने से पहले सुनिश्चित करें कि दोनों रिकॉर्ड एक ही अनुरोध के हैं। क्लाइंट का संस्करण, उस समय चुना गया प्रदाता कॉन्फ़िगरेशन, सटीक मॉडल ID और उसी प्रदाता खाते का उपयोग या कटौती रिकॉर्ड तैयार रखें। मॉडल का दिखाई देने वाला नाम एक जैसा होना, मॉडल या बिलिंग चैनल एक जैसा होने का प्रमाण नहीं है।

1. Settings → Usage → Requests खोलें। उस अनुरोध को शामिल करने वाली समय सीमा चुनें और Date के अनुसार रिकॉर्ड खोजें।
2. हर पंक्ति में मॉडल का नाम और उसके नीचे प्रदाता का नाम देखें। Source बताता है कि कॉल किस असिस्टेंट, सत्र या सुविधा से आई थी; यह लागत का स्रोत नहीं है।
3. तारीख और समय, Tokens, Cost तथा मुद्रा नोट करें। रिकॉर्ड न मिले तो पहले फिर से Date के अनुसार क्रम लगाएँ, समय सीमा जाँचें और सूची के नीचे अधिक रिकॉर्ड लोड करने का विकल्प इस्तेमाल करें। Cost के अनुसार क्रम लगाने पर चुनी गई मुद्रा का फ़िल्टर भी लागू होता है; इसलिए बिना लागत वाले रिकॉर्ड परिणामों से बाहर हो सकते हैं।
4. प्रदाता के उसी समय के रिकॉर्ड भी सुरक्षित रखें। क्लाइंट का रिकॉर्ड कॉल पूरी होने के समय का होता है। प्रदाता का लेखांकन समय और समय क्षेत्र अलग हो सकता है, इसलिए शुरुआत में ऐसी समय सीमा रखें जिसमें पूरी कॉल शामिल हो।

फ़ील्ड और उनके प्रदर्शन के लिए Requests तालिका का आधिकारिक कोड तथा रिकॉर्ड लिखने का तर्क देखें।

पूरी सूची खाली हो तो पहले समय सीमा, रिकॉर्ड लोड होने की स्थिति और कॉल पूरी होने की जाँच करें। केवल Cost गायब हो तो कीमत और लागत के स्रोत की जाँच आगे बढ़ाएँ। दोनों स्थितियों के अगले कदम अलग हैं; केवल ऐप फिर से इंस्टॉल करना या इतिहास मिटाना यह नहीं बताएगा कि प्रदाता ने पैसे काटे थे या नहीं।

Cost की तीन स्थितियाँ हैं; Source कॉलम से उनका पता नहीं चलता

रकम कितनी सटीक दिखती है, उससे ज़्यादा अहम है कि वह आई कहाँ से है। आधिकारिक रिकॉर्डिंग तर्क पहले शर्तें पूरी करने वाली प्रदाता की लागत स्वीकार करने की कोशिश करता है। वह उपलब्ध न हो तो अनुरोध के समय सुरक्षित की गई दरों से अनुमान लगाता है। दोनों रास्ते उपलब्ध न हों तो लागत खाली रहती है। देखें: लागत दर्ज करने का तर्क।

रिकॉर्ड की स्थिति	उसका अर्थ	मिलान में उसका उपयोग
costSource का मान provider है	क्लाइंट ने प्रदाता द्वारा लौटाई गई लागत स्वीकार की; प्रदाता की क्षमता संबंधी घोषणा, रकम और मुद्रा की शर्तें पूरी होनी चाहिए	इसे उस प्रतिक्रिया के साथ आई लागत मानें, फिर भी खाते की वास्तविक कटौती से मिलाएँ
costSource का मान computed है	क्लाइंट ने उपयोग और उस समय की कीमतों के स्नैपशॉट से रकम निकाली	अनुमान और रुझान देखने में उपयोग करें; स्थानीय दरें वास्तविक खाते से मेल खाती हैं या नहीं, जाँचें
Cost और उसका स्रोत खाली हैं	न उपयोग योग्य प्रदाता की रकम मिली, न स्थानीय गणना पूरी हो सकी	रकम अज्ञात है; वास्तविक कटौती प्रदाता के रिकॉर्ड में देखें, इसे शून्य न मानें

v2.1.6 में गायब Cost - के रूप में दिखती है। जाँचे गए main की अंग्रेज़ी भाषा में Unable to estimate दिखता है। मौजूदा Requests तालिका में अलग costSource कॉलम या लागत-स्रोत का टूलटिप नहीं है। Source को उसका विकल्प न समझें और केवल रकम देखकर उसका स्रोत न तय करें। इंटरफ़ेस स्रोत स्पष्ट न करे तो उसे फिलहाल अस्पष्ट ही दर्ज करें। देखें: main की तालिका और अंग्रेज़ी लेबल।

प्रदाता के प्रतिक्रिया डेटा में कोई लागत फ़ील्ड होना भी उसके स्वीकार होने की गारंटी नहीं है। क्लाइंट यह भी देखता है कि प्रदाता वास्तविक बिल की रकम लौटाने की क्षमता घोषित करता है या नहीं, और मुद्रा तय हो सकती है या नहीं। इसके लिए आपको अंदरूनी रिकॉर्ड बदलने की ज़रूरत नहीं है; वास्तविक कटौती का मिलान आखिरकार प्रदाता के खाते से ही होगा। देखें: लागत का आधिकारिक विवरण।

Token से लागत का अनुमान: पहले इकाई, फिर उपयोग की श्रेणियाँ जाँचें

Requests का Tokens कुल उपयोग दिखाता है; उसे किसी एक समान दर से सीधे गुणा नहीं कर सकते। computed का अर्थ केवल इतना है कि रकम क्लाइंट ने गणना करके निकाली। इसका अर्थ यह नहीं कि Token की संख्या भी स्थानीय अनुमान है। कुल संख्या निकालने वाला आधिकारिक फ़ंक्शन पहले totalTokens इस्तेमाल करता है; वह न मिले तो उपलब्ध इनपुट और आउटपुट गिनती जोड़ता है। दोनों अज्ञात हों तो मान खाली रहता है। देखें: Token के कुल उपयोग की परिभाषा।

Settings → Model Provider → प्रदाता चुनें → संबंधित मॉडल का गियर आइकन → More settings में मूल्य क्षेत्र खोलें। उसी खाते, मॉडल और मूल्य स्तर की मौजूदा दरों से इन फ़ील्ड का मिलान करें:

• Input Price / Output Price: क्रमशः प्रति दस लाख इनपुट और आउटपुट Token की दर। प्रदाता प्रति हज़ार Token की दर देता हो तो उसे पहले प्रति दस लाख में बदलें; सिर्फ़ संख्या कॉपी न करें।
• Cache Read Price / Cache Write Price: कैश से पढ़ने और कैश में लिखने की दरें अलग जाँचें। मौजूदा संपादक में फ़ील्ड खाली होने पर उस स्तर की इनपुट दर लागू होती है। 0 दर्ज करने का अर्थ है कि स्थानीय गणना उस श्रेणी की दर शून्य मानेगी; खाली फ़ील्ड का अर्थ मुफ़्त नहीं है।
• मूल्य स्तर: इनपुट की लंबाई के आधार पर अलग दरें हों तो क्लाइंट पूरी इनपुट संख्या से एक स्तर चुनता है और वही पूरी कॉल पर लागू करता है। यह बिजली के स्लैब की तरह अलग-अलग हिस्सों पर क्रमिक दरें नहीं लगाता। आवश्यक उपयोग या दरें गायब हों तो अनुमान अभी भी खाली रह सकता है।

फ़ील्ड और सहेजने का तरीका मूल्य संपादक में और गणना का आधार लागत के विवरण में दिया गया है।

मिलान के एक ही रिकॉर्ड में श्रेणीवार संख्या और दर रखें: बिना कैश वाला इनपुट × इनपुट दर + कैश पढ़ने की संख्या × पढ़ने की दर + कैश लिखने की संख्या × लिखने की दर + आउटपुट × आउटपुट दर। हर भाग को प्रति दस लाख Token की इकाई में बदलकर गणना करें। इनपुट कुल में कैश पहले से शामिल हो तो उसे पहले अलग करें; कैश की संख्या को सामान्य इनपुट में दोबारा न जोड़ें। रीजनिंग Token आउटपुट में शामिल हों तो उन्हें भी दोबारा न जोड़ें। श्रेणीवार संख्या न मिले तो उसे अज्ञात दर्ज करें; कुल Tokens से किसी सटीक बिल का अनुमान न गढ़ें।

मुद्रा भी अलग पहचानें: जाँचे गए मूल्य संपादक में $ का अर्थ USD और ¥ का अर्थ CNY है, JPY नहीं। प्रतीक बदलने से विनिमय दर के अनुसार रकम परिवर्तित नहीं होती। यदि रिचार्ज या बैंक स्टेटमेंट आपकी स्थानीय मुद्रा में हो, लेकिन मॉडल की दर अमेरिकी डॉलर में हो, तो पहले डॉलर में कॉल की लागत मिलाएँ। उसके बाद रिचार्ज की विनिमय दर और शुल्क अलग जाँचें; अलग मुद्राओं की रकम सीधे न जोड़ें। देखें: मुद्रा मैपिंग और कीमत सहेजने का कोड।

दर बदलने के बाद इनपुट फ़ील्ड से बाहर क्लिक करें और उसी मॉडल को फिर खोलकर पुष्टि करें कि मान सहेज लिया गया है। यह भी जाँचें कि प्रदाता के लिए कोई मूल्य गुणक या समय-आधारित दर नियम तो नहीं लगा है, ताकि गुणक शामिल कर चुकी वास्तविक दर पर उसे फिर से लागू न कर दें। पुराने अनुरोध अपने मूल मूल्य-स्नैपशॉट का उपयोग करते हैं; आज कीमत बदलने से उनकी रकम स्वतः नहीं बदलती। देखें: गुणक और समय-आधारित नियम और अनुरोध के समय लिया गया मूल्य-स्नैपशॉट।

चित्र की Cost खाली है? पहले प्रति-अनुरोध और प्रति-चित्र बिलिंग में अंतर करें

प्रति अनुरोध, प्रति चित्र और चित्र-संबंधी Token के हिसाब से शुल्क लेना अलग बिलिंग नियम हैं। एक अनुरोध कई चित्र लौटा सकता है। प्रति अनुरोध की तय रकम को हर चित्र की दर बनाकर न भरें, और उसे Input Price या Output Price में भी न डालें।

v2.1.6 में अंदरूनी गणना प्रति-चित्र लागत की शर्तें पहचानती है, लेकिन डेस्कटॉप मूल्य संपादक में उसका फ़ील्ड नहीं है। स्थानीय गणना के लिए रनटाइम के मूल्य-स्नैपशॉट में perImage होना चाहिए, उसका unit image होना चाहिए और कॉल से imageCount मिलना चाहिए। केवल Token की दर या pixel इकाई पर्याप्त नहीं है। देखें: चित्र लागत की गणना की शर्तें।

आपके बिल्ड में नया विकल्प वास्तव में दिखता हो और प्रदाता स्पष्ट रूप से जनरेट हुए चित्रों की संख्या के हिसाब से बिल करता हो, तो इस तरह सेट करें:

1. उसी प्रदाता और मॉडल के मूल्य क्षेत्र में Price unit को Image पर बदलें।
2. Image price में सही मुद्रा की प्रति-चित्र दर भरें। फ़ील्ड से बाहर आने पर बदलाव स्वतः सहेजा जाता है; मॉडल फिर खोलकर उसकी पुष्टि करें।
3. कीमत अज्ञात हो तो फ़ील्ड खाली रखें। दर वास्तव में शून्य हो तभी 0 भरें। अपनी ओर से शून्य दर्ज करने पर स्थानीय प्रदर्शन बदलेगा, प्रदाता की कटौती बंद नहीं होगी।
4. यह विकल्प केवल तय करता है कि आप कौन-सी दर संपादित कर रहे हैं; Token और चित्र, दोनों की दरें सुरक्षित रहती हैं। इसमें नया “प्रति अनुरोध तय शुल्क” मोड नहीं जुड़ा है, न ही यह प्रति पिक्सेल या चित्र Token की लागत का अनुमान हल करता है।
5. कीमत बदलने के बाद एक नई जनरेशन से मिलान करें। परिणाम मिलने पर लौटे चित्रों की वास्तविक संख्या, अनुरोध का समय और नई Cost नोट करें, फिर प्रदाता का रिकॉर्ड देखें। स्थानीय गणना “जनरेट हुए चित्रों की संख्या × अनुरोध के समय लागू प्रति-चित्र दर” पर आधारित होनी चाहिए, साथ में लागू प्रदाता गुणक या समय-आधारित नियम भी देखें। जाँच के लिए भेजा गया नया अनुरोध भी शुल्क वाला हो सकता है; बेहतर है कि आप अपनी अगली आवश्यक जनरेशन से ही जाँच करें।

ये कदम नए मूल्य संपादक और कीमत सहेजने वाले फ़ंक्शन पर आधारित हैं। विकल्प न दिखे तो पहले प्रदाता के वास्तविक रिकॉर्ड से मिलान करें। जब आपके इंस्टॉल किए गए स्थिर संस्करण में वह सुविधा स्पष्ट रूप से शामिल हो, तभी यह कॉन्फ़िगरेशन करें।

चित्र की दर भरने के बाद भी नए अनुरोध में Cost गायब हो सकती है। कॉल किसी दूसरे मॉडल कॉन्फ़िगरेशन से गई हो, चित्रों की गिनती न मिली हो, मुद्रा की जानकारी अधूरी हो या वास्तविक बिलिंग प्रति-चित्र न हो—हर स्थिति अलग जाँचें। आधिकारिक कस्टम चित्र-कार्य वाला रास्ता लौटे चित्र URL की संख्या को imageCount में दर्ज करता है। इसलिए अपने कंप्यूटर पर सफलतापूर्वक डाउनलोड हुई फ़ाइलों की संख्या को उसका सीधा विकल्प न बनाएँ। यह गिनती हर प्रदाता की बिलिंग गिनती से मेल खाने की गारंटी भी नहीं है। देखें: चित्र-कार्य के रिकॉर्ड का कोड।

वास्तविक कटौती से मिलान करें और अंतर समझाने वाला रिकॉर्ड सहेजें

पहले एक पूरे हुए अनुरोध को मिलाना, दोनों ओर के मासिक कुल की सीधी तुलना से आसान है। एक ही प्रदाता खाते का उपयोग करें। Key के लेबल या समूह से पहचान कर सकते हों तो वह भी नोट करें, लेकिन स्क्रीनशॉट या सहायता के लिए भेजी गई जानकारी में पूरी कुंजी न रखें।

क्या सहेजना है	Cherry Studio की ओर	प्रदाता की ओर
पहचान	क्लाइंट संस्करण, प्रदाता कॉन्फ़िगरेशन, मॉडल का दिखाई देने वाला नाम और सटीक ID	वास्तविक खाता, मॉडल ID, लागू मूल्य स्तर
समय	अनुरोध पूरा होने का समय और स्थानीय समय क्षेत्र	लेखांकन समय, समय क्षेत्र और उसी कॉल को शामिल करने वाली सीमा
मात्रा	दिखने वाले Tokens; चित्र-कार्य से वास्तव में लौटे चित्रों की संख्या	इनपुट, आउटपुट, कैश जैसी श्रेणियों का उपयोग और बिल किए गए अनुरोधों या चित्रों की संख्या
रकम	Cost, मुद्रा और खाली मान ज्यों के त्यों	वास्तविक कटौती, मुद्रा और दिखाई देने वाली वापसी या समायोजन
संबंध	अनुरोध किस सत्र या सुविधा से आया	प्रदाता द्वारा दिया गया अनुरोध या बिलिंग पहचानकर्ता

दोनों ओर स्पष्ट रूप से एक ही प्रदाता अनुरोध ID मिले तो पहले उसी से मिलाएँ। अन्यथा खाते, मॉडल, समय सीमा और मात्रा को साथ लेकर जाँचें। Cherry Studio के अंदरूनी अनुरोध पहचानकर्ताओं का अपना नामकरण है; उन्हें प्रदाता का ID न मान लें। देखें: आधिकारिक रिकॉर्ड संरचना।

यदि आप पहले से BetterToken इस्तेमाल कर रहे हैं, तो आधिकारिक उपयोग संबंधी जानकारी के अनुसार कंसोल में मौजूदा उपयोग और कटौती का इतिहास देख सकते हैं। फिर पेज पर वास्तव में उपलब्ध फ़ील्ड के आधार पर मॉडल, समय, स्थिति और Token का मिलान करें।

रकम मेल न खाए तो इस क्रम में आगे बढ़ें:

• पहले मात्रा ही अलग है: देखें कि वही खाता दूसरे टूल में भी इस्तेमाल हो रहा है या एक कार्रवाई में कई कॉल हुई थीं। क्लाइंट को दिखाई न देने वाले SDK पुनःप्रयास Requests में दर्ज हों, यह ज़रूरी नहीं है। दोनों ओर की प्रविष्टियाँ स्वाभाविक रूप से एक-से-एक हों, ऐसी अपेक्षा न रखें।
• मात्रा समान, रकम अलग है: मॉडल, प्रति-चित्र/प्रति-अनुरोध/Token इकाई, कैश नियम, मूल्य स्तर, मुद्रा, गुणक और खाते की वास्तविक दर देखें। फिर अनुरोध के समय का पुराना मूल्य-स्नैपशॉट जाँचें।
• प्रदाता ने पैसे काटे, लेकिन क्लाइंट की Cost खाली है: उसे खाली ही रखें और संबंधित रकम के साथ दर्ज करें, “क्लाइंट अनुमान नहीं लगा सका; प्रदाता ने शुल्क लिया।” खाली मान अपनी ओर से शून्य न करें।
• क्लाइंट में रिकॉर्ड नहीं है या विफलता दिखती है, लेकिन प्रदाता के पास रिकॉर्ड है: पहले प्रदाता के पूरा होने, शुल्क और वापसी के नियम स्पष्ट करें। संवेदनशील जानकारी हटाकर समय, मॉडल और प्रदाता अनुरोध पहचानकर्ता दें; समस्या दोहराने के लिए तुरंत अनुरोधों का एक और बैच न भेजें।

आधिकारिक दस्तावेज़ इन उपयोग रिकॉर्ड को ऐसे विश्लेषण डेटा के रूप में परिभाषित करते हैं जिसे क्लाइंट यथासंभव दर्ज करता है। उसके दायरे से बाहर के पुनःप्रयास, विफलताएँ और पुराने माइग्रेट किए गए रिकॉर्ड मात्रा की तुलना को प्रभावित कर सकते हैं। वास्तविक कटौती के लिए प्रदाता का रिकॉर्ड आधार है। उसमें कुछ स्पष्ट न हो तो प्रदाता से स्पष्टीकरण लें; Cost के खाली खाने से उत्तर नहीं निकलेगा। देखें: रिकॉर्डिंग का दायरा और सीमाएँ।

मिलान कब पूरा माना जाए

आपके पास उसी अनुरोध के दोनों ओर के रिकॉर्ड होने चाहिए और आप तीन बातें समझा सकें: कौन-सा मॉडल और बिलिंग इकाई इस्तेमाल हुई, क्लाइंट की रकम का स्रोत स्पष्ट है या वह अनुमान/अज्ञात है, और प्रदाता ने आखिर में कितना काटा तथा अंतर क्यों है। स्थानीय दर बदली हो तो नए अनुरोध से उसके सहेजे जाने और गणना की पुष्टि करें। पुराने अनुरोधों के मूल मान रहने दें; उनसे नई दर पर दोबारा गणना की अपेक्षा न रखें।

अभी एक पुराने चित्र अनुरोध से शुरू करें। संस्करण, मॉडल, समय, वास्तविक चित्र संख्या, Cost और प्रदाता की कटौती नोट करें। उस एक अनुरोध का अंतर समझ में आ जाए तो बड़ी समय सीमा का हिसाब देखें। अंतर न समझ आए तो गायब जानकारी और संबंधित अनुरोध प्रदाता या क्लाइंट परियोजना के सामने जाँच के लिए रखें।