تفاوت قیمت توکن ورودی و خروجی در مدل‌های Claude

چرا هزینه توکن‌های خروجی از توکن‌های ورودی بیشتر است

هزینه توکن‌های خروجی در تمامی مدل‌های Claude موجود در کاتالوگ فعلی، پنج برابر هزینه توکن‌های ورودی است. دلیل این موضوع به ساختار محاسباتی بازمی‌گردد. خواندن یک پرامپت، یک مرحله پردازش روی مدل است. اما نوشتن پاسخ، به ازای هر توکن یک مرحله پردازش جداگانه است و هر مرحله باید منتظر پایان مرحله پیش از خود بماند.

این نسبت در تمامی ردیف‌های لیست قیمت یکسان است، بنابراین مدل انتخابی شما تغییری در سهم توکن‌های خروجی از صورت‌حساب نهایی ایجاد نمی‌کند. این سهم توسط ماهیت کاری که انجام می‌دهید تعیین می‌شود. یک مرحله از کار یک عامل (agent) که 60,000 توکن را می‌خواند و با 800 توکن پاسخ می‌دهد، تقریباً هیچ هزینه‌ای بابت خروجی ندارد. در مقابل، یک کارِ پیش‌نویس که 2,000 توکن را می‌خواند و 12,000 توکن می‌نویسد، تقریباً هیچ هزینه‌ای بابت ورودی ندارد. هر دو مورد در ادامه بر اساس نرخ‌های منتشرشده Anthropic در اوت 2026 محاسبه شده‌اند.

مرحله Prefill یک‌بار اجرا می‌شود، رمزگشایی (Decoding) برای هر توکن یک‌بار

یک سرور استنتاج (inference server)، درخواست را در دو مرحله با هزینه‌های بسیار متفاوت پردازش می‌کند. مرحله Prefill پرامپت را می‌خواند. مرحله Decoding پاسخ را می‌نویسد.

مرحله Prefill کل پرامپت را یک‌جا دریافت می‌کند. هر توکن پرامپت در یک forward pass وارد شبکه می‌شود، بنابراین عملیات attention و feed-forward به تعداد کمی ضرب ماتریسی بزرگ تبدیل می‌شود که هزاران توکن را در هر لحظه پوشش می‌دهد. یک‌بار خواندن وزن‌های مدل از حافظه، کل پرامپت را پردازش می‌کند. واحدهای ماتریسی شتاب‌دهنده (accelerator) مشغول می‌مانند، به این معنی که Prefill محدود به توان محاسباتی (compute-bound) است: محدودیت اصلی، سرعت ضرب ماتریس‌ها توسط تراشه است.

مرحله Decoding نمی‌تواند به این شکل عمل کند، زیرا توکن 2 به توکن 1 وابسته است. توکنی که مدل به‌تازگی تولید کرده، بخشی از ورودی مرحله بعد می‌شود، بنابراین مراحل نمی‌توانند هم‌زمان اجرا شوند. هر توکن خروجی، forward pass مخصوص خود را دارد و هر یک از این پاس‌ها، کل مجموعه وزن‌های مدل را از حافظه با پهنای باند بالا (high-bandwidth memory) می‌خواند تا تنها یک توکن تولید کند. این موضوع باعث می‌شود Decoding محدود به حافظه (memory-bound) باشد: محدودیت اصلی، سرعت انتقال وزن‌هاست، نه سرعت ضرب آن‌ها. همان ترافیک وزنی که در مرحله Prefill کل یک پرامپت را پردازش می‌کرد، در مرحله Decoding تنها یک توکن به شما می‌دهد.

سیستم‌های سرویس‌دهی با استفاده از batching با این مشکل مقابله می‌کنند. بسیاری از درخواست‌ها به‌صورت دسته‌ای (batch) رمزگشایی می‌شوند، بنابراین یک‌بار خواندن وزن‌ها، برای هر درخواست در آن دسته، یک توکن تولید می‌کند. به همین دلیل است که Decoding اصلاً مقرون‌به‌صرفه است. سقف این کار دوباره حافظه است. هر درخواست در حال اجرا، یک KV cache (حافظه پنهان کلید/مقدار، یعنی وضعیت attention ذخیره‌شده برای هر توکن تا آن لحظه) را نگه می‌دارد؛ این حافظه با تولید هر توکن رشد می‌کند و وقتی حافظه شتاب‌دهنده پر شود، اندازه دسته (batch) دیگر نمی‌تواند افزایش یابد.

