Context Engineering: چرا agent شما در نوبت 40 کم‌هوش‌تر می‌شود

Anthropic در سپتامبر 2025 خط مرز را کشید و این دو جمله باید کنار هم باشند. prompt engineering یعنی «روش‌هایی برای نوشتن و سازمان‌دهی دستورالعمل‌های LLM برای نتایج بهینه». Context engineering یعنی «مجموعه راهبردها برای گزینش و نگه‌داری مجموعه بهینه tokenها (اطلاعات) هنگام inference در LLM، شامل همه اطلاعات دیگری که ممکن است بیرون از promptها در آنجا قرار بگیرد».¹

تفاوت عملیاتی در چه زمانی و به‌دست چه کسی است. prompt یک‌بار، به‌دست انسان، نوشته و بازبینی می‌شود. context در هر call، به‌دست کدی که کسی به آن نگاه نمی‌کند، از موادی که هیچ‌کس دستی ننوشته، ساخته می‌شود: چهل نوبت تاریخچه، شش نتیجه ابزار، چهار passage بازیابی‌شده، پروفایل کاربر، دوازده schema در JSON. فصل 15 اندازه گرفت دستورهای بهتر چه چیزی می‌خرند. این فصل درباره نود درصد دیگر tokenهاست، که خودشان از راه می‌رسند.

همان سند منبعی را نام می‌برد که همه‌شان خرج می‌کنند: مدل‌ها «یک attention budget دارند که هنگام parse کردن حجم‌های بزرگ context از آن خرج می‌کنند. هر token جدیدی که معرفی می‌شود، این بودجه را تا حدی تخلیه می‌کند». و نشانه را هم نام می‌برد: «هرچه تعداد tokenها در context window افزایش می‌یابد، توانایی مدل برای recall دقیق اطلاعات از آن context کاهش پیدا می‌کند» — context rot.¹

آن جمله آخر ادعایی درباره رفتار است، یعنی می‌شود آن را بررسی کرد، و جدول بالای این صفحه همان بررسی است.

چهل خط در برابر endpoint محلی از فصل 22 — یک سرور کوچک Python که Qwen2.5-0.5B-Instruct را روی CPU نگه می‌دارد و شکل chat-completions را صحبت می‌کند، تا حلقه TypeScript بماند و tensorها آن سوی port بمانند.

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

شمارنده other همان چیزی است که یک نتیجه ناامیدکننده را به نتیجه‌ای مفید تبدیل می‌کند: وقتی مدل اشتباه می‌کند، گم شده یا مطمئن است؟

پاسخ، مطمئن است. در هشت جایگاه غیر اول، 136 مورد از 205 پاسخ اشتباه، داخلی یک ticket دیگر بود — یک عدد چهاررقمی واقعی، با قالب درست، خوانده‌شده از خط اشتباه. در جایگاه 1 فقط یکی از پنج خطا چنین بود؛ در جایگاه 7، بیست‌ویک مورد از بیست‌وشش.

همین تمایز در production مهم است. مدلی که می‌گوید نمی‌توانم پیدایش کنم باگی است که متوجهش می‌شوید؛ مدلی که شماره ردیف کناری را برمی‌گرداند باگی است که ship می‌کنید، چون روی صفحه این دو یکسان به نظر می‌رسند. این همان شکستی است که فصل 19 citationهای قابل‌راستی‌آزمایی را علیه آن ساخت، با این تفاوت که از داخل prompt می‌آید نه از index.

جایگاه یک محور است. طول محور دیگر است، و آزمودنش آسان‌تر: پاسخ را در میانه نگه دارید و فهرست را بزرگ کنید.

یک رکورد و 97 token: 90٪. سه رکورد و 159 token: 55٪. هشت رکورد و 315 token: 15٪، و از آنجا تا 140 رکورد و 4,477 token پایین و تقریباً ثابت می‌ماند. کل فروپاشی بین خط اول و هشتم یک فهرست رخ می‌دهد.

