একজন একক ডেভেলপারের তিনটি Claude মডেলের পরীক্ষা মাসিক API খরচ ৩৫% কমিয়ে দিয়েছে এবং কাজের গড় ল্যাটেন্সি ৪২ সেকেন্ড থেকে কমিয়ে ২৭ সেকেন্ডে নিয়ে এসেছে। সহজ এবং কম অস্পষ্ট (low-ambiguity) কাজগুলোকে সস্তা Haiku মডেলে, রুটিন কাজগুলোকে Sonnet-এ পাঠিয়ে এবং উচ্চ-ঝুঁকিপূর্ণ সমস্যার জন্য ভারী Opus মডেলটিকে সংরক্ষণ করে, লেখক প্রমাণ করেছেন যে "সবকিছুর জন্য সেরা মডেল" ব্যবহার করা একটি ব্যয়বহুল অভ্যাস।

কেন এই রাউটিং গুরুত্বপূর্ণ ছিল

লেখক একটি স্বায়ত্তশাসিত (autonomous) কোডিং এজেন্ট চালান যা ক্রমাগত ডেভেলপমেন্ট টাস্ক পায়—যেমন লিন্ট ফিক্স (lint fixes), ফিচার সংযোজন, সিকিউরিটি রিভিউ এবং গভীর ডিবাগিং সেশন। মাসের পর মাস এজেন্টটি প্রতিটি রিকোয়েস্ট Opus-এর কাছে পাঠাত, যা হলো সবচেয়ে সক্ষম Claude মডেল; ধারণা করা হয়েছিল যে উচ্চতর গুণমান সবসময় দামের চেয়ে বেশি গুরুত্বপূর্ণ হবে। Opus প্রতি টোকেনের জন্য প্রিমিয়াম মূল্য দাবি করে, তাই বিল অনিয়ন্ত্রিতভাবে বাড়তে থাকে।

যখন লেখক একটি স্তরভিত্তিক (tiered) রাউটিং স্কিম চালু করলেন, তখন খরচ আগের মাত্রার ৬৫%-এ নেমে আসে এবং মোট কাজের মাত্র ১১%-এ Opus-এর ব্যবহার কমে যায়।

কীভাবে এই তিন-স্তরের সিস্টেমটি কাজ করে

রাউটিং লজিকটি অস্পষ্টতার (ambiguity) ওপর নির্ভর করে, কাজের কোড কত লাইনের তার ওপর নয়। লেখক তিনটি বিভাগ (buckets) নির্ধারণ করেছেন:

  • Haiku – কম অস্পষ্টতা সম্পন্ন, নির্ধারিত (deterministic) কাজ। উদাহরণ: লিন্ট ওয়ার্নিং ঠিক করা, ভেরিয়েবল রিনেম করা, লগ ফাইল সামারি করা। সঠিক উত্তর সাধারণত কোড বা টেক্সটের একটি মাত্র লাইন হয়।
  • Sonnet – ডিফল্ট কাজের হাতিয়ার। এটি ফিচার ইমপ্লিমেন্টেশন, রুটিন বাগ ফিক্স এবং স্ট্যান্ডার্ড রিফ্যাক্টরিং সামলায় যেখানে সমস্যাটি স্পষ্ট কিন্তু সমাধানের জন্য বেশ কয়েকটি ধাপের প্রয়োজন হতে পারে।
  • Opus – উচ্চ-ঝুঁকিপূর্ণ এবং উচ্চ-অস্পষ্টতা সম্পন্ন কাজ। আর্কিটেকচার সংক্রান্ত সিদ্ধান্ত, সিকিউরিটি অডিট, জটিল ডিবাগিং সেশন, অথবা এমন যেকোনো কাজ যেখানে সঠিক পথটি অস্পষ্ট এবং একটি ভুল পদক্ষেপ পুরো পাইপলাইন নষ্ট করে দিতে পারে।

একটি স্ট্যাটিক লুকআপ টেবিল এই নিয়মগুলোর ওপর ভিত্তি করে প্রতিটি ইনকামিং রিকোয়েস্টকে সঠিক মডেলে ম্যাপ করে। লেখক একটি "স্মার্ট" মডেল ব্যবহার করার চেষ্টা করেছিলেন যা তাৎক্ষণিকভাবে (on the fly) স্তর নির্ধারণ করবে, কিন্তু অতিরিক্ত টোকেন ব্যবহারের ফলে যে সাশ্রয় হওয়ার কথা ছিল তা আর থাকল না। সহজ স্ট্যাটিক নিয়মগুলো প্রায় ৮০% কাজের চাপ সামলাতে সক্ষম হয়েছে এবং সিস্টেমটিকে সস্তা ও অনুমানযোগ্য (predictable) রেখেছে।