هیچ‌کدام از این موارد عدد دقیقی به شما نمی‌دهد و نباید نسبت 5x را به‌عنوان یک نسبت سخت‌افزاری اندازه‌گیری‌شده در نظر بگیرید. این یک قیمت‌گذاری است که توسط Anthropic و با توجه به این عدم تقارن تعیین شده است. آنچه می‌توانید خودتان بررسی کنید، جهت این تغییرات است که حدود یک دقیقه زمان می‌برد.

شکاف ورودی و خروجی را شخصاً اندازه‌گیری کنید

ابزارها را روی هر سیستم Ubuntu نصب کنید:

sudo apt update && sudo apt install -y curl jq moreutils

اکنون یک prompt کوتاه که درخواست پاسخی طولانی دارد را استریم کنید و زمان رسیدن هر خط را ثبت نمایید.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s ابتدای هر خط، ثانیه‌های سپری‌شده از زمان شروع دستور را درج می‌کند. دو مورد در این خروجی قابل بررسی است. اولین خط content_block_delta نشان‌دهنده زمان رسیدن به اولین توکن (Time to First Token) است و تمام عملیات prefill در آن بازه انجام شده است. هر خط پس از آن، یک گام کوچک از عملیات decoding است و زمان‌سنج تا رسیدن message_stop به افزایش خود ادامه می‌دهد.

اکنون این الگو را معکوس کنید. یک سند طولانی در prompt قرار دهید و پاسخ را به تعداد کمی توکن محدود کنید.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

اولین دلتا نسبت به حالت prompt کوتاه زمان بیشتری می‌برد، زیرا prefill باید متن بسیار بیشتری را پردازش کند. پس از رسیدن آن، پاسخ تقریباً بلافاصله تمام می‌شود، چرا که تنها چند توکن برای decoding باقی مانده است. ده‌ها هزار توکن وارد شد و زمان‌سنج تغییر چندانی نکرد. چند صد توکن خارج شد و زمان‌سنج در تمام مدت در حال کار بود.

هر پاسخ غیر استریم (non-streaming) با اعدادی که بر اساس آن‌ها صورت‌حساب برای شما صادر می‌شود، پایان می‌یابد.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

هر چهار فیلد را برای هر درخواست لاگ کنید. output_tokens شامل تفکر گسترده (extended thinking) است، بنابراین مدلی که پیش از پاسخ‌دهی فکر می‌کند، هزینه آن تفکر را با نرخ خروجی محاسبه می‌کند. برای قیمت‌گذاری یک prompt پیش از ارسال، POST /v1/messages/count_tokens همان بدنه درخواست را می‌پذیرد، {"input_tokens": N} را بدون اجرای مدل برمی‌گرداند و رایگان است. این تنها بخشی از API نیست که هزینه‌ای ندارد و بررسی بخش‌هایی از Claude API که هرگز برای آن‌ها صورت‌حساب دریافت نمی‌کنید پیش از بودجه‌بندی اولین پروژه، ارزشمند است.

هزینه‌های Claude به ازای هر میلیون توکن تا اوت 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

ستون آخر، خروجی تقسیم بر ورودی است و در هر ردیف مقدار 5 را نشان می‌دهد. مدل Haiku 4.5 برای ورودی $1 و برای خروجی $5 محاسبه هزینه می‌کند. مدل Opus 5 به ازای ورودی $5 و خروجی $25 هزینه دریافت می‌کند. مدل Fable 5 که گران‌ترین است، $10 برای ورودی و $50 برای خروجی دریافت می‌کند، و مطالعه آنچه با نرخ‌های Fable 5 به دست می‌آورید پیش از نادیده گرفتن ردیف اول، ارزشمند است. حرکت در این بازه، هر دو طرف را در یک ضریب یکسان ضرب می‌کند؛ بنابراین مجموع هزینه تغییر می‌کند اما نسبت ورودی به خروجی ثابت می‌ماند.

مدل Sonnet 5 دو بار ذکر شده است زیرا نرخ مقدماتی آن منقضی می‌شود. تا 31 اوت 2026، هزینه آن $2 برای ورودی و $10 برای خروجی است. از 1 سپتامبر 2026، نرخ استاندارد $3 برای ورودی و $15 برای خروجی اعمال می‌شود که 50 درصد در هر دو طرف افزایش یافته است. تمام مثال‌های محاسباتی زیر از نرخ ماه اوت استفاده می‌کنند.

