وقتی قرار است یک LLM از میان محصول‌های database چند مورد متناسب با درخواست کاربر انتخاب کند، فرستادن شناسهٔ واقعی هر محصول راهی مستقیم به نظر می‌رسد. اما آزمایش نویسنده نشان می‌دهد در چنین promptای، خود شناسه‌ها می‌توانند بخش عمدهٔ هزینه را تشکیل دهند؛ حتی وقتی اطلاعات محصول تغییری نمی‌کند.
نویسنده یک prompt با ۴۶ token دستور، فهرست ۵۰ محصول به‌شکل شناسه و نام، یک درخواست کوتاه و خروجی مورد انتظار شامل JSON array سه شناسه ساخت. سپس قالب شناسه‌ها را عوض کرد و تعداد token را با tiktoken، ابزار open-source متعلق به OpenAI، شمرد. هر UUID به‌طور میانگین حدود ۲۳ token مصرف کرد، درحالی‌که نام محصول کنار آن حدود ۴ token بود. در این نمونه، شناسه‌ها حدود ۸۰ درصد ورودی را تشکیل می‌دادند.
با UUID، ورودی ۱۴۳۹ و خروجی ۷۲ token داشت؛ با index از ۱ تا ۵۰، این اعداد به ۳۳۶ و ۹ رسیدند. محاسبه با قیمت‌های اعلام‌شدهٔ GPT-5.6 و فرض ۳۰۰ هزار درخواست در ماه، هزینهٔ ماهانه را حدود ۱۱۲۳ دلار در برابر ۲۳۴ دلار نشان داد: نسبت ۴٫۸ برابر و اختلاف ۸۸۹ دلار. این ارقام به حجم درخواست و قیمت‌های استفاده‌شده در همان آزمایش وابسته‌اند.
دلیل این تفاوت به tokenizer برمی‌گردد: رشته‌های تصادفی UUID به قطعه‌های کوتاه تقسیم می‌شوند. خروجی هم اهمیت دارد، چون token خروجی گران‌تر است؛ در نمونهٔ UUID، پاسخ فقط سه شناسه داشت، اما ۲۳ درصد هزینهٔ فراخوانی را تشکیل می‌داد.
راهکار پیشنهادی، شماره‌گذاری موردها در prompt و نگه‌داشتن ارتباط هر شماره با شناسهٔ واقعی در برنامه است. پس از دریافت پاسخ، برنامه شماره‌ها را به شناسه‌های اصلی تبدیل و شماره‌های خارج از فهرست را رد می‌کند. این ارتباط فقط برای همان درخواست نگه داشته می‌شود.
این روش محدودیت دارد: index محلی برای ارجاع میان پیام‌های گفتگو، فراخوانی‌های tool در یک agent یا خروجی ذخیره‌شده کافی نیست؛ آنجا شناسهٔ ثابت لازم است. نویسنده همچنین دقت را اندازه نگرفته است: بررسی شماره‌ها فقط موردهای خارج از فهرست را تشخیص می‌دهد، نه انتخاب اشتباه را. اگر هر محصول توضیحی طولانی داشته باشد، سهم شناسه‌ها و میزان صرفه‌جویی کمتر می‌شود؛ بنابراین پیش از تغییر، باید tokenهای prompt واقعی شمرده شوند.
