Context Engineering: لماذا يصبح agent لديك أغبى عند الدور 40

رسمت Anthropic الخط في سبتمبر 2025، والجملتان تستحقان أن تقفا جنبًا إلى جنب. Prompt engineering هو «طرائق كتابة وتنظيم تعليمات LLM لتحقيق النتائج المثلى». Context engineering هو «مجموعة الاستراتيجيات الخاصة بتنظيم وصيانة المجموعة المثلى من tokens (المعلومات) أثناء استدلال LLM، بما في ذلك كل المعلومات الأخرى التي قد تصل إلى هناك خارج prompts».¹

الفرق العملي هو متى، ومن قِبل من. يُؤلف prompt مرة واحدة، بواسطة شخص، ويُراجع. أما context فيُجمع عند كل استدعاء، بواسطة كود لا ينظر إليه أحد، من مادة لم يكتبها أحد يدويًا: أربعون دورًا من التاريخ، وست نتائج أدوات، وأربع مقاطع مسترجعة، وملف مستخدم، واثنا عشر مخطط JSON. قاس الفصل 15 ما تشتريه التعليمات الأفضل. هذا الفصل عن التسعين في المئة الأخرى من tokens، التي تصل من تلقاء نفسها.

تسمي الوثيقة نفسها المورد الذي تنفقه كلها: النماذج «لديها 'ميزانية attention' تعتمد عليها عند تحليل أحجام كبيرة من context. كل token جديدة تُضاف تستنزف هذه الميزانية بمقدار ما». وتسمي العَرَض: «مع زيادة عدد tokens في context window، تتناقص قدرة النموذج على استدعاء المعلومات من ذلك context بدقة» — تعفن context.¹

الجملة الأخيرة ادعاء عن السلوك، وهذا يعني أنه يمكن اختباره، والجدول في أعلى هذه الصفحة هو الاختبار.

أربعون سطرًا ضد نقطة النهاية المحلية من الفصل 22 — خادم Python صغير يحتفظ بـ Qwen2.5-0.5B-Instruct على CPU ويتحدث بشكل chat-completions، بحيث تبقى الحلقة في TypeScript وتبقى التنسورات في الجهة البعيدة من المنفذ.

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 إجابات خاطئة هي الرقم الداخلي لتذكرة أخرى — رقم حقيقي من أربعة أرقام، منسق بشكل صحيح، مقروء من السطر الخطأ. في الموضع 1 كانت واحدة فقط من الإخفاقات الخمسة كذلك؛ وفي الموضع 7، كانت إحدى وعشرون من ست وعشرين كذلك.

هذا التمييز هو ما يهم في الإنتاج. النموذج الذي يقول لا أستطيع العثور عليه خطأ تلاحظه؛ أما النموذج الذي يعيد رقم صف مجاور فهو خطأ تشحنه، لأن الاثنين يبدوان متطابقين على الشاشة. إنه الفشل الذي بنى الفصل 19 الاستشهادات القابلة للتحقق لمواجهته، لكنه يصل من داخل prompt بدلًا من الفهرس.

الموضع محور واحد. والطول هو المحور الآخر، واختباره أسهل: أبقِ الإجابة في الوسط وكبّر القائمة.

سجل واحد و97 token: 90 %. ثلاثة سجلات و159 token: 55 %. ثمانية سجلات و315 token: 15 %، ومن هناك تبقى منخفضة ومسطحة حتى 140 سجلًا و4,477 token. يحدث الانهيار كله بين السطر الأول والسطر الثامن من قائمة.

العمود الأخير هو كل ما ليس الرقم الداخلي الصحيح ولا رقم سجل آخر، ومع وجود سجل واحد فقط على الصفحة فهذا هو المكان الوحيد الذي يمكن أن تقع فيه الإجابة الخاطئة. الإخفاقان عند سجل واحد يستحقان التقرير لا التقريب والإخفاء، لأن أيًا منهما لم يكن رفضًا: أحدهما أجاب 5806 على سجل لا يحتوي إلا على سطر يقول 5805. عند 97 token ومع مرشح واحد فقط، لا يزال هذا النموذج ينسخ رقمًا خطأ مرتين من عشرين، وهذا هو الحد الأدنى الذي يُقاس عليه كل شيء آخر.

ينتج عن ذلك أمران. context أكبر يشتري حق إرسال المزيد، لا يقين أن يُقرأ: لدى هذا النموذج context window من 32,768 token ونطاق عمل، في هذه المهمة، لا يتجاوز بضع مئات من tokens. ولا توجد عتبة، ولا جرف، ولا حالة «context ممتلئ» — التدهور جارٍ عند السجل الثالث ومكتمل بحلول الثامن، عند واحد في المئة من النافذة. أيًا كان حد context، فليس هو ما يحكم هذا.

