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

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

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

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

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

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

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

مرحله Decoding نمی‌تواند به این شکل عمل کند، زیرا توکن 2 به توکن 1 وابسته است. توکنی که مدل به‌تازگی تولید کرده، بخشی از ورودی مرحله بعد می‌شود؛ بنابراین این مراحل نمی‌توانند همزمان اجرا شوند. هر توکن خروجی، forward pass مخصوص به خود را دارد و هر یک از این passها برای تولید تنها یک توکن، باید کل وزن‌های مدل را از حافظه با پهنای باند بالا (HBM) بخواند. این موضوع باعث می‌شود 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

sudo apt update && sudo apt install -y curl ts

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

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'

echo '{"model": "claude-3-5-sonnet-20241022", "max_tokens": 1024, "messages": [{"role": "user", "content": "Write a long essay about the history of computing."}], "stream": true}' | \
curl 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 @- | \
ts '%.S'

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

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

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'

echo '{"model": "claude-3-5-sonnet-20241022", "max_tokens": 10, "messages": [{"role": "user", "content": "<long_document_text_here> Summarize this in one sentence."}], "stream": true}' | \
curl 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 @- | \
ts '%.S'

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

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

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

{
"usage": {
"input_tokens": 200,
"output_tokens": 50
}
}

هر چهار فیلد را برای هر درخواست لاگ کنید. output_tokens شامل تفکر گسترده (extended thinking) است، بنابراین مدلی که پیش از پاسخ‌دهی فکر می‌کند، هزینه آن تفکر را با نرخ خروجی محاسبه می‌کند. برای قیمت‌گذاری یک پرامپت پیش از ارسال، 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 و ChatGPT اطلاعات بیشتری نسبت به کنار هم قرار دادن دو کارت نرخ به شما می‌دهد. ارزش یک میلیون توکن 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٪ از هزینه‌ها است و پرامپت عملاً قابل چشم‌پوشی است. اکثر افراد نسبت واقعی خود را اشتباه حدس می‌زنند، بنابراین پیش از انجام هرگونه بهینه‌سازی، حتماً آمار دقیق را از لاگ‌های خود استخراج کنید.

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

یک گام از عامل بازیابی (retrieval agent) را در نظر بگیرید: 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) از prompt، حدود یک‌سوم هزینه را کاهش می‌دهد. محدود کردن طول خروجی در عاملی که متکی بر خواندن است، تقریباً تلاشی بیهوده محسوب می‌شود. اینکه توکن‌های یک عامل کدنویسی واقعاً کجا مصرف می‌شوند، تحلیل می‌کند که چه چیزی در وهله اول آن prompt را پر می‌کند.

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

حالا شکل کار را تغییر دهید. یک دستورالعمل 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 دلار هزینه دارد، در حالی که این هزینه برای مدل Haiku 4.5 برابر با 0.062 دلار است. این اختلاف پنج‌برابری تقریباً به‌طور کامل از سمت خروجی ناشی می‌شود؛ یعنی دقیقاً همان جایی که یک مدل ارزان‌تر بیشترین صرفه‌جویی را برای شما به همراه دارد.

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

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

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

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

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

همان مرحله از ایجنت را روی 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) محدود می‌شود. اما پاسخ، توکن به توکن تولید می‌شود و هر توکن به یک forward pass مجزا نیاز دارد که دوباره تمام وزن‌های مدل را می‌خواند؛ در نتیجه سخت‌افزار توسط پهنای باند حافظه محدود می‌شود. Anthropic قیمت خروجی را در کل کاتالوگ فعلی خود، از Haiku 4.5 تا Fable 5، پنج برابر ورودی تعیین کرده است.

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

خیر. کش کردن پرامپت فقط برای ورودی اعمال می‌شود. تا اوت 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 منتقل کنید.