AI की Computer Use क्षमता structured API की तुलना में 45 गुना महंगी है

 (reflex.dev)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • उसी admin panel task में vision agent ने screenshots और clicks से UI को ऑपरेट किया, जबकि API agent ने उसी application handlers को structured responses के साथ call किया, जिससे लागत के अंतर में केवल interface ही variable रहा
  • base prompt पर API agent ने 8 calls में task पूरा कर लिया, लेकिन vision agent ने visible area के नीचे मौजूद 3 pending reviews मिस कर दिए और 4 में से केवल 1 को approve किया
  • 14-step UI walkthrough जोड़ने पर vision agent ने भी task पूरा किया, लेकिन execution में लगभग 14 मिनट और लगभग 5 लाख input tokens लगे, और इस तरह की specific guidance खुद एक अलग engineering cost है
  • कुल results में Sonnet के आधार पर vision path ने औसतन 53 steps, 1003 seconds, 550,976 input tokens उपयोग किए, जबकि API path 8 calls, 19.7 seconds, 12,151 input tokens में समाप्त हुआ, और इसकी cost व time variability भी बहुत कम थी
  • cost gap model performance से नहीं बल्कि interface structure से आया; Reflex 0.9 की तरह अगर event handlers से HTTP endpoints auto-generate किए जाएं, तो self-built internal tools में structured API path की cost economics ज़्यादा फायदेमंद हो जाती है

benchmark का उद्देश्य और experiment setup

  • उसी admin panel को vision agent और structured API तरीके से चलवाकर browser/computer use approach की लागत मापी गई
  • जब AI agent को ऐसे web app को ऑपरेट करना हो जो API न देता हो, तब vision agent default choice बन जाना आसान है
  • ऐसी स्थिति में जहां हर team के पास 20 से अधिक internal tools हों, हर app के लिए MCP या REST surface लिखना अपने आप में एक अलग engineering project बन जाता है, इसलिए कई teams vision agent चुनती हैं
  • test app एक admin panel है जो customers, orders और reviews को manage करता है, और इसका model react-admin Posters Galore demo पर आधारित है
  • दोनों agents ने वही running app, वही Claude Sonnet, वही fixed dataset और वही task इस्तेमाल किया; सिर्फ interface variable रखा गया
  • task था: “Smith” नाम वाले customers में सबसे ज्यादा orders वाले customer को ढूंढना, फिर उस customer का सबसे recent pending order ढूंढना, उसके सभी pending reviews approve करना, और order को shipped के रूप में mark करना
  • यह task तीन resources को छूता है, और इसमें filtering, pagination, entities के बीच lookup, तथा read और write दोनों शामिल हैं, इसलिए यह सामान्य internal tool workflows जैसा है

दो execution paths

  • path A: Vision agent

    • Claude Sonnet ने browser-use 0.12 को vision mode में इस्तेमाल करके screenshots और clicks के जरिए UI ऑपरेट किया

  • path B: API agent

    • Claude Sonnet ने tool-use mode में app के HTTP endpoints को सीधे call किया
    • हर tool app state के एक या अधिक event handlers से map होता है, और वही functions इस्तेमाल होते हैं जिन्हें button click trigger करता है
    • rendered page की जगह agent को structured responses मिलते हैं

base prompt पर vision agent क्यों fail हुआ

  • दोनों agents को वही छह-वाक्य वाला task देकर run किया गया
  • API agent ने 8 calls में task पूरा कर लिया
    • pending status से filtered customer reviews list किए
    • हर review को approve किया
    • order को shipped mark किया
  • दोनों agents ने वही application logic call किया, लेकिन API agent ने rendered page देखने के बजाय structured responses सीधे पढ़े
  • vision agent ने उसी prompt पर 4 pending reviews में से केवल 1 ढूंढकर approve किया और अगले step पर बढ़ गया
  • बाकी 3 reviews review page के visible area के नीचे थे, और agent को scroll करने का कोई signal नहीं मिला
  • यह failure model reasoning की समस्या नहीं थी, बल्कि rendered page यह signal देने में विफल रहा कि पूरी content दिखाई नहीं दे रही है
  • API agent ने वही handlers call किए जिन्हें UI call करता है, लेकिन response में सिर्फ current rendered rows नहीं, बल्कि handler द्वारा लौटाया गया पूरा result set शामिल था
  • API agent ने pixels से pagination controls interpret नहीं किए, बल्कि “50 items per page के साथ 4 pages में से page 1” जैसी जानकारी सीधे पढ़ी