نرخ‌ها تغییر می‌کنند و این صفحه مرجع بررسی آن‌ها نیست. claude.com/pricing منبع اصلی و معتبر است. آنچه پس از تغییر قیمت‌ها همچنان معتبر باقی می‌ماند، روش محاسبه است.

یک نکته مهم که در لیست قیمت‌ها نمایش داده نمی‌شود: مستندات Anthropic بیان می‌کند که Claude 4.7 و مدل‌های بعدی از توکنایزر جدیدتری استفاده می‌کنند که برای متن یکسان، تقریباً 30 درصد توکن بیشتری نسبت به توکنایزر Sonnet 4.6 و مدل‌های قدیمی‌تر تولید می‌کند. مقایسه دو مدل صرفاً بر اساس قیمت هر میلیون توکن، مدل جدیدتر را ارزان‌تر جلوه می‌دهد، زیرا یک سند واحد در آن مدل توکن‌های بیشتری دارد. مقایسه را بر اساس هزینه هر وظیفه نهایی انجام دهید و پرامپت‌های واقعی خود را با مدلی که قصد استفاده از آن را دارید، بسنجید. ارزش یک میلیون توکن Claude در متن واقعی توضیح می‌دهد که این حجم در عمل چه مقدار متن است.

چه زمانی هزینه خروجی بر صورت‌حساب شما غالب می‌شود؟

با توجه به اینکه قیمت خروجی 5 برابر ورودی است، محاسبه نقطه سربه‌سر به‌سادگی در ذهن انجام می‌شود. توکن‌های ورودی را I و توکن‌های خروجی را O در نظر بگیرید. هزینه ورودی برابر با I است. هزینه خروجی برابر با 5 ضرب‌در O است. زمانی که 5 ضرب‌در O بزرگ‌تر از I باشد، خروجی بیش از نیمی از هزینه‌های شما را تشکیل می‌دهد؛ این یعنی نسبت توکن 5 ورودی به 1 خروجی.

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

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

در نسبت 100 به 1، خروجی 4.8% از هزینه‌ها را تشکیل می‌دهد و در این حالت، تنها بهینه‌سازی پرامپت ارزش وقت گذاشتن دارد. در نسبت 5 به 1، هزینه‌های هر دو طرف برابر است. در نسبت 1 به 6، خروجی 96.8% از هزینه‌هاست و پرامپت عملاً یک خطای گرد کردن محسوب می‌شود. اکثر افراد نسبت مصرف خود را اشتباه حدس می‌زنند، بنابراین پیش از هرگونه بهینه‌سازی، آمار دقیق را از لاگ‌های خود استخراج کنید.

یک بار کاری عامل: ورودی با متن طولانی، خروجی کوتاه

یک گام از عامل بازیابی را در نظر بگیرید: 60,000 توکن ورودی شامل اسناد بازیابی‌شده و تاریخچه گفتگو، و یک پاسخ 800 توکنی. این نسبت 75 به 1 است که برای هر فرآیندی که پیش از نوشتن، مطالعه می‌کند، طبیعی است.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

خروجی 6.25% از آن فراخوانی در هر مدل است، زیرا این نسبت در کل لیست قیمت ثابت است. هزینه این فراخوانی روی Opus 5 برابر با $0.32، روی Sonnet 5 با نرخ ماه اوت برابر با $0.128 و روی Haiku 4.5 برابر با $0.064 است. دویست مورد از این گام‌ها در روز روی Opus 5، هزینه‌ای معادل 64 دلار در روز دارد.

وقتی این تفکیک را مشاهده کنید، اهرم فشار مشخص می‌شود. کاهش پاسخ از 800 توکن به 400 توکن، حدود 3% از هزینه فراخوانی را صرفه‌جویی می‌کند. حذف 20,000 توکن از متن‌های قدیمی (stale context) از پرامپت، حدود یک‌سوم هزینه را کاهش می‌دهد. محدود کردن طول خروجی در یک عاملِ متکی بر خواندن (read-heavy)، تقریباً تلاشی بیهوده است. محل قرارگیری واقعی توکن‌های یک عامل کدنویسی تحلیل می‌کند که چه چیزی در وهله اول آن پرامپت را پر می‌کند.

