JavaScript फ़्रेमवर्क की AI लागत: तुलना और अपना परीक्षण

कंटेंट पर केंद्रित ऐप में AI कोडिंग लागत मायने रखती है, तो Hono+htmx और Astro को शुरुआती विकल्प रखें। नोलन लॉसन के बेंचमार्क में Hono+htmx की अनुमानित API लागत की माध्यिका (median) सबसे कम थी: $2.67, जबकि Angular की $4.97 थी। मौजूदा प्रोजेक्ट में दूसरा फ़्रेमवर्क चुनने से पहले कोई सामान्य बदलाव करके तुलना करें।

किस फ़्रेमवर्क की AI लागत सबसे कम रही?

इन नतीजों से कंटेंट पर केंद्रित ऐप के लिए परीक्षण के विकल्प चुनें। लॉसन ने प्रयोग 28 अक्टूबर 2026 को प्रकाशित किया। प्रकाशित रन और माप में Claude Code 2.1.310 और claude-opus-5-5 का इस्तेमाल हुआ। तर्क करने के स्तर की effort सेटिंग high पर थी।

हर एजेंट ने खोज, फ़िल्टर और विवरण पृष्ठों वाला वही PokéAPI ऐप बनाया। तालिका में 2026-11-06 तक प्रकाशित नतीजे शामिल हैं। संस्करण बताते हैं कि कौन से पैकेज परखे गए थे। इन्हें आज इंस्टॉल करने की सिफ़ारिश न मानें।

फ़्रेमवर्क और परखा गया संस्करण	अनुमानित API लागत, USD: माध्यिका (न्यूनतम–अधिकतम)	मिनट	टोकन, मिलियन	कोड की पंक्तियाँ
Hono 4.13.14 + htmx 2.0.11	$2.67 ($2.23–$3.19)	8.6	4.26	1,370
Astro 7.4.2	$2.76 ($2.16–$3.63)	8.2	4.13	1,461
Nuxt 4.6.2	$2.82 ($2.39–$4.25)	9.0	3.85	1,415
Vanilla के साथ Vite 8.3.5	$2.98 ($2.24–$3.37)	10.1	5.00	1,492
Next.js 16.4.3	$3.14 ($2.58–$4.13)	10.9	4.99	1,539
Qwik 1.20.2 / 1.20.3	$3.27 ($2.35–$3.80)	10.7	5.64	1,744
TanStack Start 1.169.4	$3.54 ($3.11–$3.96)	10.3	7.07	1,697
SolidStart 2.1.0	$3.79 ($2.84–$4.81)	11.2	7.13	1,630
React Router 8.5.0	$3.81 ($2.82–$3.97)	12.5	7.58	1,564
SvelteKit 3.1.0	$4.28 ($3.59–$4.65)	10.8	8.53	1,611
Gracile 0.11.0 + Lit 3.3.3	$4.65 ($3.92–$5.07)	12.1	9.04	1,717
Angular 22.2.3	$4.97 ($3.19–$6.82)	17.2	9.76	2,009

हर मापदंड की माध्यिका अलग निकाली गई है। लागत, समय और टोकन में प्रत्येक फ़्रेमवर्क के पाँच प्रयास शामिल हैं। Angular के कोड का आकार तीन ऐप से निकाला गया, क्योंकि दो ऐप को रिवर्स प्रॉक्सी के पीछे मापा नहीं जा सका।

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

डॉलर में दी गई ये राशियाँ Claude Code की बताई गई API लागत के अनुमान हैं। लॉसन सदस्यता पर काम कर रहे थे, इसलिए तालिका प्रति ऐप उनके वास्तविक भुगतान नहीं बताती। होस्टिंग का बिल और मानव समीक्षा का समय भी इसमें शामिल नहीं है।

राउंड की गई माध्यिकाओं के आधार पर Angular की अतिरिक्त लागत $4.97 − $2.67 = $2.30 है। उसकी लागत Hono+htmx की 4.97 / 2.67 ≈ 1.86 गुना है। इस काम के लिए यह लगभग 86% अधिक है।

ऐप बनाने पर Next.js और Astro में $0.38 का अंतर था; देखे गए लागत दायरों में ओवरलैप है। Hono+htmx और Astro में केवल $0.09 का अंतर है। इसलिए अपने काम पर छोटा परीक्षण करें; इस अंतर से सभी ऐप के लिए पक्की रैंकिंग नहीं बनती।

SvelteKit और Angular महँगे क्यों पड़े?

