Claude Code गेम बनाने से मना करे तो क्या करें?

अगर Claude Code गेम बनाने से मना करे, तो पहले देखें कि अनुरोध किसी खास मौजूदा गेम को फिर से बनाने का तो नहीं है। मौलिक काम के लिए डिज़ाइन और सामग्री के अधिकार स्पष्ट करें, छोटा काम दोबारा दें और दोहराए जा सकने वाले गलत इनकार की रिपोर्ट करें। Anthropic के अनुसार, मौलिक गेम और किसी शैली के गेम बनाने में मदद जारी रहनी चाहिए।

प्रॉम्प्ट, मॉडल या सेटिंग बदलने से पहले इनकार का सटीक पाठ सुरक्षित रखें। इससे अधिकारों को लेकर गलतफ़हमी और व्यवहार में व्यापक बदलाव के बीच अंतर समझने में मदद मिलेगी।

क्या बदला है और tengu_heron_brook क्या है?

2026-11-05 तक Anthropic ने Opus 5.5 पर Claude Code के प्रॉम्प्ट में जोड़े गए दो वाक्यों की पुष्टि की है। इससे यह साबित नहीं होता कि हर Claude मॉडल या सीधे API अनुरोध में यही निर्देश पहुँचता है।

बताए गए नियम का पाठ Game Developer की 30 अक्टूबर की रिपोर्ट में दिया गया है। इसका हिंदी अनुवाद:

मौलिक गेम, किसी शैली के गेम और उपयोगकर्ता के अपने डिज़ाइन व सामग्री से बने गेम बनाएँ। किसी खास मौजूदा गेम को फिर से न बनाएँ, भले ही उसका नाम बदल दिया गया हो या उसे मौलिक कहा जाए।

30 अक्टूबर के बयान में Anthropic के Addy Osmani ने प्रॉम्प्ट में बदलाव की पुष्टि की। उन्होंने इसका उद्देश्य बौद्धिक संपदा के अधिकारों का उल्लंघन रोकना बताया।

उनके अनुसार, मौलिक गेम, किसी शैली के गेम और उपयोगकर्ता के अपने डिज़ाइन व सामग्री वाले प्रोजेक्ट में मदद जारी रहनी चाहिए। Game Developer ने बताया कि Anthropic के प्रवक्ता ने प्रकाशन को इसी बयान की ओर भेजा।

Chasm की पहली रिपोर्ट के अनुसार, बदलाव लगभग 27 अक्टूबर से सर्वर द्वारा भेजे गए tengu_heron_brook नाम के फ़ील्ड से आया। Chasm ने यह भी कहा कि इसे बंद करने की कोई सेटिंग नहीं है।

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

किस तरह के गेम इस नियम के दायरे में बनाए जा सकते हैं?

प्रॉम्प्ट बदलने से पहले काम का स्वरूप और उससे जुड़े अधिकार स्पष्ट करें। बयान अपेक्षित व्यवहार बताता है; हर योग्य अनुरोध सफल होने की गारंटी नहीं देता।

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

किसी शैली को आधार बनाएँ, फिर अपनी ज़रूरतों का अलग विवरण तैयार करें। दूसरे गेम के लेवल और प्रस्तुति को नए नाम से माँगना अब भी उसी गेम को फिर से बनाने का अनुरोध है।

छोटे मौलिक प्रोजेक्ट के लिए Unreal में खेलने योग्य लेवल बनाने की प्रक्रिया से शुरुआत कर सकते हैं। डिज़ाइन, सामग्री का स्रोत और नतीजा जाँचने के मानदंड स्पष्ट रखें।

अपने गेम पर गलत इनकार मिले तो क्या करें?

डिज़ाइन और सामग्री के स्रोत स्पष्ट करें, फिर एक छोटा तकनीकी काम दें। इससे आपके प्रोजेक्ट और किसी दूसरे के गेम को फिर से बनाने के अनुरोध में अंतर बताना आसान होता है।

जिस डेवलपर ने नीचे का डिज़ाइन खुद बनाया हो, वह ऐसा अनुरोध दे सकता है:

Project: Lantern Orchard, an original browser game.
Design: players route rainwater between hexagonal garden plots.
Task: write a pure JavaScript function that distributes water equally
between connected plots, with tests for empty and single-plot inputs.
Assets: use colored geometric placeholders only.
Rights: I created this design; no third-party game assets are required.
Scope: return the function and tests as text.
If a rights detail is unclear, ask a specific question.

