Copilot Billing Preview در 3 اوت 2026 بازنشسته می شود؛ راهنمای مهاجرت

اگر تیم شما هنوز برای تحلیل هزینه GitHub Copilot به Copilot Billing Preview app تکیه دارد، GitHub این App را در 3 اوت 2026 بازنشسته می کند و پنجره مهاجرت عملاً به پایان رسیده است. خبر خوب این است که قابلیت های اصلی به Billing داخلی GitHub منتقل شده اند؛ اما Dashboard، Budget، Export و Automationهایی که روی App قدیمی ساخته اید باید قبل از قطع شدن مسیر قبلی بازبینی شوند.

چه چیزی در 3 اوت 2026 حذف می شود؟

آنچه حذف می شود خود Copilot Billing Preview app است، نه Billing یا Copilot usage. دلیل GitHub این است که تجربه Built-in اکنون داده هایی دارد که Reportهای زیرساخت App قدیمی کامل نشان نمی دهند؛ از جمله Budget سطح کاربر، Cost Center و نحوه تخصیص Usage Pool. بنابراین مهاجرت صرفاً «URL جدید Dashboard» نیست. اگر تیم Finance یا Platform فایل Export، Bookmark، Runbook یا اسکریپت استخراج داده را بر اساس App قدیمی ساخته، باید Dependency آن را پیدا و جایگزین کند.

در سازمان های کوچک ممکن است تنها کار، آشناشدن با AI usage page باشد. در Enterprise، موضوع پیچیده تر است: Cost allocation، بودجه هر Org/User، Chargeback داخلی و گزارش ماهانه ممکن است چند ذی نفع داشته باشد. Owner مهاجرت را مشخص کنید و یک نمونه گزارش پایان ماه را قبل از Deadline از مسیر جدید تولید کنید. اگر عددها و grouping با فرایند مالی شما همخوان نیستند، فردای بازنشستگی زمان خوبی برای کشف تفاوت نیست.

جایگزین رسمی؛ چهار مسیر به جای یک Preview App

بهتر است هر Persona فقط ابزار لازم را ببیند. Engineering Manager برای پیدا کردن تیم پرمصرف به Group/Filter نیاز دارد؛ Finance به Export و Cost Center؛ Platform به API و Budget enforcement. یک Dashboard واحد که برای همه نقش ها شلوغ است، معمولاً Governance را بدتر می کند. مهاجرت فرصت خوبی است که سؤال های گزارش را دوباره تعریف کنید: «کدام کاربر هزینه دارد؟» با «کدام جریان کاری ROI ندارد؟» متفاوت است و Data Model متفاوت می خواهد.

Budget را از گزارش جدا کنید

Report به شما می گوید چه اتفاقی افتاده؛ Budget قرار است جلوی اتفاق ناخواسته بعدی را بگیرد. اگر قبلاً Preview App فقط برای مشاهده مصرف استفاده می شد، مهاجرت را با تعریف Budget تکمیل کنید. سقف باید با مدل سازمانی شما هماهنگ باشد: Budget تیمی، فردی یا Cost Center. در Enterprise، User-level budget به شما اجازه می دهد anomalous usage را در سطح فرد کنترل کنید، اما نباید تبدیل به Micromanagement کور شود. Context نقش، پروژه و مدل مصرف مهم است.

یک Policy خوب سه لایه دارد: Baseline برای استفاده عادی، Alert قبل از رسیدن به سقف و Exception flow برای تیمی که به طور موقت مصرف بیشتری نیاز دارد. اگر فقط Hard Cap بگذارید، در روز Release ممکن است workflow حیاتی متوقف شود. اگر فقط Alert دارید، Cost runaway همچنان ممکن است. Budget باید با Owner و escalation path همراه باشد. این همان تفاوت بین تنظیم UI و FinOps واقعی است.

Usage Report و Billing API؛ مسیر Automation

GitHub می گوید داده خام Usage را می توان از Usage Report و Billing API گرفت. برای تیم هایی که Export Preview App را به BI می فرستادند، بهترین Migration این است که ingestion را از رابط رسمی جدید بسازند و Schema را versioned نگه دارند. قبل از Cutover، یک بازه زمانی مشترک را از مسیر قدیم و جدید استخراج کنید و اختلاف aggregation را بررسی کنید. ممکن است grouping یا field naming یکسان نباشد و Dashboard بدون خطا اما با عدد متفاوت کار کند.

API token را با حداقل Scope نگه دارید، secret را در CI/Secret Manager ذخیره کنید و Raw Billing Data را به دلیل حساسیت سازمانی عمومی نکنید. داده هزینه می تواند رفتار تیم، پروژه های فعال و الگوی استفاده از AI را آشکار کند. Retention و Access Control برای Data Warehouse را مشخص کنید. «Billing data است، پس امنیتی نیست» فرض خطرناکی است.