दस्तावेज़ ज़्यादा पढ़ना और बड़ा ऐप बनना संभावित कारण हैं, लेकिन प्रयोग उनके अलग-अलग प्रभाव नहीं मापता।

लॉसन ने देखा कि SvelteKit का एजेंट हर रन में v3 की माइग्रेशन गाइड पढ़ता था। उनका अनुमान था कि v3 मॉडल के प्रशिक्षण डेटा से नई हो सकती है। आधिकारिक माइग्रेशन गाइड में कॉन्फ़िगरेशन को Vite में ले जाने जैसे बदलाव दर्ज हैं। इससे यह साबित नहीं होता कि मॉडल ने प्रशिक्षण के दौरान क्या सीखा।

लॉसन के अनुसार Gracile के लिए एजेंट ने रिपॉज़िटरी क्लोन की या node_modules में कम्पाइल की गई फ़ाइलें पढ़ीं। यह अतिरिक्त शोध था। इन फ़ाइलों को पढ़ने से लागत का कितना अंतर आया, यह बेंचमार्क नहीं बताता।

Angular में कोड की पंक्तियों की माध्यिका 2,009 थी, जबकि Hono+htmx में 1,370। दूसरा मान पहले का लगभग 68% है, जो लॉसन के करीब 70% वाले आकलन से मेल खाता है। बड़ी फ़ाइलों से भविष्य में पढ़ने और संपादन का काम बढ़ सकता है, लेकिन यहाँ रखरखाव की लागत नहीं मापी गई।

कुल टोकन भी सावधानी से देखें। Nuxt की टोकन माध्यिका सबसे कम, 3.85 मिलियन थी, लेकिन डॉलर की माध्यिका सबसे कम नहीं थी। कैश का इस्तेमाल कुल टोकन और कीमत का संबंध बदल देता है। लागत समझते समय टोकन की श्रेणियाँ अलग रखें।

क्या फ़्रेमवर्क के MCP सर्वर और स्किल मदद करते हैं?

इस बेंचमार्क से यह तय नहीं होता कि MCP सर्वर या स्किल लागत घटाते हैं। स्किल एजेंट के लिए काम के निर्देश देती है। उपलब्ध टूल का इस्तेमाल अलग-अलग रहा। हर फ़्रेमवर्क के लिए टूल चालू और बंद रखकर तुलनीय रन नहीं किए गए।

जहाँ आधिकारिक टूल उपलब्ध थे, लॉसन ने उन्हें लगाया। कुछ फ़्रेमवर्क के पास ऐसे टूल नहीं थे। उनके निरीक्षण में ये बातें सामने आईं:

फ़्रेमवर्क	पाँच रन में देखा गया इस्तेमाल
Hono+htmx	Hono का Skill टूल 5/5 में इस्तेमाल हुआ
SvelteKit	MCP 5/5 में इस्तेमाल हुआ
Nuxt	MCP 0/5 में इस्तेमाल हुआ
Next.js	स्किल फ़ाइलें 1/5 में पढ़ीं; AGENTS.md 2/5 में पढ़ा
TanStack Start	पैकेज के साथ आई स्किल फ़ाइलें 2/5 में मिलीं

Nuxt का MCP इस्तेमाल न होना उसकी बेअसरता का प्रमाण नहीं है। SvelteKit की अधिक लागत भी यह साबित नहीं करती कि उसका MCP कारण था। इंस्टॉलेशन, टूल कॉल और पूरा काम करने की लागत में सुधार अलग सवाल हैं।

Next.js की मौजूदा गाइड संस्करण से मेल खाते दस्तावेज़ों को काम का क्रम तय करने वाली स्किल से अलग रखती है। एजेंट ने वास्तव में कौन सा संसाधन इस्तेमाल किया, यह दर्ज करें। हर दस्तावेज़ पढ़ने को MCP कॉल न मानें।

अपने परीक्षण में पहले claude mcp list या /mcp से सर्वर की उपलब्धता जाँचें, फिर वास्तविक टूल कॉल देखें। एक ही फ़्रेमवर्क को तीन परिस्थितियों में परखें: बिना टूल, उपलब्ध टूल के साथ, और टूल इस्तेमाल करने का स्पष्ट निर्देश देकर। MCP के कॉन्टेक्स्ट उपयोग को मापने की गाइड आगे की जाँच में मदद करती है।

इस प्रयोग से क्या साबित नहीं होता?

इन नतीजों को छोटे, कंटेंट पर केंद्रित ऐप के लिए शुरुआती छँटाई मानें। इन्हें लागू करते समय चार सीमाएँ ध्यान में रखें:

• काम: सीमित इंटरैक्शन वाला कैटलॉग जटिल एडिटर, डैशबोर्ड या गेम का प्रतिनिधि नहीं है। रेंडरिंग का तरीका भी एजेंट ने चुना।
• नमूने का आकार: पाँच प्रयास उपयोगी मिसालें और दायरे देते हैं, लेकिन करीबी नतीजों की रैंकिंग अनिश्चित है। दिखाए गए दायरे देखे गए न्यूनतम और अधिकतम मान हैं, सांख्यिकीय विश्वास अंतराल नहीं।
• परिवेश: केवल एक मॉडल, एक एजेंट और एक effort सेटिंग परखी गई। पहले रन के बाद Qwik 1.20.2 से 1.20.3 हो गया। माँगे गए Gracile+Lit संयोजन के बावजूद दो ऐप में Lit इस्तेमाल नहीं हुआ।
• परिणाम: मोबाइल सेटिंग वाले Lighthouse पेज-लोड माप हर इंटरैक्शन या production की ज़रूरत नहीं मापते। कोड की पंक्तियाँ आकार बताती हैं; यहाँ रखरखाव लागत का पूर्वानुमान साबित नहीं हुआ।

Angular का अपवाद भी अहम है। प्रकाशित रिकॉर्ड में पाँचों प्रयास स्वीकृति परीक्षण पास दिखते हैं, जबकि दो production माप असफल रहे। अपने प्रयोग में परीक्षण सफल होने और डिप्लॉयमेंट सफल होने को अलग दर्ज करें।

अपने प्रोजेक्ट में Claude Code की लागत कैसे मापें

दो विकल्प लें और हर एक के तीन नए प्रयास चलाएँ। नतीजे करीब हों तो पाँच तक बढ़ाएँ। यह छोटे परीक्षण का प्रस्तावित ढाँचा है, कोई नया बेंचमार्क परिणाम नहीं।

1. काम और शुरुआती स्थिति तय करें

समान स्वीकृति जाँचों से एक सीमित फ़ीचर की तुलना करें। किसी मौजूदा उत्पाद के लिए उसके वर्तमान फ़्रेमवर्क को भी विकल्पों में रखें। संपादन वाले प्रयोग में समय मापने से पहले दोनों शुरुआती प्रोजेक्ट तैयार करें। ऐप शुरू से बनाना मापना हो तो दोनों में सेटअप शामिल करें।

SPEC.md में स्पष्ट काम लिखें। उदाहरण के लिए दोनों कैटलॉग पृष्ठ समान तैयार करें और उत्पादों का वही परीक्षण डेटा दें। फिर यह निर्देश दें:

Add case-insensitive name search to the catalog.
Read products from the existing fixture.
Persist the search query in the URL across reloads.
Show an accessible empty state when nothing matches.
Keep existing routes and the acceptance tests unchanged.

डिपेंडेंसी के संस्करण पिन करें और लॉकफ़ाइलें रखें। संपादन परीक्षण से पहले डिपेंडेंसी इंस्टॉल करें। सुनिश्चित करें कि दोनों प्रोजेक्ट में npm run build और npm test उपलब्ध हों। स्वीकृति परीक्षणों की मूल प्रति अलग रखें।

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

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

2. रन और उसका अंतिम परिणाम दर्ज करें

Bash का इस्तेमाल करें। Claude Code का प्रमाणीकरण पूरा हो और jq इंस्टॉल हो। claude auth status --text से प्रमाणीकरण जाँचें; ज़रूरत हो तो परीक्षण से पहले claude auth login चलाएँ।

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

हर परिस्थिति के लिए अलग trial_label रखें। यह उदाहरण दस्तावेज़ में दिए गैर-इंटरैक्टिव CLI का इस्तेमाल करता है और अलग आउटपुट डायरेक्टरी रखता है।

trial_label=astro-01
trial_dir=$(mktemp -d "/tmp/${trial_label}.XXXXXX") || exit 1

claude --version > "$trial_dir/claude-version.txt"
git rev-parse HEAD > "$trial_dir/commit.txt"

trial_status=0
CLAUDE_CODE_EFFORT_LEVEL=high claude -p \
  --model claude-opus-5-5 \
  --max-budget-usd 10 \
  --allowedTools "Read,Edit,Write,Bash" \
  --output-format stream-json --verbose \
  "Implement SPEC.md without changing dependencies or acceptance tests. Run npm run build and npm test. Report incomplete work." \
  > "$trial_dir/session.jsonl" 2> "$trial_dir/stderr.log" \
  || trial_status=$?