এস্কেলেশন সেফটি নেট

সস্তা মডেলগুলোও ভুল করতে পারে। Haiku বা Sonnet-এর কোনো ভুল রেসপন্স বিল্ড (build) প্রক্রিয়াকে ব্যাহত করা থেকে রক্ষা করতে, সিস্টেমটি দুইবার ব্যর্থ হওয়ার পর রিকোয়েস্টটিকে পরবর্তী স্তরে উন্নীত (escalate) করে। এই সেফটি নেটটি দ্রুত ভুল শনাক্ত করে এবং মানুষের হস্তক্ষেপ ছাড়াই পাইপলাইনটি মসৃণভাবে চলতে সাহায্য করে।

সংখ্যা যা নিজেই কথা বলে

চার সপ্তাহ এই টিয়ারড রাউটার চালানোর পর, লেখক এই পরিবর্তনগুলো নথিভুক্ত করেছেন:

  • API খরচ আগের খরচের ৬৫%-এ নেমে এসেছে (৩৫% হ্রাস)।
  • গড় টার্নঅ্যারাউন্ড টাইম ৪২ সেকেন্ড থেকে কমে ২৭ সেকেন্ডে দাঁড়িয়েছে।
  • Opus-এর ব্যবহার প্রতিটি রিকোয়েস্ট সামলানো থেকে কমে মোট কাজের মাত্র ১১%-এ নেমে এসেছে।

এই পরিসংখ্যানগুলো দেখায় যে গুণমানের উল্লেখযোগ্য অবনতি না ঘটিয়েই বেশিরভাগ ডেভেলপমেন্ট কাজ সস্তা মডেলগুলোর ওপর অর্পণ করা সম্ভব, যেখানে কঠিনতম সমস্যাগুলো এখনও Opus-এর বড় context window-এর সুবিধা নিতে পারে।

অন্যান্য ডেভেলপারদের জন্য শিক্ষা

১. নিচ থেকে শুরু করুন, উপর থেকে নয়। প্রতিদিনের বেশিরভাগ কোডিং কাজের জন্য সবচেয়ে শক্তিশালী মডেলের প্রয়োজন হয় না। অস্পষ্ট কাজের জন্য Sonnet-কে ডিফল্ট হিসেবে ব্যবহার করা, সবকিছু Haiku-এর মাধ্যমে করার চেয়ে বেশি সাশ্রয়ী ছিল। ২. কঠিনতা পরিমাপ করুন, আকার নয়। একটি পুরো ফাইল রিফ্যাক্টর করার চেয়ে এক লাইনের একটি race-condition ফিক্স করা অনেক বেশি কঠিন হতে পারে। সমাধানের অস্পষ্টতার ওপর ভিত্তি করে রাউটিং করুন, পরিবর্তিত লাইনের সংখ্যার ওপর নয়। ৩. এস্কেলেশন রেট খেয়াল রাখুন। এস্কেলেশনের সংখ্যা বৃদ্ধি পাওয়া মানে হলো স্ট্যাটিক নিয়মগুলো আর কাজের চাপের সাথে সামঞ্জস্যপূর্ণ নয়। সস্তা মডেলগুলো পাইপলাইনে বেশি ব্যর্থতা ঘটানোর আগেই বিভাগগুলো (buckets) সমন্বয় করে নিন।

সবচেয়ে কঠিন সমস্যার জন্য সবচেয়ে ব্যয়বহুল মডেলটি সংরক্ষণ করা এবং বাকি কাজগুলো সস্তা মডেলগুলোর মাধ্যমে সম্পন্ন করা AI-সহায়তা প্রাপ্ত ডেভেলপমেন্টকে দ্রুত এবং সাশ্রয়ী রাখে। আসল সুবিধাটি লুকিয়ে আছে একটি সুশৃঙ্খল রাউটিং কৌশলে, যা সঠিক কাজের জন্য সঠিক টুলটি নির্বাচন করে।