اقتصاد توسعه با کمک AI برای یک تیم plugin WordPress

سؤالی که در ماه 1 نمی‌توانستیم صادقانه پاسخ دهیم

عرضه یک plugin WordPress با Claude Code به‌عنوان یک همکار روزانه چقدر هزینه دارد؟

برای اولین ماه ساخت Statnive، نمی‌توانستیم پاسخ دهیم. ما صورت‌حساب را می‌دانستیم. نمی‌دانستیم چه چیزی واقعاً آن را هدایت می‌کند. برخی روزها $3 بود، دیگر $11، و variance با میزان کد عرضه شده ارتباط واضحی نداشت.

چهار ماه بعد ما تصویر بسیار روشن‌تری داریم. این پست حسابداری هزینه است: جایی که پول می‌رود، چهار اهرمی که برای حدود 2 تا 3 برابر خرج ما ترکیب می‌شوند، و یک عددی که بیشتر از هر بهینه‌سازی منفرد اهمیت داشت.

سرتیتر: خرج روزانه از حدود $6/روز به حدود $2 تا 3/روز برای همان throughput مهندسی کاهش یافت. صرفه‌جویی‌ها افزایشی نیستند. ضرب می‌شوند.

کجا خرج AI واقعاً می‌رود

قیمت‌گذاری Anthropic برای مدل‌های مرتبط با Claude Code، فعلی از اوایل 2026:

مدل	ورودی / MTok	خروجی / MTok	بهترین برای
Haiku 4.5	$1	$5	اکتشاف فقط-خواندنی، اعتبارسنجی، اصلاحات روتین
Sonnet 4.6	$3	$15	کار توسعه استاندارد
Opus 4.7	$5	$25	معماری پیچیده، استدلال عمیق

به‌طور ساده، یک مدل را انتخاب می‌کنید و آن نرخ × مصرف توکن خود را می‌پردازید. واقعیت ریزدانه‌تر است، و سه از چهار اهرم بهینه‌سازی زیر از آن استفاده می‌کنند.

برای مرجع، اینجا بودجه‌های توکن معمولی به ازای هر عملیات هستند:

نوع عملیات	توکن معمولی	زمان واقع‌بینانه
اصلاح ساده (Haiku)	2K تا 5K	1 تا 2 دقیقه
ویژگی استاندارد (Sonnet)	10K تا 20K	5 تا 10 دقیقه
Refactor پیچیده (Sonnet + thinking گسترده)	30K تا 50K	15 تا 25 دقیقه
بازبینی معماری (Opus)	50K تا 100K	20 تا 40 دقیقه

ضرب شده در یک روز کاری، آن جایی است که حدود $6/روز روی یک مهندس منفرد می‌آید. ضرب در سال، مکالمه بهینه‌سازی جدی می‌شود.

اهرم 1 — Prompt Caching (حدود 90% روی prefix پایدار)

Claude Code به‌طور خودکار prefix پایدار هر مکالمه را cache می‌کند: system prompt، تعاریف ابزار داخلی، metadata مهارت و CLAUDE.md ریشه. خواندن‌های cache 0.1 برابر قیمت پایه هزینه دارند — یک کاهش 90% روی بخش cache شده.

prefix پایدار 50K+ توکن برای بیشتر راه‌اندازی‌ها است. بدون caching، هر نوبت آن 50K توکن را دوباره شارژ می‌کند. با caching، هر نوبت پس از اول آن‌ها را با 10% هزینه می‌خواند.

دو قاعده عملی:

1. محتوا را static-first، dynamic-last مرتب کنید. Cache hits به یک تطابق دقیق prefix نیاز دارند. هر چیز پویا در شروع یک مکالمه cache را می‌شکند و یک خواندن مجدد کامل را اجبار می‌کند. ما CLAUDE.md ریشه و metadata مهارت را اول، context پویا (فایل‌های تغییر یافته، حالت شاخه فعلی) را آخر نگه می‌داریم.
2. prefix را با هر چیزی که در هر نشست تغییر می‌کند آلوده نکنید. این استدلال واقعی برای نگه داشتن CLAUDE.md لاغر است — هر بایتی که حذف می‌کنید بایتی است که وقتی فایل تغییر می‌کند نیاز به caching مجدد ندارد، و prefixهای cache شده کوتاه‌تر برای رفرش وقتی منقضی می‌شوند ارزان‌تر هستند.