printf '%s\n' "$trial_status" > "$trial_dir/exit-code.txt"

jq -s '
  [.[] | select(.type == "result")] | last
  | if . == null then error("No final result; record an incomplete run")
    else {
      session_id,
      subtype,
      is_error,
      estimated_usd: .total_cost_usd,
      reported_wall_minutes: (.duration_ms / 60000),
      modelUsage,
      permission_denials
    } end
' "$trial_dir/session.jsonl" > "$trial_dir/summary.json"

cat "$trial_dir/summary.json"
printf 'Results: %s\n' "$trial_dir"

$10 का बजट केवल उदाहरण के लिए है। --max-budget-usd अनुमानित API खर्च का इस्तेमाल करता है और खर्च इस सीमा से ऊपर जा सकता है। हर परिस्थिति में एक ही सीमा रखें और बजट के कारण रुके रन दर्ज करें।

2026-11-06 के अनुसार, CLAUDE_CODE_EFFORT_LEVEL को --effort पर प्राथमिकता मिलती है। संगठन की effort सीमाएँ चुने हुए स्तर को फिर भी सीमित कर सकती हैं। मॉडल का इस्तेमाल न हो पाए, तो तुलना जारी रखने से पहले Opus 5.5 का कॉन्फ़िगरेशन ठीक करें।

सारांश में estimated_usd, reported_wall_minutes, modelUsage और कोई भी permission_denials होना चाहिए। JSONL रिकॉर्ड टूल की घटनाएँ सहेजता है, जिनकी आप जाँच कर सकते हैं। इच्छित मॉडल का नाम देखें और इस्तेमाल हुए अतिरिक्त मॉडल भी दर्ज करें।

3. जाँच पास करने वाले परिणामों की तुलना करें और असफल प्रयास भी रखें

एजेंट और सबएजेंट के टोकन हिसाब के लिए modelUsage इस्तेमाल करें। inputTokens, outputTokens, cacheReadInputTokens और cacheCreationInputTokens को अलग रखें। अंतिम परिणाम के usage फ़ील्ड में सबएजेंट की गतिविधि शामिल नहीं होती।

अंतिम परिणाम एक बार पढ़ें। संचित परिणामों के कुल मान आपस में न जोड़ें। दोबारा जारी किए गए पुराने सत्र को नया प्रयास न मानें।

मूल परीक्षण और production बिल्ड खुद चलाएँ। जाँचें कि डिपेंडेंसी और परीक्षण फ़ाइलें नहीं बदलीं। एजेंट का सफल परिणाम यह प्रमाणित नहीं करता कि ऐप सभी तय शर्तें पूरी करता है।

अंतिम परिणाम गायब हो या उसका फ़ॉर्मैट गलत हो, तो stderr.log देखें। प्रयास को अधूरा और लागत को अज्ञात दर्ज करें; लागत में शून्य न लिखें। MCP इस्तेमाल न होने को एजेंट का व्यवहार मानने से पहले अनुमति न मिलने की समस्याएँ दूर करें।

हर फ़्रेमवर्क के लिए जाँच पास करने वाले प्रयासों की संख्या और कुल प्रयास लिखें। सफल रन के लिए माध्यिकाएँ और दायरे दें। सभी प्रयासों का कुल अनुमानित खर्च भी दें। प्रति स्वीकृत परिणाम की लागत निकालने के लिए सभी प्रयासों की अनुमानित लागत को स्वीकृत परिणामों की संख्या से भाग दें:

Total quoted cost of all attempts / Number of accepted results

किसी प्रयास की लागत न मिले, तो पूरे बैच की लागत अधूरी बताएँ। कोई परिणाम स्वीकृत न हो, तो प्रति परिणाम लागत निकालने की जगह विफलता लिखें। मानव समीक्षा का समय अलग दर्ज करें।

मैन्युअल सत्रों में Claude Code की मौजूदा लागत रिपोर्ट /usage में ऐसी ही अनुमानित राशि दिखाती है। कमांड संदर्भ में 2026-11-06 के अनुसार /cost उसका एक उपनाम है। सदस्यता की उपलब्ध सीमा और प्रदाता के वास्तविक शुल्क इस अनुमान से अलग हैं।

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

फ़्रेमवर्क चुनने के बाद दूसरे मॉडल या मॉडल तक पहुँचने के तरीके को अलग प्रयोग में परखें। कोडिंग मॉडल की तुलना विकल्प चुनने में मदद कर सकती है, ताकि फ़्रेमवर्क परीक्षण में एक साथ कई कारक न बदलें।