ستون آخر همه چیزهایی است که نه داخلی درست‌اند و نه داخلی رکوردی دیگر؛ وقتی فقط یک رکورد روی صفحه است، پاسخ اشتباه فقط همان‌جا می‌تواند بیفتد. دو خطا در یک رکورد ارزش گزارش کردن دارند، نه گرد کردن و حذف شدن، چون هیچ‌کدام refusal نبود: یکی به فهرستی که تنها خطش 5805 بود، پاسخ 5806 داد. با 97 token و فقط یک candidate، این مدل هنوز در بیست بار، دو بار یک رقم را اشتباه کپی می‌کند، و این کفِ چیزی است که هرچیز دیگر نسبت به آن سنجیده می‌شود.

دو نتیجه دنبال می‌شود. context بزرگ‌تر حق فرستادن بیشتر را می‌خرد، نه قطعیت خوانده شدن را: این مدل یک window با 32,768 token دارد و دامنه کاری‌اش، روی این کار، چند صد token است. و هیچ threshold، هیچ cliff، هیچ وضعیت «context full» وجود ندارد — افت از رکورد سوم در جریان است و تا هشتم کامل می‌شود، در یک درصد window. هرچه limit مربوط به context باشد، آن چیزی نیست که این را حکمرانی می‌کند.

معمولاً دو سازوکار پیشنهاد می‌شود. اولی همان حساب فصل 9 است، که Anthropic با همان واژه‌هایی بیان می‌کند که این دوره به کار می‌برد: مدل‌ها «بر پایه معماری transformer هستند، که به هر token امکان می‌دهد در سراسر context کامل به هر token دیگر attention بدهد. نتیجه، n² رابطه دوتایی برای n token است».¹ attention روی دنباله‌ای طولانی‌تر همان عملیات اعمال‌شده به مواد بیشتر نیست؛ یک بودجه ثابت از جرم احتمال است که میان رقیب‌های بیشتر پخش می‌شود. دومی training است: مدل‌ها دنباله‌های کوتاه را بسیار بیشتر از دنباله‌های بلند می‌بینند، پس الگوهای positional دوربرد کم‌تمرین‌ترین بخش شبکه‌اند. این یک استدلال است، نه یک اندازه‌گیری، و این فصل نمی‌تواند آن را فیصله دهد.

آنچه فیصله یافته شکل ماجراست، و از 2023 چنین بوده است. Liu و همکاران پرسش‌پاسخ چندسندی و key-value retrieval را در خانواده‌ها و اندازه‌های مختلف مدل آزمودند و دریافتند که «عملکرد اغلب وقتی اطلاعات مرتبط در آغاز یا پایان input context رخ می‌دهد بیشینه است، و وقتی مدل‌ها باید به اطلاعات مرتبط در میانه contextهای بلند دسترسی پیدا کنند به‌طور معنادار افت می‌کند، حتی برای مدل‌هایی که صراحتاً long-context هستند».² فصل 15 قانون جایگاه خود را از آن مقاله گرفت؛ فصل 19 از آن دلیل اینکه بیست chunk بازیابی‌شده می‌تواند بدتر از چهار تا امتیاز بگیرد را برداشت. شکل عملی این واقعیت تنها جمله‌ای است که اینجا باید براساسش عمل کنید: اندازه‌گیری این موضوع روی مدل خودتان و با داده خودتان پنج دقیقه طول می‌کشد، و هیچ منحنی منتشرشده‌ای جای منحنی شما را نمی‌گیرد.

از یک تیم بپرسید چه چیزی context مربوط به agentشان را پر می‌کند و یک تخمین می‌گیرید، چون هیچ API پاسخ را برنمی‌گرداند: response به شما prompt_tokens می‌دهد، یک عدد برای همه‌اش.

می‌توانید breakdown را با چهار شمارش و سه تفریق بازسازی کنید — کل prompt رندرشده، همان بدون tool definitionها، system message تنها با آن‌ها و بدون آن‌ها، و همه چیز با حذف tool resultها:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