تُطرح عادة آليتان. الأولى هي الحساب من الفصل 9، الذي تصوغه Anthropic بالمصطلحات نفسها التي يستخدمها هذا المساق: النماذج «مبنية على معمارية transformer، التي تمكّن كل token من attention إلى كل token أخرى عبر context كله. ينتج عن ذلك علاقات زوجية n² لعدد n من tokens».¹ attention على تسلسل أطول ليست العملية نفسها مطبقة على مادة أكثر؛ إنها ميزانية ثابتة واحدة من كتلة الاحتمال موزعة على منافسين أكثر. الثانية هي التدريب: ترى النماذج تسلسلات قصيرة أكثر بكثير من الطويلة، لذا تكون الأنماط الموضعية بعيدة المدى هي الجزء الأقل تدريبًا في الشبكة. هذه حجة، لا قياس، وهذا الفصل لا يستطيع حسمها.

ما حُسم هو الشكل، وقد حُسم منذ 2023. اختبر Liu وآخرون الإجابة عن أسئلة متعددة الوثائق وretrieval المفتاح-القيمة عبر عائلات النماذج وأحجامها، ووجدوا أن «الأداء يكون غالبًا أعلى عندما تقع المعلومات ذات الصلة في بداية context المُدخل أو نهايته، ويتدهور كثيرًا عندما تضطر النماذج إلى الوصول إلى المعلومات ذات الصلة في وسط contexts طويلة، حتى في النماذج المصممة صراحةً لـ context طويل».² أخذ الفصل 15 قاعدة الموضع من تلك الورقة؛ وأخذ الفصل 19 منها سبب أن عشرين chunk مسترجعة قد تسجل أسوأ من أربع. الصيغة العملية للحقيقة هي الجملة الوحيدة هنا التي ينبغي أن تعمل بها: يستغرق قياس هذا على نموذجك وبياناتك خمس دقائق، ولا يعوض أي منحنى منشور منحناك.

اسأل فريقًا ما الذي يملأ context الخاص بـ agent لديهم، وستحصل على تقدير، لأن أي API لا يعيد الإجابة: الاستجابة تمنحك prompt_tokens، رقمًا واحدًا لكل ذلك.

يمكنك استعادة التفصيل بأربع عمليات عد وثلاث عمليات طرح — prompt المعروض كاملًا، والشيء نفسه بلا تعريفات أدوات، ورسالة النظام وحدها معها وبدونها، وكل شيء بعد إزالة نتائج الأدوات:

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، وهذا أهم مما يبدو: نصك ليس ما يُحسب. علامات الأدوار، ومقدمة tool-calling، وعرض المخطط كلها tokens تدفع ثمنها ولم تكتبها قط. بنى الفصل 7 tokenizer وعدّ الفصل 16 باستخدام js-tiktoken؛ هنا يأتي العد من النموذج نفسه الذي سيقرأ prompt، وهذا هو العد الوحيد الصحيح تمامًا.

الآن شغّل agent حقيقيًا عبره: أربعون دورًا من تحقيق حادث، واثنتا عشرة أداة، وبيئة عمليات مزيفة تعيد تفريغات سجلات وسلاسل مقاييس واقعية.

اقرأ الصف الأول مقابل الأخير.

عند الدور 1 يكون prompt بطول 2,547 token و71 % منه تعريفات أدوات. system prompt هو 3 %. ما كتبه المستخدم هو 6 %. لم يفعل agent شيئًا بعد، ومع ذلك يحمل بالفعل 1,817 token من مخطط JSON.

بحلول الدور 40 يكون prompt بطول 10,632 token وقد انعكست الحصص: التعريفات 17 %، والمحادثة 29 %، ونتائج الأدوات 53 %. تجاوزت مخرجات الأدوات التعريفات عند الدور 5؛ ولم تتجاوزها المحادثة حتى الدور 25، لذا خلال أول ستين في المئة من الجلسة كان كتالوج الأدوات أكبر من كل ما قيل.

ثم الإجمالي. عبر 57 استدعاء نموذج، فوّتر التشغيل 370,291 input tokens لأجل context نهائي من 10,632 — أي دُفع ثمن prompt الأخير نحو خمس وثلاثين مرة، وهذا هو التربيع في الفصل 16 مع مُضاعِف agent فوقه. من تلك الـ 370,291، كانت 103,569، أو 28 % من كل ما فُوتر، هي تعريفات الأدوات الاثنتا عشرة، أُعيد إرسالها مطابقة على مستوى البايت في كل استدعاء.