الگوی ساده Pipeline گزارش

GitHub Billing API -> scheduled ingestion -> validated raw table -> cost-center mapping -> dashboard / alerts

این Pipeline باید idempotent باشد و از یک cursor یا window زمانی روشن استفاده کند. اگر Job دوباره اجرا شد، نباید مصرف دو بار حساب شود. همچنین Raw table را از Business mapping جدا نگه دارید تا تغییر ساختار تیم، تاریخچه ماه قبل را بازنویسی نکند. این جزئیات کوچک در Billing Automation اهمیت زیادی دارند.

چک لیست مهاجرت قبل از 3 اوت

1. تمام افرادی را که از Preview App استفاده می کنند شناسایی کنید.
2. Bookmark، Export، Script و Dashboard وابسته را Inventory کنید.
3. AI usage page جدید را با همان بازه و grouping قبلی مقایسه کنید.
4. Budget و Owner آن را برای Org/Enterprise تعریف کنید.
5. اگر Automation دارید، Usage Report یا Billing API را جایگزین کنید.
6. یک گزارش آزمایشی پایان ماه از مسیر جدید تولید کنید.
7. Runbook و Documentation داخلی را با مسیر Built-in به روزرسانی کنید.

Cutover را با «App دیگر باز نمی شود» تعریف نکنید. Definition of Done یعنی تیم مالی بتواند همان سؤال های قبلی را پاسخ دهد، Alert هزینه کار کند، داده API وارد Warehouse شود و Ownerها بدانند Exception را کجا درخواست کنند. بعد از قطع App قدیمی، یک هفته Dual Observation روی خروجی جدید انجام دهید و Anomalyهای عددی را ثبت کنید.

بعد از مهاجرت؛ از Billing به Governance برسید

داده مصرف Copilot وقتی ارزشمند است که به تصمیم Productive وصل شود. صرفاً Rank کردن کاربران پرمصرف می تواند برداشت غلط بسازد؛ فردی که Code Review یا Agent workflow سنگین دارد ممکن است هزینه بیشتری اما ارزش بیشتری ایجاد کند. بهتر است Cost را کنار Outcome ببینید: Cycle time، PR throughput، Review latency یا تعداد taskهای agentic که واقعاً تکمیل شده اند. هدف کنترل کور هزینه نیست؛ هدف هزینه قابل توضیح و قابل برنامه ریزی است.

Cost Centerها نیز باید با ساختار واقعی سازمان نگاشت شوند. اگر افراد بین تیم ها جابه جا می شوند، mapping تاریخی را نگه دارید. برای پروژه موقت، tag یا mapping جدا بسازید. Report ماهانه باید بتواند افزایش مصرف را به Release، pilot مدل جدید یا تغییر policy نسبت دهد. این Context مانع واکنش های شتاب زده مثل کاهش عمومی Budget می شود.

اشتباهات رایج در این مهاجرت

• فرض اینکه بازنشستگی Preview App یعنی Copilot billing متوقف می شود؛ در واقع تجربه Built-in جایگزین است.
• تکیه بر Export دستی بدون Owner و زمان بندی مشخص.
• مقایسه عدد قدیم و جدید بدون یکسان کردن بازه زمانی، timezone و grouping.
• دادن Token API با Scope بیش از نیاز به Job گزارش.
• ساخت Hard Cap بدون Alert و Exception flow.
• انتشار Dashboard هزینه برای مخاطبانی که نیاز دسترسی ندارند.

پرسش های متداول

Copilot Billing Preview چه زمانی بازنشسته می شود؟

GitHub تاریخ 3 اوت 2026 را اعلام کرده است.

بعد از حذف App، هزینه Copilot را کجا ببینیم؟

در AI usage page داخل Billing settings GitHub می توانید مصرف را group، filter و export کنید.

آیا Budget سطح کاربر وجود دارد؟

برای Organization و Enterprise، GitHub به user-level budgets اشاره کرده است.

برای BI و Automation چه کنیم؟

Usage reports و Billing API مسیر رسمی دریافت Raw usage data هستند.

آیا باید قبل از Deadline کاری انجام دهیم؟

اگر Export، Dashboard یا Automation به Preview App وابسته است، بله؛ مسیر جدید را قبل از قطع App تست و مستند کنید.

منبع اصلی و جمع بندی