countPrompt پیش از tokenizing، chat template خود مدل را اعمال می‌کند، و این از چیزی که به نظر می‌رسد مهم‌تر است: متن شما آن چیزی نیست که شمرده می‌شود. role markerها، پیش‌درآمد tool calling و رندر schema همگی tokenهایی هستند که برایشان پول می‌دهید و هرگز تایپ نکرده‌اید. فصل 7 یک tokenizer ساخت و فصل 16 با js-tiktoken شمارش کرد؛ اینجا شمارش از همان مدلی می‌آید که prompt را خواهد خواند، و این تنها شماری است که دقیقاً درست است.

حالا یک agent واقعی را از آن عبور دهید: چهل نوبت از بررسی یک incident، دوازده ابزار، و یک محیط عملیاتی ساختگی که log dumpها و سری‌های metric واقع‌گرایانه برمی‌گرداند.

ردیف اول را در برابر آخرین ردیف بخوانید.

در turn 1، prompt برابر 2,547 token است و 71٪ آن tool definitionهاست. system prompt سه درصد است. آنچه کاربر تایپ کرده 6٪ است. agent هنوز هیچ کاری نکرده و همین حالا 1,817 token از JSON schema را حمل می‌کند.

تا turn 40، prompt برابر 10,632 token است و سهم‌ها وارونه شده‌اند: definitionها 17٪، conversation بیست‌ونه درصد، tool resultها 53٪. output ابزار در turn 5 از definitionها پیشی گرفت؛ conversation تا turn 25 از آن‌ها پیشی نگرفت، پس در شصت درصد اول session کاتالوگ ابزارها از هرچیزی که گفته شده بود بزرگ‌تر بود.

بعد کل. در 57 model call، اجرا 370,291 input token برای context نهایی 10,632 صورتحساب شد — prompt آخر تقریباً سی‌وپنج بار پرداخت شده، همان درجه‌دوی فصل 16 با multiplier مربوط به agent روی آن. از آن 370,291، 103,569، یا 28٪ همه چیزِ صورت‌حساب‌شده، دوازده tool definition بودند، که در هر call عیناً و byte-identical دوباره فرستاده شدند.

کاتالوگ ابزار بزرگ‌ترین هزینه ثابت در یک agent است و نامرئی است، چون هرگز آن را نمی‌بینید: شما آرایه‌ای از objectها را پاس می‌دهید و provider آن را برایتان داخل prompt رندر می‌کند. روی همان دوازده ابزار اندازه‌گیری شد:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

به ازای هر ابزار، هزینه marginal از 80 token برای get_current_time شروع می‌شود، که یک string می‌گیرد، تا 263 برای search_tickets، که چهار parameter با یک enum و برای هرکدام یک جمله راهنما می‌گیرد. این همان نرخ تبدیلی است که پشت توصیه مرکزی فصل 18 قرار دارد که description همان API است: یک description خوب برای باقی عمر agent، در هر request حدود صد token هزینه دارد. سه پیامد.

ابزاری که استفاده نمی‌کنید هم صورتحساب می‌شود. agent از دوازده ابزار، هفت تا را call کرد. پنج تای دیگر در هرکدام از 57 request، 697 token هزینه داشتند — در مجموع 39,729، بیش از یک‌دهم همه چیزی که اجرا بابت آن صورتحساب شد، برای قابلیت‌هایی که هرگز لمس نکرد. یکی از آن پنج مورد تیزترین جزئیات trace را حمل می‌کند: مدل سه بار تلاش کرد read_log را call کند، که وجود ندارد. ابزاری که می‌خواست search_logs بود، دومین definition گران در کاتالوگ با 237 token. مدل 57 بار هزینه آن definition را پرداخت، هرگز از آن استفاده نکرد، و هرگز نامش را پیدا نکرد.

کوتاه کردن نثر ارزان‌ترین بهینه‌سازی موجود است، و یک trade-off است. کوتاه کردن descriptionها به یک جمله و حذف documentation مربوط به parameterها، 526 token در هر call ذخیره کرد، 29 درصد، بدون دست‌زدن به یک خط منطق — و باعث شد مدل ابزارها را بدتر call کند، همان چیزی که فصل 18 اندازه گرفت. نکته این است که هر دو سوی آن trade-off حالا در یک واحدند.