كتالوج الأدوات هو أكبر كلفة ثابتة في agent، وهو غير مرئي، لأنك لا تراه: تمرر مصفوفة من الكائنات ويعرضها المزود داخل 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 %)

لكل أداة تتراوح الكلفة الهامشية من 80 token لـ get_current_time، التي تأخذ string واحدًا، إلى 263 لـ search_tickets، التي تأخذ أربعة معاملات مع enum وجملة إرشاد لكل منها. هذا هو سعر الصرف وراء نصيحة الفصل 18 المركزية بأن الوصف هو API: الوصف الجيد يكلف نحو مئة token في كل طلب لبقية عمر agent. ثلاث نتائج.

الأداة التي لا تستخدمها لا تزال تُفوتر. استدعى agent سبعًا من الاثنتي عشرة. الخمس الأخرى كلفت 697 token في كل طلب من الطلبات الـ 57 — 39,729 إجمالًا، أكثر من عُشر كل ما فُوتر للتشغيل، من أجل قدرات لم يلمسها أبدًا. تحمل واحدة من الخمس أكثر التفاصيل حدة في الأثر: حاول النموذج ثلاث مرات استدعاء read_log، وهي غير موجودة. الأداة التي أرادها كانت search_logs، ثاني أغلى تعريف في الكتالوج عند 237 token. دفع ثمن ذلك التعريف 57 مرة، ولم يستخدمه قط، ولم يجد اسمه قط.

تشذيب النثر هو أرخص تحسين متاح، وهو مقايضة. اختصار الأوصاف إلى جملة واحدة وإسقاط توثيق المعاملات وفّر 526 token لكل استدعاء، 29 في المئة، من دون لمس سطر من المنطق — وجعل النموذج يستدعي الأدوات بشكل أسوأ، وهو ما قاسه الفصل 18. الفكرة أن طرفي تلك المقايضة أصبحا الآن في الوحدة نفسها.

عند مستوى معين، يتوقف إرسال التعريفات أصلًا عن كونه منطقيًا. وضعت Anthropic رقمًا لهذا في نوفمبر 2025: مجموعة كبيرة من الخوادم المتصلة تعني معالجة «مئات الآلاف من tokens» من التعريفات قبل قراءة الطلب، واستبدال ذلك بتنفيذ الكود — أي أن agent يكتشف ويحمل التعريفات التي يحتاجها فقط — «يخفض استخدام token من 150,000 token إلى 2,000 token، موفرًا 98.7% من الوقت والكلفة».³ الفكرة نفسها في بقية هذا الفصل، مطبقة على المخططات بدلًا من التاريخ: احتفظ بالفهرس، وحلّ المدخل عند الطلب.

زُرع أمران في ذلك النص المؤلف من أربعين دورًا. عند الدور 2، قبل أي عمل حقيقي، يذكر المستخدم قاعدة دائمة: أي تذكرة تفتحها يجب أن تُسجل تحت رقم الموظف الخاص بي، 4417. عند الدور 19، في وسط الحادث، حقيقة: الشاردة المتأثرة هي pay-shard-7، أكدها فريق المدفوعات. عند الدور 40 يطلب المستخدم من agent فتح تذكرة الحادث، وهذا يحتاج إلى الاثنين. يُسأل كل مسبار بست صياغات مختلفة ويُسجل من أصل ست — greedy decoding حتمي، لذا يعطي استدعاء واحد نعمًا أو لا غير قابل للتكرار، وستة تعطي معدلًا.

ثم يُعاد تشغيل النص وفق سبع سياسات context. يُعاد تشغيله بدلًا من إعادة تنفيذه، عمدًا: الرسائل، واستدعاءات الأدوات، ونتائج الأدوات مطابقة على مستوى البايت في السبع كلها، لذا فالمتغير الوحيد هو ما اختارت كل سياسة الاحتفاظ به. أظهر الفصل 16 لماذا تكون النافذة المنزلقة حركة اقتصادية سيئة، لأنها تدمر البادئة القابلة لـ prompt caching. إليك ما تفعله بالسلوك:

تشمل صفوف الضغط تكلفة الضغط: 18,581 input tokens لسبع ملخصات و3,392 أخرى لمدون الملاحظات. صف الضابط موجود كي يُقرأ الصفر كصفر — مع الرسالتين وحدهما في prompt من 1,981 token يجيب هذا النموذج عن المسبارين بشكل كامل، لذا لا يوجد صف يعني أن المهمة أصعب مما ينبغي.