14-step UI guidance जोड़ने पर क्या हुआ

  • fair comparison के लिए vision prompt को explicit UI walkthrough के रूप में फिर से लिखा गया
  • sidebar items, tabs, form fields जैसे UI elements को नाम से बताया गया जिनसे agent को हर step पर interact करना था
  • वह navigation process जिसे agent पहले खुद नहीं ढूंढ पाया था, उसे 14 numbered instructions में लिखा गया
  • यह guidance देने पर vision agent ने task पूरा कर लिया
  • हालांकि execution में 14 मिनट लगे और लगभग 5 लाख input tokens खर्च हुए
  • हर numbered instruction token count में दिखाई नहीं देता, लेकिन वह वास्तविक engineering cost को दर्शाता है
  • internal tools में vision agent deploy करने के लिए या तो इस स्तर के detailed prompts लिखने होंगे, या यह मानना होगा कि agent चुपचाप कुछ काम miss कर सकता है

execution pattern और variability

  • API path को 5 बार, vision path को 3 बार run किया गया
  • vision path का एक run 14–22 मिनट लेता था और 4 लाख–7.5 लाख tokens खर्च करता था, इसलिए उसे 3 runs तक सीमित रखा गया
  • vision path में runs के बीच variance काफी अधिक था
    • 3 runs में wall-clock time 749 seconds से 1257 seconds तक रहा
    • input tokens 4,07,000 से 7,51,000 तक रहे
    • सबसे छोटा run 43 cycles और सबसे लंबा 68 cycles में पूरा हुआ
  • screenshot-reasoning-click loop में इतनी non-determinism थी कि केवल एक run से representative cost estimate करना मुश्किल था
  • API path में ऐसी variability नहीं थी
    • Sonnet ने सभी 5 runs में बिल्कुल 8 tool calls ही उपयोग किए
    • input token count सभी 5 runs में केवल ±27 के भीतर बदला
    • structured responses agent को भटकने का कारण नहीं देते, इसलिए उसने हर बार वही handlers उसी order में call किए

कुल results

metric Vision agent (Sonnet) API (Sonnet) API (Haiku)
steps / calls 53 ± 13 8 ± 0 8 ± 0
wall-clock time 1003 seconds ± 254 seconds, लगभग 17 मिनट 19.7 seconds ± 2.8 seconds 7.7 seconds ± 0.5 seconds
input tokens 550,976 ± 178,849 12,151 ± 27 9,478 ± 809
output tokens 37,962 ± 10,850 934 ± 41 819 ± 52
  • संख्याएँ average ± sample standard deviation (n−1) हैं; API path के लिए n=5 और vision path के लिए n=3 है
  • पूरे execution details repository में देखे जा सकते हैं
  • Haiku vision path पूरा नहीं कर सका
  • failure browser-use 0.12 के structured output schema तक सीमित था, क्योंकि Haiku vision mode और text-only mode दोनों में इसे reliably generate नहीं कर पाया
  • API path में Haiku ने 8 seconds से कम और 10,000 से कम input tokens में task पूरा किया, और यह tested configurations में सबसे सस्ता था

structural cost gap

  • लागत का अंतर सीधे architecture से आता है
  • जो agent देखने के बाद ही action ले सकता है, उसे model बेहतर हो जाने पर भी देखने की लागत हमेशा चुकानी पड़ेगी
  • बेहतर vision models screenshot per error rate घटा सकते हैं, लेकिन वे संबंधित data तक पहुंचने के लिए जरूरी screenshots की संख्या कम नहीं करते
  • हर rendering एक screenshot है, और हर screenshot हजारों input tokens बन जाता है
  • दोनों agents उसी application logic से गुजरते हैं
    • दोनों UI की तरह ही filtering, pagination और updates करते हैं
    • फर्क इस बात में है कि हर step पर वे क्या पढ़ते हैं
  • vision agent pixels पढ़ता है, और हर intermediate state को render करके interpret करना पड़ता है
  • API agent उसी handlers से निकले structured responses पढ़ता है, जिनमें वह data पहले से होता है जिसे UI दिखाना चाहता था
  • बेहतर model step per cost घटा सकता है, लेकिन steps की संख्या interface तय करता है, इसलिए वह कम नहीं होती