इस उदाहरण में एक JavaScript फ़ंक्शन, परीक्षण और ग्राफ़िक्स के लिए केवल ज्यामितीय आकृतियों की माँग है। अपनी परियोजना की सही जानकारी दें। जिस सामग्री को आपने न बनाया हो, न उसके उपयोग का अधिकार पाया हो, उस पर स्वामित्व का दावा न करें।

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

GitHub issue #106167 को समझने में भी यह भेद ज़रूरी है। इसके लेखक, Conflict Simulations LLC के lerugray, ने 30 अक्टूबर को शुरुआती विवरण सुधारा। इन कामों के लिए शुरुआत में प्रकाशक का लाइसेंस नहीं था; ग्राहक गेम की प्रतियों के मालिक थे और सामग्री खुद देते थे।

4 नवंबर को लेखक ने दोनों कामों के लिए प्रकाशकों की लिखित अनुमति मिलने की जानकारी दी। उसी अपडेट में उन्होंने कहा कि Claude Code ने दूसरे काम पर लगी रोक हटा दी। लेखक के अनुसार, दोनों कामों में इनकार की समस्या सुलझ गई।

यह अतिरिक्त अनुमति देने के बाद काम फिर चलने की एक डेवलपर की रिपोर्ट है। इससे आधिकारिक छूट कार्यक्रम की पुष्टि नहीं होती और दूसरे मामलों में वही नतीजा मिलने की गारंटी नहीं मिलती।

अधिकार स्पष्ट हों, तो उसी सही प्रोजेक्ट विवरण के साथ नए सत्र में छोटा काम दोबारा दें। स्वामित्व और लाइसेंस की ज़रूरी जानकारी बनाए रखें। फिर भी इनकार मिले, तो उत्तर सुरक्षित रखें और रिपोर्ट करें। सफल होने पर प्रोजेक्ट में अक्सर आने वाला काम दें और दायरा बढ़ाने से पहले नतीजा जाँचें।

गलत इनकार की रिपोर्ट कैसे भेजें?

गोपनीय जानकारी के बिना समस्या दोहराने वाला छोटा उदाहरण तैयार करें, फिर प्रभावित सत्र में /bug चलाएँ। वर्तमान कमांड संदर्भ के मुताबिक आप चुन सकते हैं कि सत्र का कितना इतिहास रिपोर्ट में जाए। भेजने से पहले सहमति वाली स्क्रीन पर पुष्टि भी करनी होती है।

Anthropic पर प्रमाणीकृत सीधे कनेक्शन से रिपोर्ट Anthropic को जाती है। तीसरे पक्ष के प्रदाता के साथ, या Anthropic के क्रेडेंशियल न होने पर, Claude Code ~/.claude/feedback-bundles/ में स्थानीय आर्काइव बनाता है। उस आर्काइव को आपको खुद आगे भेजना होगा।

समस्या दोहराने लायक जानकारी शामिल करें:

• UTC का समय, claude --version का आउटपुट, माँगा गया मॉडल और खाता/प्रदाता का कनेक्शन मार्ग।
• सटीक प्रॉम्प्ट और इनकार, साथ में प्रोजेक्ट का सबसे छोटा प्रासंगिक उदाहरण।
• अधिकारों का छोटा सार, जिसमें मौलिक सामग्री, लाइसेंस वाली सामग्री और ग्राहक की अनुमति अलग हों।
• अपेक्षित नतीजा और यह जानकारी कि वही अनुरोध नए सत्र में भी विफल होता है या नहीं।

सार्वजनिक रिपोर्टों में करार, क्रेडेंशियल या ग्राहक की पहचान बताने वाली सामग्री न डालें। ऐसी जानकारी के लिए उपयुक्त निजी सहायता चैनल इस्तेमाल करें जिसे सार्वजनिक नहीं किया जा सकता।

अगर आपका उदाहरण issue #106167 से मेल खाता है, तो प्रासंगिक रिकॉर्ड वहीं जोड़ें। अन्यथा रिपॉज़िटरी के साँचे से एक अलग, स्पष्ट रिपोर्ट बनाएँ।

Osmani ने उपयोगकर्ता के अपने काम पर इनकार के मामले भी भेजने को कहा था। ऊपर दिए गए उनके 30 अक्टूबर वाले बयान में यह निमंत्रण है। उन्होंने समीक्षा की समय-सीमा या अपने आप मंज़ूरी देने का वादा नहीं किया।