التاريخ الكامل يتذكر، وهو أغلى شيء على الطاولة: 370,291 input tokens لجلسة محتواها الدائم جملتان.

هذا يجيب عن سؤال تركته البداية مفتوحًا. لماذا يحتفظ نص من 10,632 token بحقيقة يخسرها سجل من 853 token؟ لأن الطول هو المتغير الخطأ. السجل يحتوي على خمسة وعشرين رقمًا داخليًا من أربعة أرقام في خمس وعشرين جملة متطابقة — أربع وعشرون خدّاعة شبه مثالية لما تريده. النص يحتوي على رقم موظف واحد واسم شاردة واحد بالضبط. تعفن context هو تداخل قبل أن يكون حجمًا، ولهذا كانت 136 من أصل 205 إجابات خاطئة أعلاه قيمة جار. السؤال المفيد عن نافذة ليس كم طولها؛ بل كم شيئًا فيها يشبه الإجابة.

النافذة المنزلقة أرخص بـ 57 % وقد فقدت الحادث. ينجو رقم الموظف فقط لأن agent كان قد كرره في الأدوار الحديثة. الشاردة، التي ذُكرت مرة عند الدور 19، ليست في آخر اثنتي عشرة رسالة — والنموذج لا يقول ذلك. عند سؤاله ست مرات أجاب «الشاردة المتأثرة للمدفوعات هي shard 4417»، متشبثًا برقم الموظف، وهو المعرف الآخر الوحيد المتبقي في نافذته، وأجاب مرتين «pool»، مرفوعة من السلسلة pool_exhausted في سطر سجل.

الضغط رخيص وفقد الحقيقة نفسها. سبعة ملخصات، كتبها النموذج تحت تعليمات صريحة بأن يحتفظ بالمعرفات، والأرقام، والتعليمات الدائمة، والأسئلة المفتوحة، ولا تظهر pay-shard-7 في أي من الملخصات المهمة؛ وكانت التخمينات الستة shard 1 وpay_shard_1 وpool. لا يفشل الضغط بصوت عالٍ. إنه ينتج جلسة سلسة ومعقولة وأقصر بكثير، لكنها أسقطت سطرًا بصمت.

سجلت ثلاثة صفوف 0/6 في حقيقة الدور 19 — النافذة المنزلقة، والضغط، والضغط مع الملاحظات. ثماني عشرة إجابة خاطئة بينها، ولم تكن واحدة منها «لا أعرف».

ثم الصف الذي ينبغي أن يكون محرجًا. الاحتفاظ برسائل المستخدم الأربعين حرفيًا، إضافة إلى آخر أربعة أدوار كاملة ولا شيء غير ذلك، يكلف 168,550 token — أقل بـ 54 % من التاريخ الكامل — ويجيب عن المسبارين بجودة التاريخ الكامل أو أفضل. لا ملخّص، ولا مدون ملاحظات، ولا نموذج ثانٍ: مجرد مرشح على role === "user". كلمات المستخدم هي أرخص tokens عالية القيمة في نافذة agent، ومعظم التصاميم تلقيها مع كل شيء آخر.

الصفان الأخيران هما جدول البداية مرة أخرى، داخل agent. الكتلة المثبتة نفسها، نُقلت من رسالة النظام إلى نهاية prompt: تتحول 5/6 إلى 6/6. في ست تجارب ليس هذا فرقًا ذا دلالة، ولا يُعرض كذلك — بل يُعرض تذكيرًا بأن المكان معامل تضبطه سواء عرفت أم لم تعرف.

الاستراتيجيات الأربع أدناه هي استراتيجيات Anthropic، وبترتيبها، رغم أن الثلاث الأخيرة فقط هي قائمتها للأفق الطويل.¹ الأربع كلها تنويعات على تعليمة واحدة: لا تحمل ما يمكنك جلبه، ولا تحمل خامًا ما يمكنك حمله مضغوطًا.

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 في الجدول أعلاه لأنه لا يعمل أربعين دورًا: يعمل مرة واحدة، في نافذة حددها شخص ما له. مع system prompt، والأدوار 17 إلى 19 ولا شيء آخر — 2,737 token — أجاب عن مسبار الشاردة 6/6، أفضل من كل سياسة في الجدول، وعن مسبار الموظف 0/6، لأن ذلك الرقم ليس في الأدوار الثلاثة التي مُنحت له.