تولید بار کاری: دستورالعمل کوتاه، پیش‌نویس طولانی

حالا ساختار را تغییر می‌دهیم. یک دستورالعمل 2000 توکنی و یک پیش‌نویس 12000 توکنی، با نسبت 1 به 6.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

خروجی 96.8% از این صورت‌حساب است. هزینه Opus 5 برای هر پیش‌نویس $0.31 در مقابل $0.062 برای Haiku 4.5 است. این اختلاف پنج‌برابری تقریباً به‌طور کامل از سمت خروجی ناشی می‌شود، که دقیقاً همان بخشی است که مدل ارزان‌تر بیشترین صرفه‌جویی را برای شما به همراه دارد.

ستون آخر، همان کار را از طریق Batch API نشان می‌دهد که 50% از هزینه‌های ورودی و خروجی می‌کاهد. هزینه Opus 5 به $0.155 برای هر پیش‌نویس کاهش می‌یابد. Batch نتایج را به‌جای پاسخ آنی، ظرف 24 ساعت بازمی‌گرداند؛ بنابراین برای تولید گزارش‌های شبانه و دسته‌بندی انبوه مناسب است. این روش برای کارهایی که کاربر منتظر پاسخ آن است، مناسب نیست.

مسیریابی مدل (Model routing) در اینجا به شکلی بازدهی دارد که در مرحله agent هرگز دیده نمی‌شود. اگر بخش طولانی کار ماهیت مکانیکی داشته باشد، مانند تغییر فرمت متن یا بسط دادن طرحی که قبلاً تأیید کرده‌اید، مدل ارزان‌قیمت آن توکن‌ها را با یک‌پنجم قیمت تولید می‌کند. انتخاب بین Opus، Sonnet و Haiku مشخص می‌کند که مرز کیفیت واقعاً کجا قرار دارد.

تخفیف‌های کشینگ برای ورودی، و فقط ورودی

قابلیت Prompt caching بخشی از ابتدای پرامپت شما را روی سرور ذخیره می‌کند و برای خواندن مجدد آن، کسری از نرخ ورودی عادی را دریافت می‌کند. از اوت 2026، ضرایب به این صورت است: 1.25 برابر نرخ پایه ورودی برای نوشتن یک کش 5 دقیقه‌ای، 2 برابر برای نوشتن یک کش 1 ساعته، و 0.1 برابر برای خواندن یک hit.

خروجی شامل این تخفیف نمی‌شود. هیچ خروجی کش‌شده‌ای وجود ندارد. هر توکنی که مدل تولید می‌کند، فارغ از اینکه چه مقدار از پرامپت به عنوان cache hit بازگشته باشد، هر بار با نرخ کامل خروجی محاسبه می‌شود.

همان مرحله از عامل (agent) را روی Opus 5 در نظر بگیرید، که در آن 55,000 توکن از مجموع 60,000 توکن ورودی از یک کش فعال (warm cache) تأمین شده است.

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

هزینه فراخوانی از $0.32 به $0.0725 کاهش می‌یابد. هزینه خروجی تغییر نمی‌کند: قبل از آن $0.02 بوده و بعد از آن نیز $0.02 باقی می‌ماند. کشینگ صورت‌حساب را کاهش داده و ساختار آن را تغییر می‌دهد. سهم خروجی در آن فراخوانی 6.25% بود. اکنون این سهم به بیش از یک‌چهارم رسیده است، که باعث می‌شود اولویت‌های بهینه‌سازی تغییر کند.

فراخوانی اول هزینه نوشتن را پرداخت می‌کند. هزینه نوشتن یک کش 5 دقیقه‌ای 1.25 برابر ورودی پایه است، بنابراین پس از یک بار hit، هزینه خود را جبران می‌کند. هزینه نوشتن 1 ساعته 2 برابر است، بنابراین به دو بار hit نیاز دارد. ضرایب نوشتن و خواندن، و جایی که کشینگ دیگر صرفه اقتصادی ندارد این محاسبات را به تفصیل بررسی می‌کند.

چهار اهرمی که در کنترل شما هستند