CLI अपडेट हुए बिना व्यवहार बदले तो कैसे पहचानें?

छोटी और दोहराने योग्य जाँच चलाएँ और समय के साथ नतीजे मिलाएँ। CLI का संस्करण न बदलना अपने आप यह साबित नहीं करता कि व्यवहार भी वही रहेगा।

खाता, प्रदाता का कनेक्शन मार्ग, प्रोजेक्ट का संस्करण, निर्देश, अनुमतियाँ और ज़रूरी सेटिंग स्थिर रखें। माँगे गए मॉडल और उत्तर में आए मॉडल मेटाडेटा का रिकॉर्ड रखें। मॉडल का पूरा ID दें, जैसे claude-opus-5-5, ताकि उपनाम का बदलाव माँगे गए संस्करण को न बदल दे। यह सेटिंग Opus 5.5 चुनने की गाइड में अलग से दी गई है।

नीचे की Bash जाँच स्क्रिप्ट एक मौलिक गेम के छोटे अनुरोध की तुलना गेम से अलग एक मिलते-जुलते अनुरोध से करती है। यह प्रॉम्प्ट, उत्तर, त्रुटियाँ, एग्ज़िट कोड, CLI संस्करण और शुरू होने का समय सहेजती है।

Claude Code का ऐसा इंस्टॉलेशन इस्तेमाल करें जिसमें प्रमाणीकरण पहले से काम कर रहा हो। jq भी पहले इंस्टॉल कर लें। स्क्रिप्ट तय फ़ाइलों और जाँची हुई सेटिंग वाले परीक्षण प्रोजेक्ट के फ़ोल्डर से चलाएँ। टूल रोकने वाला फ़्लैग मॉडल के टूल कॉल रोकता है, लेकिन सत्र शुरू होने पर चलने वाले हुक फिर भी चल सकते हैं।

यह उदाहरण game-probe.sh में सहेजें, फिर bash game-probe.sh चलाएँ:

#!/usr/bin/env bash
set -eu
umask 077

probe_model="${PROBE_MODEL:-claude-opus-5-5}"
probe_dir=$(mktemp -d "${TMPDIR:-/tmp}/claude-game-probe.XXXXXX")
date -u +%FT%TZ > "$probe_dir/start-utc.txt"
claude --version > "$probe_dir/cli-version.txt"
printf '%s\n' "$probe_model" > "$probe_dir/requested-model.txt"

for probe_case in game control; do
  case "$probe_case" in
    game) probe_context='This is an original game using my own design and geometric placeholder assets.' ;;
    control) probe_context='This is an original counter application.' ;;
  esac
  probe_prompt="$probe_context Write a JavaScript increment(value) function that returns value + 1. Include tests for 0, 1, and -1. Return code as text."
  printf '%s\n' "$probe_prompt" > "$probe_dir/$probe_case.prompt.txt"
  if CLAUDE_CODE_EFFORT_LEVEL=medium claude -p "$probe_prompt" \
    --model "$probe_model" --disallowedTools "*" \
    --output-format json </dev/null \
    > "$probe_dir/$probe_case.json" \
    2> "$probe_dir/$probe_case.stderr.txt"; then
    probe_exit=0
  else
    probe_exit=$?
  fi
  printf '%s\n' "$probe_exit" > "$probe_dir/$probe_case.exit.txt"
done

printf 'Evidence directory: %s\n' "$probe_dir"
jq '{file: input_filename, subtype, is_error, stop_reason, modelUsage, result, errors}' \
  "$probe_dir/game.json" "$probe_dir/control.json"

मॉडल और टूल नियंत्रण CLI संदर्भ में दर्ज हैं। प्रोग्राम से चलाने की गाइड में गैर-इंटरैक्टिव मोड, JSON आउटपुट और नतीजा पढ़ना बताया गया है।

कमांड में --continue या --resume नहीं दिए गए हैं। यह CLAUDE_CODE_EFFORT_LEVEL के ज़रिए मॉडल से medium स्तर के प्रयास का अनुरोध करती है। संगठन की नीतियाँ भी स्थिर रखें।

स्क्रिप्ट जाँच का रिकॉर्ड रखने के लिए एक अस्थायी फ़ोल्डर बनाती है। अगर TMPDIR तय है, तो उसका पथ परीक्षण प्रोजेक्ट से बाहर होना चाहिए। इससे सहेजे गए उत्तर रिपॉज़िटरी की सामग्री नहीं बदलेंगे।