هذا هو sub-agents في رقمين: النافذة النظيفة ليست ذكاءً، إنها نطاق، وتحديد النطاق يُنجز مسبقًا بواسطة كود يجب أصلًا أن يعرف أي الأدوار مهمة. هناك أمر آخر في تلك الإجابات يستحق الاحتفاظ به. كانت هذه السياسة الوحيدة التي ردت «None available» بدلًا من اختراع شيء. النموذج ذو context صغير ومتماسك يعرف ما ينقصه؛ أما النموذج ذو context كبير وصاخب فلا يعرف.

كل محادثة مرتبكة تقريبًا عن ذاكرة agent هي ثلاث آليات ترتدي كلمة واحدة. لها أعمار وملاك وأنماط فشل مختلفة، والنظام الذي يحتفظ بها في المكان نفسه لديه مشكلة لم يلاحظها بعد.

الإطار الأكاديمي هو CoALA، الذي ينظم language agents حول «مكونات ذاكرة معيارية» ويفصل ذاكرة العمل عن المخازن العرضية والدلالية والإجرائية.⁴ يأخذ MemGPT الفكرة نفسها حرفيًا، مستعيرًا الذاكرة الافتراضية من أنظمة التشغيل: طبقة سريعة داخل النافذة، وطبقة بطيئة خارجها، والنموذج نفسه ينقل البيانات بينهما عبر function calls.⁵ كلاهما يفرض السؤال الذي يجب على المنتج أن يجيب عنه على أي حال — ليس كم يمكنني الاحتفاظ به، بل إلى أي مخزن ينتمي هذا، ومتى ينتهي.

الاختبار العملي سؤال واحد لكل حقيقة: ما الذي يجب أن يبقى صحيحًا غدًا؟ نتيجة أداة من الدور 12، لا شيء. ملخص الجلسة، حتى تنتهي الجلسة. أن رقم موظف المستخدم هو 4417، حتى يغيّر وظيفته. ثلاث إجابات، ثلاثة مخازن.

يمكنك الآن قياس ما في نافذة، وتقرير ما يبقى فيها، والتمييز بين agent نسي شيئًا وآخر كان يحمله ولم ينظر.

آخر الاستراتيجيات الأربع هي التي لا تناسب هنا. sub-agent ليس سياسة context، بل agent ثانٍ، وفي اللحظة التي يصبح فيها لديك اثنان يجب أن تقرر ما الذي يمر بينهما ومن المسؤول. الفصل 25 هو ذلك: أنماط التنسيق الخمسة ومن أين تأتي أسماء كل منها فعلًا، والطوبولوجيتان اللتان تختلطان — سؤال sub-agent والحصول على إجابة، مقابل تسليمه المحادثة وعدم استعادتها — والنتيجة المقاسة أنه في المهمة التي يسعرها، ينتصر الترتيب الأبسط — ثم الاختبار لمعرفة متى يتوقف عن الانتصار.

كما يرث بالضبط ما قاسه هذا الفصل للتو. يعيد sub-agent ملخصًا. الملخص ضغط لم تكتبه، ينتجه نموذج لا تستطيع رؤية نافذته، ولا يملك الأب طريقة لتمييز الجيد من الخاطئ الواثق — التمييز نفسه الذي فصل 84 % عن 19 % في أعلى هذه الصفحة، وحوّل ثماني عشرة حقيقة مفقودة إلى ثماني عشرة حقيقة مخترعة. إذن: عندما يخطئ sub-agent، ما الذي يستطيع الأب النظر إليه بالضبط؟

أُنتج كل رقم هنا على هذه الآلة، ولم يُقدّر أي منها. النموذج هو Qwen2.5-0.5B-Instruct في float32 على CPU مع greedy decoding، ويُخدّم عبر loopback بواسطة نقطة نهاية Python صغيرة تتحدث بشكل chat-completions وتكشف مسار عد token — الحد نفسه في الفصل 14 مرة أخرى، التنسورات على جانب Python والحلقة على جانب TypeScript — لذا فكل عد هو tokenizer الخاص بذلك النموذج مطبقًا على قالب الدردشة الخاص به. جدول الموضع 288 استدعاء، تسعة مواضع في اثنتين وثلاثين تجربة مع تذكرة مختلفة في كل تجربة؛ وجدول الطول 140 استدعاء؛ وتشغيل agent هو 57 استدعاء نموذج عبر 43 دقيقة من وقت الجدار؛ وجدول السياسات هو ذلك النص الواحد مُعاد تشغيله تحت سبع سياسات. الفواصل هي Wilson، من الفصل 4. لم يُستدع أي API مدفوع، ولهذا أيضًا لا يوجد سعر واحد في الفصل: أعداد token دقيقة، والأسعار التي ستضربها بها هي أسعار الفصل 16.