Claude Opus 5-এর “max effort” সেটিংস একটি সাধারণ রিকোয়েস্টের দাম $০.৭৬ থেকে বাড়িয়ে $১৯.২১ করে দেয়, অথচ কার্যকরী আউটপুট প্রায় একই থাকে। এই অতিরিক্ত খরচ মূলত একটি অভ্যন্তরীণ অডিট পাসের জন্য, কোনো উন্নত সমাধানের জন্য নয়; এবং এটি কেবল সেই কাজগুলোতে দৃশ্যমান উন্নতি দেখায় যেগুলোর টেস্ট কভারেজ (test coverage) কম।
পরীক্ষা যা দেখিয়েছে
এই পরীক্ষায় Claude Opus 5-এর ডিফল্ট এফোর্ট লেভেলের সাথে “max effort” অপশনের তুলনা করা হয়েছে দুটি ধরণের প্রম্পটের ওপর: প্রতিদিনের কোডিং কাজ এবং উদ্দেশ্যপ্রণোদিতভাবে কঠিন সমস্যা।
- একটি সাধারণ কাজের জন্য, লো-এফোর্ট রানটি দুই মিনিটে শেষ হয় এবং খরচ হয় $০.৭৬। সেটিংটি বাড়িয়ে 'max' করলে বিল $১৯.২১ পর্যন্ত পৌঁছে যায়, তবুও রিকোয়ারমেন্ট-কভারেজ স্কোর—যা মডেলটি রিপোর্ট করে যে এটি নির্দেশাবলী কতটা ভালোভাবে পূরণ করেছে—একই থাকে।
- ট্রান্সক্রিপ্ট থেকে দেখা যায় যে মডেলটি কোড তৈরির পরিবর্তে সংশোধনের দিকে ঝুঁকে পড়েছে। মডেলটি নতুন কোড জেনারেট করা বন্ধ করে দিয়ে আগে যা লিখেছে তাকেই পরিমার্জিত করতে শুরু করে। নতুন কোড লেখার তুলনায় এডিট বা সংশোধনের সংখ্যা ছিল ২.৪ গুণ বেশি। “read” টুলের ব্যবহার আঠারো গুণ এবং “bash” টুলের ব্যবহার ছয় গুণ বৃদ্ধি পেয়েছে। বাস্তবে মডেলটি নিজে থেকেই মডিউলগুলো পুনরায় পড়ে, নিজের টেস্টগুলো পুনরায় চালায়, লিন্টিং (linting) এবং এমনকি অনুরোধ ছাড়াই মিউটেশন টেস্টিং (mutation testing) সম্পন্ন করে।
“max effort” সেটিংসটি কোনো নতুন অ্যালগরিদম নিয়ে আসে না; এটি কেবল মডেলটি যে বাজেট খরচ করতে পারে তা বাড়িয়ে দেয়। বাজেট যথেষ্ট বড় হয়ে গেলে, মডেলটি একটি সেলফ-অডিট মোডে চলে যায় এবং এমন কোনো পরিবর্তন খোঁজে যা করার জন্য খরচ করাটা যুক্তিযুক্ত মনে হয়।
কেন খরচ বেড়ে যায়
যখন মডেলটি অডিট করার সিদ্ধান্ত নেয়, তখন প্রতিটি অতিরিক্ত 'read' বা 'bash' কল বিল বাড়িয়ে দেয় এবং এই গুণিতক প্রভাব দ্রুত মোট খরচ বহুগুণ বাড়িয়ে দেয়।
অডিট মোডটি একটি সুনির্দিষ্ট ডিজাইনের সিদ্ধান্ত। মডেলটি বড় বাজেটকে “এমন কিছু খোঁজার অনুমতি” হিসেবে বিবেচনা করে যা সংশোধন করা প্রয়োজন। যদি উন্নতির কোনো সুযোগ না দেখা যায়, তবে অতিরিক্ত খরচে কোনো কার্যকরী সুবিধা পাওয়া যায় না।
কখন উচ্চতর এফোর্ট যুক্তিযুক্ত
অডিট মোডটি তখনই কার্যকর হয় যখন প্রাথমিক আউটপুটে উন্নতির সুযোগ থাকে। একটি Go প্রজেক্টে যেখানে টেস্ট কভারেজ ছিল ০.৭৩, সেখানে এফোর্ট বাড়িয়ে 'max' করলে কভারেজ বেড়ে ০.৮৮ হয়।
বিপরীতভাবে, একটি Python টাস্ক যা ইতিমধ্যে ০.৯৮ কভারেজ অর্জন করেছিল, বাজেট বাড়ানোর পরও তাতে কোনো পরিবর্তন দেখা যায়নি। মডেলটি কেবল একই উচ্চ-মানের কোড পুনরায় পরীক্ষা করেছে, যা কোনো বাড়তি ভ্যালু যোগ না করেই খরচ বাড়িয়ে দিয়েছে।
সম্ভাব্য অসুবিধা
- বাজেট বিপর্যয় – যারা লো-এফোর্ট প্রাইস পয়েন্টে অভ্যস্ত, তারা একই কাজের জন্য পঁচিশ গুণ বৃদ্ধি দেখে অবাক হতে পারেন।
ডেভেলপারদের জন্য ব্যবহারিক নির্দেশিকা
- রুটিন প্রম্পটগুলোকে ডিফল্ট এফোর্ট লেভেলে রাখুন। আপনি খুব সামান্য খরচে একই কার্যকরী ফলাফল পাবেন।
- “max effort” শুধুমাত্র সেই কোডের জন্য সংরক্ষণ করুন যা একটি নির্দিষ্ট কোয়ালিটি থ্রেশহোল্ড পূরণ করতে ব্যর্থ হয়—যেমন কম টেস্ট কভারেজ, লিন্টিং ওয়ার্নিং বা অন্যান্য পরিমাপযোগ্য ঘাটতি।
- এই সেটিংটিকে একটি আলাদা মোড হিসেবে বিবেচনা করুন: এটি উন্নত উত্তরের জন্য কোনো স্পিড ডায়াল নয়, বরং একটি ঐচ্ছিক সেলফ-রিভিউ পাস।
মূল কথা
Claude Opus 5-এর max-effort সুইচটি উন্নত কোডের জন্য নয়, বরং একটি অভ্যন্তরীণ কোয়ালিটি চেকের জন্য টাকা খরচ করে। এটি পরিমিতভাবে ব্যবহার করুন, কেবল তখনই যখন আপনার বেসলাইন ফলাফলগুলোতে পূরণের মতো কোনো পরিমাপযোগ্য ঘাটতি থাকে; অন্যথায়, সস্তা ডিফল্ট সেটিংসটি অডিট-মোডের বাড়তি খরচ ছাড়াই একই ফলাফল প্রদান করে।
Community discussion: https://t.me/GyaanSetuAi