દરેક નવું મોડેલ રિલીઝ થવું એ જ જૂની ચર્ચાને જન્મ આપે છે. ટીકાકારો વિજેતા જાહેર કરવા અને અગાઉના સ્તરને નકામું જાહેર કરવા માટે ઉતાવળ કરે છે. GPT-5.6 Luna, Terra અને Sol ની સાથે હોવાથી, વાર્તા આપમેળે લખાઈ જાય છે: Luna એટલી સસ્તી અને સક્ષમ છે કે તે Terra ને બિનજરૂરી બનાવી દેશે. આ ખોટું છે. તે પણ મોંઘી છે. તમારા કોડિંગ એજન્ટ્સ માટે મોડેલ પસંદ કરવું એ સૌંદર્ય સ્પર્ધા, ટીમની ઓળખ અથવા બેન્ચમાર્કની રેસ નથી. તે એક ઓપરેટિંગ પોલિસી છે. જે ટીમો આ તફાવતને સમજી લેશે તેઓ દરેક વિનંતી માટે સૌથી શક્તિશાળી મોડેલનો ઉપયોગ કરતી ટીમો કરતા ઓછો ખર્ચ કરશે, ઝડપથી કામ કરશે અને ઓછી ભૂલો કરશે.
તમારો ડિફોલ્ટ વિકલ્પ એ સૌથી સસ્તું સાધન હોવું જોઈએ જે કામ માટે યોગ્ય હોય
Luna એ વેલ્યુ ટિયર (value tier) છે, અને આ કોઈ સામાન્ય વાત નથી. તે મર્યાદિત, સ્પષ્ટ અને સરળ કાર્યોમાં શ્રેષ્ઠ કામ કરે છે. વર્ગીકરણ (classification), સારાંશ (summarization), કોડના ટૂંકા ફેરફારો અને પ્રાથમિક સંશોધન વિશે વિચારો. જ્યારે કોઈ એજન્ટ પ્રાયોરિટી લેબલ આપવા માટે સપોર્ટ ટિકિટનું વિશ્લેષણ કરે છે, ત્યારે Luna પૂરતી છે. જ્યારે તે થોડી ફાઇલોમાં વેરિએબલનું નામ બદલે છે અથવા git diff નો એક ફકરાનો સારાંશ તૈયાર કરે છે, ત્યારે Luna પૂરતી છે. આ એવા કામો છે જેનું કાર્યક્ષેત્ર મર્યાદિત છે, ઇનપુટ સ્પષ્ટ છે અને આઉટપુટને નિરપેક્ષ રીતે ચકાસી શકાય તેવું છે.
આર્થિક અસર જ ખેલ બદલી નાખે છે. Luna સસ્તી છે. મોટા પાયે ઉપયોગ કરવાથી, ઓટોમેશન એક મોંઘી પ્રક્રિયામાંથી ઈન્ફ્રાસ્ટ્રક્ચરમાં બદલાઈ જાય છે. તમે ટોકન્સ ગણવાનું બંધ કરો છો અને થ્રુપુટ (throughput) માપવાનું શરૂ કરો છો. જો વધારાના પાંચ ટકા કામ પરિણામ બદલતું ન હોય, તો રૂટિન કાર્યોના એંસી ટકા કામ પૂરું કરતું સસ્તું મોડેલ એ એંસી પાંચ ટકા કામ પૂરું કરનારા મોંઘા મોડેલ કરતા વધુ મૂલ્યવાન છે. જો Luna બે સેકન્ડમાં યુનિટ ટેસ્ટ બનાવે છે અને Terra પાંચ ગણા ખર્ચમાં આઠ સેકન્ડમાં થોડો વધુ સારો ટેસ્ટ બનાવે છે, તો ગણિત ત્યારે જ કામ કરે છે જો કોઈ દરેક લાઇનનું કાળજીપૂર્વક ઓડિટ કરતું હોય. મોટાભાગે, કોઈ કરતું નથી. Luna એ મર્યાદિત કામ માટે તમારો ડિફોલ્ટ વિકલ્પ હોવી જોઈએ કારણ કે મોટાભાગનું કામ મર્યાદિત હોય છે.
જ્યારે મર્યાદાઓ અદૃશ્ય થઈ જાય ત્યારે એસ્કેલેટ (Escalate) કરો
Terra નકામું નથી. તે તમારું એસ્કેલેશન ટિયર છે, અને તે એવા કાર્યો માટે છે જેમાં સ્પષ્ટ મર્યાદાઓ નથી. જ્યારે લક્ષ્ય અસ્પષ્ટ હોય અથવા જ્યારે કામમાં ડિપ્લોયમેન્ટ પાથ (deployment paths), ક્રોસ-મોડ્યુલ ફેરફારો અથવા ઇન્સિડન્ટ ટ્રાયજ (incident triage) જેવી જટિલ સિસ્ટમ્સ સામેલ હોય ત્યારે તેનો ઉપયોગ કરો. ફીચર ફ્લેગ્સ સાથે સ્ટેજિંગ, કેનરી અને પ્રોડક્શન એન્વાયરમેન્ટ્સમાંથી પસાર થતો ડિપ્લોયમેન્ટ પાથ પાસે કોઈ ચોક્કસ સ્પેક શીટ હોતી નથી. બિલિંગ લોજિકને સ્પર્શ કરતું અને રિપોર્ટિંગ પાઇપલાઇનમાં અસર કરતું રિફેક્ટર એ મર્યાદિત કાર્ય નથી. પ્રોડક્શન ઇન્સિડન્ટ જ્યાં લોગ્સ API ટાઇમઆઉટ વિશે બૂમો પાડી રહ્યા હોય પરંતુ તેનું મૂળ કારણ ગયા ક્વાર્ટરના માઈગ્રેશન સ્ક્રિપ્ટમાં હોય, ત્યાં નિર્ણય લેવાની ક્ષમતાની જરૂર પડે છે.
Terra તે નિર્ણય લેવાની ક્ષમતા પૂરી પાડે છે. તે લક્ષણોને કારણોથી અલગ કરે છે. Luna લોહી વહેતું અટકાવવા માટે રિટ્રાય લૂપ (retry loop) ને પેચ કરી શકે છે. Terra પૂછે છે કે શું રિટ્રાય લૂપ હોવો જ જોઈએ, અથવા શું અન્ડરલાઇંગ ટાઇમઆઉટ આર્કિટેક્ચર એ સાચી સમસ્યા છે. જ્યારે ખોટો ફિક્સ કામચલાઉ ધીમી ગતિને મોટી નિષ્ફળતામાં ફેરવી દે છે, ત્યારે આ તફાવત મહત્વનો બને છે. જો એક મજબૂત મોડેલ એક ખરાબ પ્રોડક્શન માઈગ્રેશનને અટકાવે છે, તો તે એન્જિનિયરનો આખો દિવસ બચાવે છે તો તે કિંમત લેવા જેવું છે. એક અટકાવેલ આઉટેજ મહિનાઓના એસ્કેલેશન ખર્ચની ભરપાઈ કરી શકે છે.
Sol એ ઇન્શ્યોરન્સ પોલિસી છે, ડેઇલી ડ્રાઇવર નથી
Sol એવા કિસ્સાઓ માટે છે જ્યાં વધારાની ક્ષમતા ઊંચા ખર્ચને યોગ્ય ઠેરવે છે. તેનો ઉપયોગ ઉચ્ચ-જોખમ ધરાવતા રિવ્યુ અથવા આર્કિટેક્ચરલ ફેરફારો માટે કરો. ઓથેન્ટિકેશન ફ્લોનું પુનઃનિર્માણ કરવું, ડેટાબેઝ શાર્ડિંગનું રિડિઝાઇન કરવું અથવા પેમેન્ટ ગેટવેને સ્પર્શ કરતી પુલ રિક્વેસ્ટને મંજૂરી આપવી એ રોજિંદી ઘટનાઓ નથી. તે મહત્વપૂર્ણ ઘટનાઓ છે. Sol તમારો ડિફોલ્ટ વિકલ્પ ન હોવો જોઈએ. તે તમારો એક્સેપ્શન હેન્ડલર (exception handler) હોવો જોઈએ, જે ત્યારે બોલાવવામાં આવે જ્યારે નિષ્ફળતાનો ખર્ચ સસ્તા મોડેલ્સ માટે સહન કરી શકાય તેટલો ઓછો ન હોય.
સૌથી વધુ જોખમી શ્રેણી માટે, Sol ને ડિટરમિનિસ્ટિક વેરિફાયર (deterministic verifier) સાથે જોડો. Sol ને સ્કીમા ફેરફાર સૂચવવા દો અથવા આર્કિટેક્ચરલ ટ્રેડ-ઓફ્સ વિશે વિચારવા દો. તમારા CI પાઇપલાઇન, સ્ટેટિક એનાલિસિસ અને ઇન્ટિગ્રેશન ટેસ્ટને મિકેનિકલ વિગતોની પુષ્ટિ કરવા દો. મોડેલ અંતર્જ્ઞાન (intuition) લાવે છે. વેરિફાયર ગેરંટી લાવે છે. જ્યારે બ્લાસ્ટ રેડિયસ (blast radius) સૌથી મોટું હોય ત્યારે આ સંયોજન જ તમને સુરક્ષિત રાખે છે.
એક રાઉટર બનાવો, ધર્મ નહીં
સાચું માપદંડ એ નથી કે કયું મોડેલ શ્રેષ્ઠ છે. પ્રશ્ન એ છે કે ખર્ચ, લેટન્સી (latency) અને બ્લાસ્ટ રેડિયસ (blast radius) ના આધારે કયા મોડેલે આ કાર્ય સંભાળવું જોઈએ. મોડેલની પસંદગીને ઓળખ તરીકે જોવાનું બંધ કરો. "અમે Terra વાપરીએ છીએ" એવું ન કહો. તેના બદલે, કાર્યના પ્રકાર મુજબ રાઉટ કરો.
Build a simple classifier. Incoming tasks get tagged by blast radius. Low-blast-radius work goes to Luna. Medium-blast-radius work goes to Terra. High-blast-radius work goes to a strong model plus a deterministic verifier. You do not need a perfect machine learning classifier to start. A few heuristics will do. Code reviews that only touch internal utilities and stay under a narrow line count? Luna. Tickets mentioning deployment pipelines, cross-service calls, or ambiguous requirements? Terra. Anything touching customer data, critical paths, or legal compliance? Escalate to Sol and require human or deterministic review.
Measure outcomes, not model names. Track cost per task, retry rate, and escape defects. If Luna is failing on tasks you assigned to it, move the boundary up. If Terra is overkill for a pattern that repeats every day, demote it to Luna and watch your burn drop. The goal is to increase automation without breaking your budget. Luna handles the high-volume background work. Terra handles the moments where judgment matters. Sol stands watch for the exceptions that can break your week.
The teams that get this right treat their agent fleet like a well-run engineering org. They do not staff every project with architects, and they do not ask interns to redesign the core data model. They match capability to risk. Do the same with your models.
Read the original discussion: GPT-5.6 Luna Is The Value Tier. Terra Is Not Useless
Join the GyaanSetu learning community: t.me/GyaanSetuAi