1. مقدار max_tokens را روی طول خروجی p95 تنظیم کنید، نه روی حداکثر مقدار مدل.
2. مراحل پرحرف (verbose) را به یک مدل ارزان‌تر هدایت کنید.
3. هر کاری که کسی منتظر نتیجه‌اش نیست را به‌صورت دسته‌ای (batch) انجام دهید.
4. دستورالعمل‌هایی که باعث طولانی شدن پاسخ‌ها می‌شوند را حذف کنید.

max_tokens یک سقف سخت است و تنظیم آن روی مقدار بالا به‌خودی‌خود هزینه‌ای ندارد، زیرا صورت‌حساب شما بر اساس توکن‌های تولیدشده صادر می‌شود و نه سقف تعیین‌شده. مزیت یک سقف سخاوتمندانه این است که محدودیتی برای پاسخ‌هایی که دچار خطا می‌شوند ایجاد نمی‌کند. توزیع output_tokens را از لاگ‌های خود استخراج کنید، سقف را کمی بالاتر از صدک 95 قرار دهید و stop_reason: "max_tokens" را در کد با ادامه دادن پاسخ یا تلاش مجدد مدیریت کنید. یک برش (truncation) که شناسایی می‌کنید، هزینه کمتری نسبت به یک پاسخ 4,000 توکنی دارد که بابت آن پول پرداخت کرده‌اید و در نهایت آن را دور می‌ریزید. تفکر طولانی (Extended thinking) نیز در output_tokens لحاظ می‌شود، بنابراین بودجه آن را بر اساس همان شواهد تنظیم کنید.

هدایت کردن (Routing) زمانی کارآمد است که بخش گران‌قیمت یک مرحله، حجم خروجی باشد نه قدرت قضاوت. مدل قدرتمند را برای تصمیم‌گیری حفظ کنید و تایپ کردن را به مدلی ارزان‌تر بسپارید. نسخه هدایت‌شده را ابتدا روی مجموعه ارزیابی خود بسنجید، زیرا یک مدل ارزان که نیاز به دو بار تلاش دارد، گران‌تر از یک تلاش موفق با مدل گران‌قیمت تمام می‌شود.

پردازش دسته‌ای (Batching) تنها اهرمی است که برای خروجی تخفیف ارائه می‌دهد. 50 درصد تخفیف در هر دو سمت، تحویل نتایج در کمتر از 24 ساعت، و هر کاری که زمان‌بندی مشخصی دارد، واجد شرایط این روش است.

آخرین اهرم، همان چیزی است که افراد از آن غافل می‌شوند. عباراتی مانند "کامل باش" یا "استدلال خود را توضیح بده" طول خروجی شما را در هر فراخوانی که انجام می‌دهید، افزایش می‌دهند. آن‌ها را با ساختار مورد نظر خود جایگزین کنید: "حداکثر در سه جمله پاسخ بده" یا "فقط شیء JSON را بدون هیچ مقدمه‌ای برگردان". یک system prompt که 300 توکن به هر پاسخ اضافه می‌کند، پنج برابر بیشتر از همان 300 توکن در prompt اصلی هزینه دارد. کنترل هزینه‌های یک عامل در حال اجرا بخش نظارت را پوشش می‌دهد و اینکه آیا API یا اشتراک ثابت برای الگوی کاری شما ارزان‌تر است موضوعی است که باید پیش از صرف یک هفته زمان برای بهینه‌سازی هزینه‌های مبتنی بر توکن، مشخص شود؛ هزینه‌هایی که یک اشتراک ثابت می‌توانست آن‌ها را پوشش دهد. برای یک توسعه‌دهنده، این موضوع عمدتاً به این برمی‌گردد که آیا اشتراک 20 دلاری ماهانه Claude Pro و محدودیت‌های استفاده همراه آن کاری را که در غیر این صورت باید برایش هزینه پرداخت می‌کردید، پوشش می‌دهد یا خیر. اگر در میانه جلسه به آن محدودیت‌ها می‌رسید، تشخیص اینکه منتظر کدام پنجره هستید در اولویت است، زیرا راه‌حل آن استفاده از یک مدل کوچک‌تر، کانتکست سبک‌تر، اعتبار استفاده اضافی یا انتقال آن کار به API مبتنی بر مصرف است. اگر مشخص شد که API مبتنی بر مصرف، خانه ارزان‌تری برای آن کار است، کاهش به یک طرح کوچک‌تر یا لغو آن ماه باقی‌مانده‌ای که پرداخت کرده‌اید را دست‌نخورده باقی می‌گذارد، بنابراین تغییر طرح در هنگام خروج هزینه‌ای برای شما ندارد. اگر طرحی که با Pro مقایسه می‌کنید مربوط به ChatGPT است و نه API مبتنی بر مصرف، مقایسه قیمت دو اشتراک در کنار هم نشان می‌دهد که کدام‌یک برای کارهای برنامه‌نویسی ارزان‌تر تمام می‌شود. اگر این سوال برای یک تیم مطرح است و نه یک توسعه‌دهنده، توجه داشته باشید که Claude Enterprise هزینه هر کاربر را با توکن‌های محاسبه‌شده با همان نرخ‌های API ترکیب می‌کند، بنابراین تمام اهرم‌های این صفحه همچنان برای بخش مبتنی بر مصرف آن صورت‌حساب اعمال می‌شوند.