Caching بزرگ‌ترین اهرم هزینه منفرد است، و عمدتاً خودکار است. کار در نشکستن آن است.

اهرم 2 — مسیریابی مدل (3 برابر روی بخش مسیریابی شده)

Haiku 4.5 3 برابر کمتر از Sonnet به ازای هر توکن هزینه دارد. تفاوت قابلیت برای وظایف فقط-خواندنی و اعتبارسنجی حداقل است. Anthropic پیشنهاد می‌کند پیش‌فرض Haiku برای حدود 80% وظایف روتین قرار دهید.

در عمل ما به این صورت مسیریابی می‌کنیم:

وظیفه	مدل	چرا
اکتشاف کد (“همه جاهایی را پیدا کن که X فراخوانی می‌شود”)	Haiku (subagent)	فقط-خواندنی، قطعی
triage شکست آزمون	Haiku (subagent)	تطبیق الگو، قضاوت کم
پیاده‌سازی ویژگی استاندارد	Sonnet (اصلی)	پیش‌فرض برای کار مولد
تصمیمات معماری، طراحی schema	Opus (اصلی، گاه به گاه)	ارزش premium برای استدلال سخت
پاس بازبینی کد	Haiku (subagent fork)	خواندن سنگین، خلاصه برمی‌گردد

مسیریابی قوی‌ترین است وقتی با subagentها جفت شود، زیرا subagentها تنظیم مدل خود را مستقل از نشست اصلی دارند. ما می‌توانیم مکالمه اصلی را روی Sonnet اجرا کنیم در حالی که یک subagent fork کار خواندن سنگین را روی Haiku انجام می‌دهد. مسیریابی مدل در مرز مهارت اتفاق می‌افتد، نه مرز مکالمه.

اهرم 3 — ایزولاسیون Subagent (حدود 37% کاهش context اصلی)

Subagentها (که agentهای fork هم نامیده می‌شوند) پنجره context 200 هزار توکنی خود را می‌گیرند. کار انجام شده درون یک subagent مکالمه اصلی را آلوده نمی‌کند. فقط یک خلاصه برمی‌گردد.

Anthropic مستند می‌کند subagentها حدود 500 تا 1,000 توکن از 10,000+ کار داخلی برمی‌گردانند — تقریباً یک کاهش 37% در context اصلی روی وظایف پیچیده.

دو اثر هزینه:

1. صرفه‌جویی مستقیم توکن. یک بازبینی کد که 30 فایل می‌خواند و یک حکم برمی‌گرداند توکن‌های خود را در ایزولاسیون مصرف می‌کند. بدون ایزولاسیون، آن 30 خواندن فایل در context اصلی می‌نشینند، در هر نوبت بعدی دوباره شارژ می‌شوند (تعدیل شده توسط caching).
2. صرفه‌جویی توکن کیفیت‌محور. contextهای طولانی کیفیت بازیابی را تنزل می‌دهند — تحقیق افت عملکرد 15 تا 47% را با پر شدن context مستند می‌کند، مشکل «گم شده در میانه». کیفیت پایین‌تر یعنی تلاش‌های بیشتر، خواندن‌های مجدد بیشتر، توکن‌های بیشتر. نگه داشتن context اصلی تمیز از این کلاس کامل هدر جلوگیری می‌کند.

مبادله واقعی است: تیم‌های agent تقریباً 7 برابر توکن کلی بیشتر از نشست‌های استاندارد استفاده می‌کنند زیرا هر agent یک نمونه تازه با سربار راه‌اندازی خود راه‌اندازی می‌کند. ما آن را می‌پذیریم زیرا ما برای کل توکن بهینه نمی‌کنیم — ما برای پاکی context اصلی و throughput کلی بهینه می‌کنیم. و subagentها روی Haiku بدون توجه ارزان هستند.

اهرم 4 — موکول کردن ابزار MCP (حدود 85%)

ما این را با جزئیات در پست MCP Tool Search پوشش دادیم. نسخه کوتاه:

بیست‌و‌چهار connector MCP بدون موکول حدود 135,000 توکن سربار baseline به ازای هر نشست مصرف می‌کردند. Tool Search آن را به حدود 3,000 توکن برای شاخص کاهش داد، با schemaهای کامل که on demand بارگذاری می‌شوند. کاهش 85%، دقت بالا رفت، نشست‌ها از احساس فشرده شدن متوقف شدند.

اثر هزینه: هر توکن سربار baseline توکنی است که بخشی از prefix cache شده در هر نشست است. قطع 130K توکن سربار، قطع تقریباً 130K × 0.1 برابر نرخ به ازای هر توکن × ارزش-cache-reads-هر-نشست است. حتی با 10% هزینه، صدها دلار در ماه برای یک مهندس کاری است.

ضرب‌کننده مرکب

اینجا بخشی است که اعداد سرتیتر ضبط نمی‌کنند. چهار اهرم ضربی هستند، نه افزایشی.

یک نشست baseline را تصور کنید که حدود $0.30 در یک وظیفه 5 دقیقه‌ای می‌سوزاند. هر اهرم را به‌نوبت اعمال کنید:

اهرم	اثر	هزینه در حال اجرا
Baseline	—	$0.30
Prompt caching (90% روی prefix پایدار)	prefix پایدار حدود 70% توکن نشست است	حدود $0.12
مسیریابی مدل (3 برابر روی کار واجد شرایط Haiku)	حدود 50% کار واجد شرایط Haiku است	حدود $0.07
ایزولاسیون Subagent (37% کاهش context اصلی)	context اصلی کوچک می‌شود → کمتر دوباره شارژ می‌شود	حدود $0.05
موکول کردن ابزار MCP (85% روی سربار schema ابزار)	schemaها دیگر baseline نیستند	حدود $0.04

هر گام متوسط است. ترکیب چشمگیر است. درصدهای دقیق چیزی نیست که اهمیت دارد — بینش ساختاری این است که بهینه‌سازی‌های هزینه توکن به‌صورت ضربی ترکیب می‌شوند زیرا روی بخش‌های متداخل صورت‌حساب اعمال می‌شوند. چهار از آن‌ها را اصلاح کنید و نظم بزرگی را تغییر داده‌اید.

به همین دلیل خرج روزانه ما از حدود $6 به حدود $2 تا 3 کاهش یافت بدون تغییر آنچه عرضه می‌کردیم. همان کد، همان آزمون‌ها، همان آهنگ release. پیش‌فرض‌های متفاوت.

الان روی چه چیزی پول خرج می‌کنیم

یک روز مهندسی Statnive معمولی، پس از بهینه‌سازی:

فعالیت	هزینه تقریبی
بازبینی کد صبحگاهی روی یک PR باز (forked، Haiku)	حدود $0.20
2 ویژگی استاندارد در داشبورد React (Sonnet، با caching)	حدود $0.80
1 اجرای گیت release (مهارت statnive-release)	حدود $0.30
پیش‌نویس مستندات/پست وبلاگ	حدود $0.40
اکتشاف متفرقه و پرسش‌و‌پاسخ	حدود $0.50
مجموع	حدود $2.20

در سراسر تیم، صورت‌حساب ماهانه Anthropic ما به‌خوبی زیر هزینه یک اشتراک SaaS قدیمی منفرد است. برای context: آن صورت‌حساب یک همکار AI را تأمین می‌کند که به عرضه یک plugin WordPress استفاده شده توسط کسب‌و‌کارهای واقعی، با 141 آزمون و 31 بررسی انطباق که هر release را گیت می‌کند کمک می‌کند.

Extended Thinking: کلمه کلیدی را با وظیفه تطبیق دهید

یک نکته قیمت‌گذاری ارزش دانستن: حالت‌های thinking گسترده Claude بودجه‌های فعال شده با کلمه کلیدی دارند:

کلمه کلیدی	بودجه thinking
think	5K تا 10K توکن
think hard	20K تا 50K توکن
think harder	50K تا 100K توکن
ultrathink	100K تا 128K توکن (حداکثر)

این توکن‌ها به‌عنوان ورودی شمارش می‌شوند. ارزان‌ترین که برای وظیفه متناسب است را استفاده کنید. ما برای کار روتین به بدون thinking modifier پیش‌فرض می‌دهیم، think hard برای تصمیمات طراحی غیرپیش‌پاافتاده، و ultrathink فقط برای سؤالات معماری واقعی که در آن استدلال عمیق ارزش خود را می‌گیرد. دستیابی به ultrathink روی یک اصلاح تایپی معادل توسعه AI اجرای یک پنجره Chrome 50 تب برای خواندن یک webpage است.