अनुरोध स्वीकार हुआ तभी मानें, जब उत्तर में माँगा गया फ़ंक्शन और परीक्षण हों। 0 के लिए 1, 1 के लिए 2 और -1 के लिए 0 मिलना चाहिए। तैयार कोड चलाने से पहले उसे पढ़कर जाँचें।

रिकॉर्ड को इस क्रम में समझें:

1. चलाने की त्रुटियाँ जाँचें। JSON न मिले या अमान्य हो, तो सहेजा गया stderr और एग्ज़िट कोड देखें। प्रमाणीकरण की समस्या और असमर्थित फ़्लैग की अलग जाँच चाहिए।
2. उत्तर पढ़ें। एग्ज़िट कोड शून्य होने से साबित नहीं होता कि मॉडल ने काम स्वीकार किया। stop_reason मौजूद हो, तो देखें। result पढ़कर सामान्य भाषा में इनकार या अधूरा अनुरोध पहचानें।
3. मॉडल मेटाडेटा जाँचें। JSON आउटपुट में मॉडल बदल दिए जाने की चेतावनियाँ छिपी रहती हैं। इसलिए मॉडल कॉन्फ़िगरेशन संदर्भ modelUsage देखने को कहता है। अतिरिक्त मॉडल प्रविष्टियों की पड़ताल करें। उनमें अंदरूनी कॉल शामिल हो सकती हैं; वे अकेले नहीं बतातीं कि अंतिम उत्तर किस मॉडल ने लिखा।
4. पहले दर्ज परिणाम से मिलाएँ। माँगा गया उत्तर मिला, इनकार हुआ, और जानकारी चाहिए तथा चलाने में त्रुटि हुई: इन नतीजों को अलग रखें। नया इनकार दिखे, तो मामला आगे भेजने से पहले जाँच दोहराएँ।

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

यह स्क्रिप्ट एक सीमित मामले में व्यवहार का बदलाव पकड़ती है। इससे यह साबित नहीं होता कि tengu_heron_brook बदला है। इसमें सफल होने से गेम बनाने की पूरी प्रक्रिया सही चलने की पुष्टि भी नहीं होती।

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

दूसरे मॉडल को कैसे परखें?

दूसरे मॉडल की तुलना उसी अधिकृत काम और उन्हीं जाँचों पर करें। किसी दूसरे मॉडल का उत्तर देना अपने आप दूसरे के गेम को फिर से बनाने की अनुमति साबित नहीं करता।

अगर आपका खाता, प्रदाता और संगठन Sonnet 5.5 की अनुमति देते हैं, तो सहेजी गई जाँच Bash में फिर चलाएँ:

PROBE_MODEL=claude-sonnet-5-5 bash game-probe.sh

Anthropic के मॉडल कॉन्फ़िगरेशन सहायता पृष्ठ में दोनों मॉडल ID दिए गए हैं। इंटरैक्टिव काम के लिए /model से उपलब्ध मॉडल चुनें और /status से वर्तमान चुनाव देखें। नतीजे मिलाने से पहले मूल सत्र और जाँच का रिकॉर्ड सुरक्षित रखें।

दूसरे प्रदाता के लिए OpenCode की मॉडल चुनने की दस्तावेज़ी गाइड इंटरैक्टिव तरीका बताती है। /connect चलाएँ और प्रदाता का प्रमाणीकरण पूरा करें। फिर /models से उपलब्ध मॉडल चुनें।

अधिकार स्पष्ट करने वाला वही विवरण भेजें और वही परीक्षण करें। इसे क्लाइंट और प्रदाता की अलग जाँच के रूप में दर्ज करें, क्योंकि यहाँ केवल मॉडल नहीं बदला है।

अगर आपकी टीम पहले से BetterToken इस्तेमाल करती है, तो उसकी OpenCode कॉन्फ़िगरेशन गाइड देखें। उसमें https://www.bettertoken.ai/v1 पर OpenAI-संगत प्रदाता बताया गया है। यह API मार्ग Claude की सदस्यता से अलग है।

केवल ANTHROPIC_BASE_URL बदलने से अनुरोधों का मार्ग बदलता है, उत्तर देने वाला मॉडल नहीं। मॉडल स्पष्ट रूप से चुनें और लौटे हुए मेटाडेटा की जाँच करें।

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