FAQ

چرا هزینه توکن‌های خروجی از توکن‌های ورودی بیشتر است؟

تولید توکن‌های خروجی به زمان بسیار بیشتری از شتاب‌دهنده برای هر توکن نیاز دارد. یک پرامپت در یک مرحله پردازش (forward pass) برای کل متن انجام می‌شود، بنابراین یک بار خواندن وزن‌های مدل، هزاران توکن را پوشش می‌دهد و سخت‌افزار توسط توان عملیاتی ضرب (multiply throughput) محدود می‌شود. اما پاسخ، توکن به توکن تولید می‌شود و هر توکن به یک مرحله پردازش مجزا نیاز دارد که دوباره تمام وزن‌های مدل را می‌خواند؛ در نتیجه، سخت‌افزار در اینجا توسط پهنای باند حافظه محدود می‌شود. Anthropic قیمت خروجی را در کل کاتالوگ فعلی خود، از Haiku 4.5 تا Fable 5، پنج برابر قیمت ورودی تعیین کرده است.

آیا کش کردن پرامپت (Prompt caching) باعث ارزان‌تر شدن توکن‌های خروجی می‌شود؟

خیر. کش کردن پرامپت فقط برای ورودی اعمال می‌شود. تا اوت 2026، هزینه خواندن از کش 0.1 برابر نرخ پایه ورودی است و هزینه نوشتن در کش برای مدت 5 دقیقه 1.25 برابر و برای مدت 1 ساعت 2 برابر است. خروجی در هر فراخوانی با نرخ کامل محاسبه می‌شود، صرف‌نظر از اینکه کش چه کاری انجام داده است. به همین دلیل است که کش کردن علاوه بر اندازه صورت‌حساب، ساختار آن را نیز تغییر می‌دهد: وقتی هزینه بخش ورودی کاهش می‌یابد، خروجی به بخشی تبدیل می‌شود که باید برای بهینه‌سازی آن اقدام کرد.

آیا مقدار بالای max_tokens در صورت کوتاه بودن پاسخ، هزینه بیشتری برای من دارد؟

خیر. هزینه شما بر اساس توکن‌هایی محاسبه می‌شود که مدل واقعاً تولید می‌کند، بنابراین max_tokens یک سقف است و نه یک رزرو. با این حال، این مقدار همچنان اهمیت دارد، زیرا تنها محدودیت سخت برای جلوگیری از تولید پاسخ‌های بی‌انتها است. آن را کمی بالاتر از صدک 95 مقدار output_tokens مشاهده‌شده خود تنظیم کنید و سپس stop_reason: "max_tokens" را در کد مدیریت کنید، به جای اینکه اجازه دهید پاسخ به‌طور خاموش قطع شود.

چگونه نسبت توکن‌های ورودی به خروجی خود را پیدا کنم؟

مقادیر input_tokens، output_tokens، cache_read_input_tokens و cache_creation_input_tokens را از شیء usage در هر پاسخ لاگ کنید و سپس مجموع آن‌ها را در طول یک هفته بر هم تقسیم کنید. اگر نسبت ورودی به خروجی بیش از 5 به 1 است، هزینه اصلی شما در پرامپت است؛ پس بخش‌های ثابت را کش کنید و بقیه را کوتاه کنید. اگر این نسبت کمتر است، هزینه شما در پاسخ است؛ پس طول آن را محدود کنید و مراحلی که بیشترین خروجی را تولید می‌کنند، به یک مدل ارزان‌تر یا به Batch API منتقل کنید.