در مقیاسی، اصلاً فرستادن definitionها دیگر منطقی نیست. Anthropic در نوامبر 2025 برایش عدد گذاشت: مجموعه بزرگی از serverهای متصل یعنی پردازش «صدها هزار token» از definitionها پیش از اینکه request خوانده شود، و جایگزین کردن آن با اجرای code — یعنی agent فقط definitionهایی را کشف و load کند که نیاز دارد — «token usage را از 150,000 token به 2,000 token کاهش می‌دهد، صرفه‌جویی زمانی و هزینه‌ای 98.7٪».³ همان ایده بقیه این فصل، اعمال‌شده به schemaها به‌جای history: index را نگه دارید، entry را on demand resolve کنید.

دو چیز در آن transcript چهل‌نوبتی کاشته شد. در turn 2، پیش از هر کار واقعی، کاربر یک قانون ثابت اعلام می‌کند: هر ticketی که باز می‌کنی باید زیر شماره کارمندی من، 4417، ثبت شود. در turn 19، وسط incident، یک واقعیت: shard آسیب‌دیده pay-shard-7 است، تأییدشده توسط تیم payments. در turn 40 کاربر از agent می‌خواهد incident ticket را باز کند، که به هر دو نیاز دارد. هر probe در شش عبارت‌بندی متفاوت پرسیده و از شش نمره‌گذاری می‌شود — greedy decoding deterministic است، پس یک call یک بله یا نه تکرارناپذیر می‌دهد و شش تا یک نرخ می‌دهد.

سپس transcript زیر هفت context policy replay می‌شود. عمداً replay می‌شود نه re-run: پیام‌ها، tool callها و tool resultها در هر هفت مورد byte-identical هستند، پس تنها متغیر این است که هر policy چه چیزی را برای نگه‌داشتن انتخاب کرد. فصل 16 نشان داد چرا sliding window از نظر اقتصادی حرکت بدی است، چون prefix قابل cache را نابود می‌کند. اینجا می‌بینید با رفتار چه می‌کند:

ردیف‌های compaction شامل هزینه compact کردن هم هستند: 18,581 input token برای هفت summary و 3,392 دیگر برای note-taker. ردیف کنترل آنجاست تا صفر به‌عنوان صفر خوانده شود — با فقط همان دو پیام در promptی 1,981-token، این مدل هر دو probe را کامل پاسخ می‌دهد، پس هیچ ردیفی به این دلیل نیست که کار زیادی سخت بوده.

full history به خاطر می‌سپارد، و گران‌ترین چیز روی جدول است: 370,291 input token برای sessionای که محتوای durable آن دو جمله است.

این به پرسشی پاسخ می‌دهد که آغاز متن باز گذاشت. چرا یک transcript با 10,632 token واقعیتی را نگه می‌دارد که یک فهرست 853-token از دست می‌دهد؟ چون طول متغیر اشتباهی است. فهرست بیست‌وپنج داخلی چهاررقمی را در بیست‌وپنج جمله یکسان نگه می‌دارد — بیست‌وچهار decoy تقریباً کامل برای همان چیزی که می‌خواهید. transcript دقیقاً یک شماره کارمندی و یک نام shard دارد. Context rot پیش از آنکه حجم باشد، interference است، و به همین دلیل 136 مورد از 205 پاسخ اشتباه بالا مقدار یک همسایه بود. پرسش مفید درباره window این نیست که چقدر بلند است؛ این است که چند چیز داخلش شبیه پاسخ‌اند.