जब API engineering cost कम हो जाए तो निर्णय कैसे बदलता है

  • benchmark को Reflex 0.9 की वजह से कम लागत पर चलाया जा सका
  • Reflex 0.9 में ऐसा plugin शामिल है जो Reflex application के event handlers से HTTP endpoints auto-generate करता है
  • structural argument Reflex पर निर्भर नहीं है, लेकिन Reflex ने API path को अलग codebase के बिना चलाना संभव बना दिया
  • मुख्य बिंदु यह है कि जब API surface की engineering cost लगभग शून्य हो जाए, तो क्या संभव हो जाता है
  • vision agent अब भी उन applications के लिए उपयुक्त है जिन्हें आप सीधे control नहीं करते
    • third-party SaaS products
    • legacy systems
    • ऐसे applications जिन्हें modify नहीं किया जा सकता
  • लेकिन जो internal tools आप खुद बनाते हैं, उनमें cost equation उलट जाती है

experiment की सीमा और सावधानियाँ

  • vision results browser-use 0.12 vision mode तक सीमित हैं; दूसरे vision agents अलग तरह से व्यवहार कर सकते हैं
  • path B runner ने auto-generated endpoints को लगभग 30 lines की एक छोटी REST tool surface में बदला
  • agent ने इन्हें list_customers, update_order जैसे tools के रूप में देखा
  • dataset fixed और छोटा है
    • 900 customers
    • 600 orders
    • 324 reviews
  • production-scale data पर behavior नहीं मापा गया
  • vision agent को LangChain के ChatAnthropic के जरिए चलाया गया
  • API agent को सीधे Anthropic SDK के जरिए चलाया गया
  • reported token counts uncached input tokens हैं