بهداشت نشست به اندازه اهرم‌ها به ما کمک کرد

یک یافته ضد شهودی: بزرگ‌ترین variance منفرد در هزینه روزانه ما طول نشست بود، نه پیکربندی مهارت یا ابزار.

نشست‌های autonomous طولانی بدون ریست context کیفیت را به‌طور تدریجی تنزل می‌دهند. اثر «گم شده در میانه» — افت عملکرد 15 تا 47% با پر شدن context — مستقیماً به تلاش‌های بیشتر، خواندن‌های مجدد بیشتر و توکن‌های هدر شده بیشتر ترجمه می‌شود. نشست‌هایی که فراتر از 80% context رفتند به‌طور معمول 2 تا 3 برابر آنچه نشست‌های کوتاه‌تر برای همان کار هزینه داشتند هزینه می‌کردند.

دو قاعده بهداشت اکنون در نحوه کار ما پخته شده است:

1. /clear بین وظایف نامرتبط. تغییر از یک باگ frontend به یک تغییر گیت release دو مکالمه متفاوت است. پاک کردن context هیچ هزینه‌ای ندارد و از آلودگی جلوگیری می‌کند.
2. /compact پیشگیرانه در 60 تا 70% context، نه در آستانه auto-compact 95%. Auto-compact در حد یک عملیات ترس است که اطلاعات را از دست می‌دهد. compact پیشگیرانه حالت مهم را حفظ می‌کند و نویز را ریست می‌کند.

پایداری حالت به فایل‌ها به‌جای تاریخچه مکالمه هر دو قاعده را امن می‌کند — هر چیز مهم روی دیسک است، بنابراین یک clear آن را از دست نمی‌دهد.

آنچه بهینه نکردیم

• هنوز هزینه به ازای هر مهارت را اندازه نمی‌گیریم. می‌توانیم مجموع روزانه را از طریق صورت‌حساب Anthropic ببینیم و از دستورات محلی /cost و /stats برای بررسی نقطه‌ای استفاده می‌کنیم، اما انتساب به ازای هر مهارت نداریم. ابزارهایی مثل ccusage (فایل‌های نشست JSONL محلی Claude را می‌خواند) و Claude-Code-Usage-Monitor وجود دارند؛ ما آن‌ها را ادغام نکرده‌ایم.
• نسبت subagent ما احتمالاً خیلی کم است. ما از حالت fork به‌طور تهاجمی برای بازبینی و ممیزی استفاده می‌کنیم، اما کسر معناداری از کار استاندارد ما به‌طور قابل قبول می‌تواند fork شود تا context اصلی تمیزتر بماند. به‌طور دقیق اندازه نگرفته‌ایم.
• ما مقایسه‌های A/B رسمی اجرا نمی‌کنیم. عدد $6 به $2 تا 3 از مقایسه خرج ما قبل و بعد از بهینه‌سازی‌هایی که پایدار شدند می‌آید. هیچ آزمایش کنترل شده‌ای پشت آن نیست. مال شما متفاوت خواهد بود.

چه چیزی برای نصف کردن دوباره آن لازم است

پاسخ صادقانه: احتمالاً هیچ چیزی که ارزش انجام دادن را داشته باشد.

ما می‌توانیم سخت‌تر روی Haiku فشار دهیم. می‌توانیم کار بیشتری را در subagentها دسته‌بندی کنیم. می‌توانیم قراردادهای بودجه خروجی تهاجمی‌تر در مهارت‌هایمان بنویسیم. هر کدام شاید 10 تا 20% بیشتر بتراشد.

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

Statnive را امتحان کنید

تحلیل‌گری حریم‌خصوصی‌محور WordPress ساخته شده توسط تیمی که حسابداری هزینه را به همان جدیت پوشش آزمون می‌گیرد. Statnive را رایگان از WordPress.org نصب کنید — داده‌های شما روی سرور شما باقی می‌ماند، خرج ما روی یک خط بودجه منفرد می‌ماند، و کل تمرین مهندسی متن‌باز است.