sliding window پنجاه‌وهفت درصد ارزان‌تر است و incident را از دست داده. شماره کارمندی فقط چون agent آن را در turnهای اخیر تکرار کرده بود زنده می‌ماند. shard که یک‌بار در turn 19 گفته شد، در آخرین دوازده message نیست — و مدل هم این را نمی‌گوید. شش بار که از آن پرسیده شد پاسخ داد «shard پرداخت آسیب‌دیده shard 4417 است»، به‌سمت شماره کارمندی دست دراز کرد، تنها identifier دیگر باقی‌مانده در window آن، و دو بار «pool»، که از string pool_exhausted در یک log line برداشته شده بود.

compaction ارزان است و همان fact را از دست داد. هفت summary، نوشته‌شده توسط مدل زیر دستور صریح برای نگه‌داشتن identifierها، عددها، دستورهای ثابت و پرسش‌های باز، و pay-shard-7 در هیچ‌یک از مواردی که مهم بود نبود؛ شش حدس shard 1، pay_shard_1 و pool بودند. compaction با صدای بلند fail نمی‌شود. یک session روان، پذیرفتنی و بسیار کوتاه‌تر تولید می‌کند که بی‌سروصدا یک خط را انداخته است.

سه ردیف روی واقعیت turn 19 امتیاز 0/6 گرفتند — sliding window، compaction و compaction با note. هجده پاسخ اشتباه میان آن‌ها، و حتی یکی از آن‌ها «نمی‌دانم» نبود.

بعد ردیفی که باید خجالت‌آور باشد. نگه‌داشتن چهل message خود کاربر به‌صورت verbatim، به‌علاوه چهار turn آخر به‌طور کامل و هیچ‌چیز دیگر، 168,550 token هزینه دارد — 54٪ کمتر از full history — و هر دو probe را به‌اندازه full history یا بهتر پاسخ می‌دهد. نه summariser، نه note-taker، نه مدل دوم: فقط یک filter روی role === "user". کلمات کاربر ارزان‌ترین tokenهای پرارزش در window یک agent هستند، و بیشتر طراحی‌ها آن‌ها را همراه با بقیه چیزها دور می‌اندازند.

دو ردیف آخر همان جدول آغازین‌اند، داخل agent. همان block pin‌شده، جابه‌جا از system message به انتهای prompt: 5/6 به 6/6 تبدیل می‌شود. روی شش آزمایش این تفاوت معنادار نیست و چنین هم عرضه نمی‌شود — فقط یادآوری می‌کند که کجا پارامتری است که چه بدانید چه ندانید، دارید تنظیمش می‌کنید.

چهار راهبرد زیر متعلق به Anthropic هستند، به همان ترتیب، هرچند فقط سه مورد آخر فهرست long-horizon آن است.¹ هر چهار مورد variationهایی روی یک دستورند: چیزی را که می‌توانید fetch کنید حمل نکنید، و چیزی را که می‌توانید فشرده حمل کنید raw حمل نکنید.

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

sub-agent در جدول بالا نیست چون چهل turn اجرا نمی‌شود: یک‌بار اجرا می‌شود، در windowی که کسی برایش scope کرده. با دادن system prompt، turnهای 17 تا 19 و هیچ‌چیز دیگر — 2,737 token — probe مربوط به shard را 6/6 پاسخ داد، بهتر از هر policy در جدول، و probe مربوط به کارمند را 0/6، چون آن شماره در سه turnی که به آن داده شده بود نبود.

این یعنی sub-agentها در دو عدد: یک window تمیز intelligence نیست، scope است، و scoping از پیش توسط کدی انجام می‌شود که همین حالا هم باید بداند کدام turnها مهم‌اند. یک چیز دیگر در آن پاسخ‌ها ارزش نگه‌داشتن دارد. این تنها policy بود که به‌جای اختراع کردن، پاسخ داد «None available». مدلی با context کوچک و coherent می‌داند چه چیزی را ندارد؛ مدلی با context بزرگ و noisy نمی‌داند.

تقریباً هر گفت‌وگوی گیج‌کننده درباره memory مربوط به agent، سه سازوکار است که یک کلمه پوشیده‌اند. lifetime، owner و failure modeهای متفاوتی دارند، و سیستمی که آن‌ها را در یک جا نگه می‌دارد مشکلی دارد که هنوز متوجهش نشده است.