اطلاعات Deadline و جایگزین ها از اعلام رسمی GitHub آمده است. مهاجرت خوب فقط بازکردن صفحه Billing جدید نیست؛ Report، Budget، API، Access Control و Runbook باید با هم منتقل شوند تا تیم بعد از 3 اوت هم Visibility و هم Cost Control داشته باشد.

کنترل نهایی مدیر فنی

• یک Owner برای Billing داده و یک Owner برای Budget policy تعیین شده است.
• گزارش مسیر جدید با داده واقعی Validate شده است.
• API integration در صورت وجود Secret و idempotency مناسب دارد.
• Cost center mapping تاریخ دار است و جابه جایی افراد تاریخچه را خراب نمی کند.
• Alert قبل از Hard Cap تعریف شده است.
• Exception flow برای تیم های Release و Pilot مستند شده است.
• دسترسی Dashboard و Raw data بر اساس نیاز واقعی محدود است.

قبل از خاموشی Preview یک Reconciliation واقعی انجام دهید

مهاجرت Billing زمانی تمام نشده که Dashboard جدید باز شود. حداقل یک بازه مصرف را همزمان از Preview موجود، AI usage و Usage Report/Billing API استخراج کنید و اختلاف را بررسی کنید. ممکن است تعریف بازه زمانی، Scope سازمان، Cost Center یا زمان ثبت Usage در دو نما متفاوت باشد؛ بنابراین انتظار برابری لحظه ای بدون شناخت مدل داده اشتباه است. هدف Reconciliation این است که تیم Finance و Platform بداند هر Metric از کدام منبع می آید، برای چه تصمیمی استفاده می شود و چه تأخیری را باید طبیعی در نظر بگیرد. نتیجه را در Runbook ثبت کنید تا بعد از 3 اوت یک عدد متفاوت به اشتباه Incident تلقی نشود.

برای گزارش ماهانه، Snapshot خروجی قدیمی را نیز نگه دارید اگر سیاست نگهداری سازمان اجازه می دهد. این Snapshot مرجع مقایسه تاریخی است و به شما کمک می کند Trend قبل و بعد از Migration را بدون وابستگی به UI بازنشسته شده حفظ کنید. اما داده Billing ممکن است اطلاعات سطح کاربر یا سازمان داشته باشد؛ Access و Retention آن باید مطابق سیاست داخلی باشد. Export را در Shared Folder عمومی رها نکنید و دسترسی Dashboard/Report را فقط به نقش هایی بدهید که برای FinOps یا Administration نیاز واقعی دارند.

Budget را از گزارش جدا ببینید

یکی از خطاهای رایج این است که Dashboard را کنترل هزینه تصور کنیم. مشاهده مصرف با جلوگیری از Spend اضافی یک چیز نیست. اگر GitHub برای Scope شما Budget و user-level budget ارائه می کند، Threshold را بر اساس سیاست تیم تنظیم کنید و Owner پاسخ گو تعیین کنید. Budget بدون Owner فقط یک عدد است. همچنین تصمیم بگیرید وقتی Threshold نزدیک می شود چه اتفاقی باید بیفتد: اطلاع رسانی، بررسی Usage غیرعادی، بازتخصیص Cost Center یا تغییر Policy مدل. این Workflow باید قبل از بحران هزینه نوشته شود، نه پس از پایان ماه.

در Enterpriseهای بزرگ، Cost Center و Allocation اهمیت بیشتری از Total spend دارند. یک افزایش مصرف ممکن است کاملاً منطقی باشد اگر تیم تازه ای Rollout شده یا Agent workflow جدیدی فعال شده است. بنابراین KPI را با Context مهندسی ترکیب کنید: تعداد کاربران فعال، نوع Feature یا مدل قابل استفاده در گزارش رسمی، و تغییرات Rollout. از نسبت دادن مستقیم «مصرف بیشتر = بهره وری بیشتر» یا «مصرف کمتر = صرفه جویی موفق» خودداری کنید؛ Billing داده هزینه است و برای نتیجه گیری درباره بهره وری به Metric مستقل نیاز دارید.

Automation بعد از Migration باید قابل مشاهده و قابل شکست باشد

اگر Usage Report یا Billing API را وارد BI می کنید، Job را با Schema validation، Retry محدود و Alert روی stale data بسازید. Dashboardی که سه روز بدون Refresh مانده اما سبز به نظر می رسد از شکست واضح خطرناک تر است. Last successful import، بازه داده و Scope را کنار نمودار نمایش دهید. همچنین Credential یا Token مورد استفاده را با کمترین دسترسی لازم نگه دارید و Rotation آن را در Runbook بنویسید. هدف این است که حذف Preview App به ایجاد یک Pipeline شکننده و بدون Owner منجر نشود.