पुनरुत्पादन सामग्री

  • repository में seed data generation, patched react-admin demo, दोनों agent scripts, और raw results शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News टिप्पणियाँ

  • एजेंट के लिए वेबसाइट नेविगेट करना महंगा बनाने का तरीका यहीं छिपा है: माउस हिलते ही स्क्रीन एलिमेंट्स को इधर-उधर कर दो, UI तभी काम करे ऐसा बनाओ कि natural mouse movement ज़रूरी हो, हर विज़िट पर JS में बटन लेबल्स को रैंडम नामों से बदल दो, और छिपे हुए अतिरिक्त काम देखने के लिए स्क्रीन के बिल्कुल नीचे तक स्क्रॉल करवाओ
    रुको, यह तो किसी आम enterprise SaaS app जैसा लग रहा है

    • यह अजीब है कि जो लोग पहले यकीन नहीं करते थे, वे AI की वजह से अचानक अच्छे software engineering practices, खासकर spec लिखने, में मेहनत करने लगे हैं
      इंसानों के लिए यह करने की इच्छा नहीं थी, लेकिन AI को इसकी ज़रूरत है तो सब लग गए हैं। यह दिलचस्प भी है और थोड़ा उदास भी। लगता है कि वे यह सिर्फ AI के लिए कर रहे हैं, क्योंकि इससे किसी अमूर्त भविष्य के व्यक्ति की बजाय उन्हें व्यक्तिगत फायदा महसूस होता है
    • असल बात यह है कि इसे ऐसा बनाया जाए जो इंसान करना चाहें। [0] की तरह interactive elements को move कराया जा सकता है, और context के हिसाब से environment के साथ interact कराया जा सकता है
      [0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
    • लगता है कि आखिरकार ASP WebForms वही तकनीक थी जिसकी हमें हमेशा ज़रूरत थी
    • पहले एक desktop app वाला प्रोजेक्ट था जो सारे grid control contents को जानबूझकर Windows accessibility API से छिपाता था, accessibility API से checkbox या radio button चुनने पर भी उसे लागू नहीं होने देता था, और data export features को CAPTCHA से protect करता था
      वह generative AI से पहले का दौर था, लेकिन app चलाने और data export करने के लिए OCR, simulated user input, और print capture को जोड़ना पड़ता था। अगर developers को Windows DRM API के बारे में पता होता जो screen capture रोक सकती है, या यह कि PostScript files से minimum formatting के साथ text आसानी से निकाला जा सकता है, तो पता नहीं वे क्या करते
      विडंबना यह थी कि इसे replace करने से पहले की प्रक्रिया में सस्ते offshore workers को system के सारे data पर read-only remote access दी जाती थी, जो trusted vendor के local tool से approved employees द्वारा बिना network access के automation करने की तुलना में कहीं बड़ा security risk था

  • मैं ठीक इसी समस्या को हल करने वाली चीज़ बना रहा हूँ[1]
    landing page पर अभी इसे आगे नहीं रखा है, लेकिन मूल रूप से यह agents को app surface explore करने के लिए छोटे tools का सेट और खासकर accessibility से जुड़े सामान्य macOS feature APIs देता है
    agent app को explore करने के बाद repeatable workflows लिख सकता है, और बाद में उन्हें CLI से invoke chrome pinTab की तरह चला सकता है
    accessibility इस्तेमाल करने का कारण यह है कि अंततः यह apps के लिए एक अच्छा DOM है। हर app इसे perfectly implement नहीं करता, लेकिन काफी apps करते हैं, इसलिए यह बहुत उपयोगी है
    [1] https://getinvoke.com - मौजूदा landing page creators के लिए है, इसलिए अभी यह use case शामिल नहीं है

    • अगर agents की वजह से अच्छी accessibility (a11y) मिलती है, तो मैं इसे स्वीकार कर सकता हूँ। बड़बड़ाऊँगा ज़रूर, लेकिन मान लूँगा
    • अगर आप macOS पर इस क्षेत्र में रुचि रखते हैं, तो system-provided Accessibility Inspector.app खोलकर apps और browser को सीधे छूकर देखने की ज़ोरदार सिफारिश करता हूँ
      आप देख सकते हैं कि हरे cells कैसे LLM को स्क्रीन के सिर्फ खास हिस्से पढ़ने या OCR करने के लिए guide कर सकते हैं, accessibility engine में कितना text पहले से built-in होता है, और यह कैसे सिर्फ MCP ही नहीं बल्कि workflow की accessibility layer को crawl करने वाले scripts को खुद बनाकर चलाने वाले code generator तक ले जा सकता है
      मुझे यह बहुत उपजाऊ क्षेत्र लगता है। बड़े labs को ऐसा approach लेना पड़ता है जो कई platforms और arbitrary workflows पर काम करे, और full-screen vision सबसे निचला common denominator है। platform-specific approaches वाकई बहुत दिलचस्प खुला क्षेत्र हैं
    • सब लोग एक ही computer-use task बार-बार दोहराकर tokens बर्बाद करने के बजाय, workflow sharing का तरीका बनाना एक अच्छा समाधान है
      बस यह पक्का करना होगा कि password जैसी user जानकारी निकालने वाले workflows शेयर न हो सकें
    • दिलचस्प है। मैंने भी कुछ वैसा शुरू किया था, हालांकि उसका polish बहुत कम है और वह काफी अलग है, लेकिन वह भी accessibility UI elements का इस्तेमाल करता है
      बड़ी समस्या यह है कि बहुत सारे apps इन elements को expose करने में बेहद खराब हैं। मेरा approach UIAccess या vision model के one-time pass का इस्तेमाल करके UI templates बनाना था: https://github.com/willwade/app-automate?tab=readme-ov-file#...
      इस पर reddit में दिया गया counterpoint यह है कि असली अनुभव लगभग उलटा है। UIA docs में uniform दिखता है, लेकिन WPF, WinForms, और Win32 सब अलग control patterns expose करते हैं, इसलिए आखिर में toolkit-specific handlers लिखने पड़ते हैं। Qt में कुछ expose होने के लिए QAccessible compile होना चाहिए और accessibility plugin runtime पर load होना चाहिए, लेकिन shipped binaries में ऐसा लगभग कभी नहीं होता। Electron, Windows पर भी, macOS जितना ही opaque है, क्योंकि आखिर में वही Chromium canvas पर draw कर रहा होता है। असली फर्क operating system बनाम operating system नहीं, बल्कि native toolkit बनाम बाकी सब है

  • यह कहना कि हर app के लिए MCP या REST surface लिखना एक अलग engineering project है, ज़रूरी नहीं कि सही हो, अगर backend frontend से पर्याप्त रूप से अलग हो और server-side operations को सोच-समझकर और सामान्य तरीके से design किया गया हो

  • मैं सोच रहा हूँ कि क्या vision agent से UI का “map” बनवाकर, किसी दूसरे agent के लिए उसे ऐसे interfaces के सेट के रूप में expose किया जा सकता है जो API जैसे ज़्यादा लगें
    मेरी समझ से अभी vision agent को यह दोनों बातें जाननी होती हैं: कि “next page” ज़्यादा results दिखाता है, और यह भी कि पहले place में उसे और results लाने चाहिए
    अगर एक agent सिर्फ test environment जैसी जगह में UI explore करके कई UI elements और actions का कुछ structured description बना दे, और दूसरा agent वही description ले, तो क्या वह उस agent से बेहतर करेगा जो UI exploration और task execution दोनों साथ करता है
    उदाहरण के लिए, “सभी reviews लाओ” को इस तरह define किया जा सकता है कि हर page पर जाओ और हर review summary के लिए “full review देखें” क्लिक करो; और “हर page पर जाना” को इस तरह कि review tab के default page 1 से शुरू करो और “next” button गायब होने तक उसे दबाते रहो
    तब दूसरे agent को navigation के बारे में कम सोचना पड़ेगा क्योंकि उसके पास पहले से वह technique होगी, और पहले agent को test environment में सिर्फ एक बार बिना गलती की चिंता के UI explore करना होगा। हो सकता है मैंने लेख को पूरी तरह गलत समझा हो, लेकिन फिर भी यह दिलचस्प है

    • मेरे मन में भी पहले यही आया था। आजकल web development code generation पर बहुत निर्भर है, फिर उसके ऊपर obfuscation और compression चढ़ा दी जाती है, और उसके ऊपर client-side JavaScript फिर से सब कुछ reconstruct कर देता है
      अंत में आपको जटिल HTML/CSS/JavaScript से रास्ता बनाना पड़ता है। अच्छा हो या बुरा, किसी web app का 5~10MiB होना अब दुर्लभ नहीं है
      browser engine जो करता है उसे लगभग उल्टा करते हुए “bottom-up” जाने की बजाय, इंसानों की तरह visual presentation देखकर “top-down” जाना आसान लगता है
    • यह सही लगता है। agents को वैसे ही वेबसाइट कैसे काम करती है यह सीखने दिया जा सकता है जैसे हम सीखते हैं, और उस model को एक simple API के रूप में expose किया जा सकता है
      navigation के लिए थोड़ी vision work फिर भी बचेगी, लेकिन वह ऐसी simple vision work होगी जिसमें ज्यादा सोचने की ज़रूरत नहीं होगी
    • मुझे नहीं लगता कि vision agent से “map” बनवाना आसान होगा। ज़्यादातर vision models image→text करते समय एक बार में image के सिर्फ हिस्से पर ध्यान देते हैं
      image→image पूरे image का इस्तेमाल करता है

  • मुझे आधार धारणा समझ नहीं आती। अगर यह internal app है, तो computer use क्यों निकाला जाए, और agent से CLI या MCP क्यों न बनवाया जाए
    जाहिर है computer use बदतर है। वह last resort है। जिस state का संबंध मेरे अपने DB से हो, उसके लिए इसका इस्तेमाल नहीं करना चाहिए
    बल्कि यह प्रभावशाली है कि यह सिर्फ 50 गुना बदतर है

  • पूरी तरह सहमत। हाल में AI visual tools बनाते समय मैंने दोनों approaches आजमाए, और general-purpose “agentic” browser usage की latency और cost आज के real-time consumer apps के लिए घातक है
    structured APIs, यहाँ तक कि strict JSON schema वाली LLM call chains, सिर्फ 40 गुना सस्ती ही नहीं हैं, बल्कि इतना निर्णायक फर्क देती हैं कि सच में stable product ship किया जा सके। computer use शानदार demo है, लेकिन server bills structured APIs ही भरते हैं

    • “agentic engineering” बस token providers की revenue बढ़ाने के लिए एक fad था
      अगर आपको लगता है कि LLM किसी काम में अच्छा है, तो उस purpose के लिए Openrouter के ऊपर अच्छी तरह defined और बहुत deterministic middleware बनाइए

  • structured APIs में सच में सोचने की ज़रूरत होती है, और आजकल सोचना अच्छी चीज़ नहीं माना जाता

  • कुछ महीने पहले मैंने kubectl से प्रेरित होकर GUI apps को control करने के लिए desktopctl CLI बनाया
    Mac पर यह OCR और Accessibility API को मिलाकर UI को Markdown में represent करता है और mouse व keyboard actions को expose करता है
    मूल विचार यह है कि “fast” perception loop को पूरी तरह local रखा जाए, UI tokenization और change detection के लिए GPU-optimized बनाया जाए, जबकि “slow” control loop को LLM roundtrip चाहिए और CLI output के लिए token-efficient Markdown interface इस्तेमाल किया जाए
    controls के लिए अपेक्षाकृत stable identifiers इस्तेमाल किए जाते हैं, इसलिए agent desktopctl pointer click --id btn_save जैसी सामान्य actions को script कर सकता है और UI tokenization loop की ज़रूरत नहीं पड़ती
    https://github.com/yaroshevych/desktopctl/tree/main

    • APIs की तुलना में human interfaces धीमे और गंदे होते हैं, लेकिन मैंने सीखा कि उनके पीछे भी काफी science है
      अच्छे apps जानकारी को अच्छी तरह surface करते हैं और clicks, typing वगैरह के लिए optimize होते हैं
      सबसे अच्छे GUIs muscle memory का अच्छा इस्तेमाल करते हैं, इसलिए वे CLI से script करने के लिए बेहतरीन उम्मीदवार बनते हैं। उदाहरण के लिए “Notes app खोलो, Cmd+F दबाओ, search term डालो, results list पढ़ो” जैसी simple sequence एक Bash command बन सकती है जिसे AI agent call करे

  • “computer use” की पूरी अवधारणा पर मैं हमेशा से संदेह में रहा हूँ। यह वैसा है जैसे किसी को hire करके घर के अंदर लाना, उसे अपने बिस्तर पर सोने देना, बाथरूम इस्तेमाल करने देना, फ्रिज का खाना खाने देना, TV देखने देना, और यह भी बता देना कि तिजोरी का password यहीं है
    लेकिन जिसे hire किया गया है वह बंदर है

    • क्या मैं पागल हो गया हूँ? यह देखकर हैरानी होती है कि एक software द्वारा दूसरे software से query और command करने का तरीका बनाने की क्षमता न होने के कारण, हम AI को माउस घुमाते हुए इधर-उधर क्लिक करने दे रहे हैं
    • निष्पक्षता से देखें तो, हम बस चाहते हैं कि वह बंदर मेरे बजाय वह बंदर-जैसा काम कर दे जो मैं खुद नहीं करना चाहता

  • अभी जो websites Claude Code या दूसरे AI agents को रोक रही हैं, वे हारने वाली लड़ाई लड़ रही हैं
    computer use अभी शुरुआती दौर में है, और mass adoption को रोकने वाली चीज़ ज़रूरी tokens की संख्या लगती है। अगर agent सही command ढूँढने से पहले 10 CLI commands बेकार आजमा ले, तो हमें लगभग फर्क नहीं पड़ता
    लेकिन browser use या computer use जैसे visual agents के साथ, चाहे वे आखिरकार सही जगह पहुँच भी जाएँ, हमारे पास एक button click करने के लिए 20 मिनट इंतज़ार करने का धैर्य नहीं है। अगर tokens सस्ते और तेज़ हो जाएँ, तो ऐसे models आ सकते हैं जो UI interfaces को CLI जितनी सहजता से इस्तेमाल करें

    • मुझे नहीं लगता कि tokens और सस्ते होंगे। venture funding से subsidized tokens user base बनाने के लिए थे, और आखिरकार growth से profitability पर जाते समय token prices बढ़ेंगी ही लगता है
    • और एक घातक त्रयी भी है। फिलहाल सभी agents के साथ यही स्थिति है, लेकिन सभी AI providers browsers में AI को personal data access देने पर कड़ी चेतावनी लगा रहे हैं
    • असल में LLM providers को कोई नहीं रोक सकता। वे content scan करने के लिए disguised requests इस्तेमाल करते हैं, और कभी-कभी residential proxies भी
    • इसका 100% effective होना ज़रूरी नहीं है। बस इतना डर पैदा करना काफी है कि account suspend होने के डर से लोग कोशिश ही न करें
    • mass adoption को रोकने वाली चीज़ token count से ज़्यादा बहुत बड़ी लागत, बढ़ती बिजली की बर्बादी, और उपलब्ध पानी की बर्बादी है