چارچوب دانشگاهی از CoALA می‌آید، که language agentها را حول «مولفه‌های memory ماژولار» سازمان می‌دهد و working memory را از storeهای episodic، semantic و procedural جدا می‌کند.⁴ MemGPT همین ایده را literal می‌گیرد، با قرض گرفتن virtual memory از operating systemها: یک لایه سریع داخل window، یک لایه کند بیرون آن، و خود مدل که داده را با function callها میانشان جابه‌جا می‌کند.⁵ هر دو پرسشی را تحمیل می‌کنند که product در هر صورت باید پاسخ دهد — نه چقدر می‌توانم نگه دارم، بلکه این به کدام store تعلق دارد، و کی expire می‌شود.

آزمون عملی برای هر fact یک پرسش است: فردا چه چیزی هنوز باید true باشد؟ یک tool result از turn 12، هیچ‌چیز. summary مربوط به session، تا پایان session. اینکه شماره کارمندی کاربر 4417 است، تا وقتی شغلش را عوض کند. سه پاسخ، سه store.

حالا می‌توانید اندازه بگیرید در یک window چه هست، تصمیم بگیرید چه چیزی در آن بماند، و تفاوت agentی را که چیزی را فراموش کرده با agentی که آن را حمل می‌کرده اما نگاه نکرده تشخیص دهید.

آخرین مورد از چهار راهبرد، همان است که اینجا جا نمی‌شود. sub-agent یک context policy نیست، agent دوم است، و لحظه‌ای که دو تا باشند باید تصمیم بگیرید چه چیزی میانشان پاس داده می‌شود و کدام در charge است. فصل 25 همین است: پنج الگوی orchestration و اینکه نام هرکدام واقعاً از کجا آمده، دو توپولوژی‌ای که با هم قاطی می‌شوند — پرسیدن از sub-agent و گرفتن پاسخ در برابر تحویل دادن conversation به آن و پس نگرفتنش — و یافته اندازه‌گیری‌شده که روی کاری که قیمت‌گذاری می‌کند، آرایش ساده‌تر می‌برد — و بعد آزمونی برای اینکه چه زمانی دیگر نمی‌برد.

همچنین دقیقاً همان چیزی را inherit می‌کند که این فصل همین حالا اندازه گرفت. sub-agent یک summary برمی‌گرداند. summary یک compaction است که شما ننوشته‌اید، تولیدشده توسط مدلی که window آن را نمی‌بینید، و والد راهی ندارد که good one را از confident wrong one تشخیص دهد — همان تمایزی که بالای این صفحه 84٪ را از 19٪ جدا کرد، و هجده fact گم‌شده را به هجده مورد اختراعی تبدیل کرد. پس: وقتی sub-agent اشتباه می‌کند، parent دقیقاً چه چیزی را می‌تواند نگاه کند؟

هر عدد اینجا روی همین ماشین تولید شد و هیچ‌کدام تخمین نیست. مدل Qwen2.5-0.5B-Instruct در float32 روی CPU با greedy decoding است، که over loopback توسط endpoint کوچک Python سرو می‌شود؛ endpointی که شکل chat-completions را صحبت می‌کند و route شمارش token را expose می‌کند — همان seam فصل 14 فصل 14، tensorها سمت Python و حلقه سمت TypeScript — پس هر count، tokenizer خود همان مدل است که روی chat template خودش اعمال شده. جدول position شامل 288 call است، نه جایگاه در سی‌ودو آزمایش با یک ticket متفاوت در هر آزمایش؛ جدول length شامل 140 call است؛ agent run شامل 57 model call طی 43 دقیقه wall clock است؛ جدول policy همان یک transcript است که زیر هفت policy replay شده. بازه‌ها Wilson هستند، از فصل 4. هیچ paid APIای call نشد، و به همین دلیل در فصل حتی یک price هم نیست: token countها دقیق‌اند و rateهایی که در آن‌ها ضرب می‌کنید متعلق به فصل 16 هستند.