شما یک سرور MCP منتشر کرده‌اید که کاری واقعاً مفید انجام می‌دهد — مثلاً دسترسی ساختاریافته به یک کاتالوگ قطعات یا یک ابزار خلاصه‌سازی اسناد — و یک روز صبح با ۴۰٬۰۰۰ فراخوانی ابزار که یک‌شبه از عامل‌های هوش مصنوعی که هرگز ندیده‌اید رسیده‌اند، از خواب بیدار می‌شوید. این رؤیاست، تا زمانی که متوجه شوید سیستم اندازه‌گیری صورتحساب، دفاتر و تنظیمات مالیاتی شما همه برای انسان‌هایی طراحی شده بودند که با سرعت انسانی روی دکمه کلیک می‌کنند. عامل‌ها مانند کاربران انسانی رفتار نمی‌کنند: یک دستور می‌تواند ده‌ها فراخوانی ابزار را در چند ثانیه زنجیره کند، هزاران درخواست را برای حل یک دستور واحد تکرار کند و در هر گام هزینه‌های پایین‌دستی ایجاد کند. اگر برای دسترسی هزینه دریافت می‌کنید، به اندازه‌گیری‌ای نیاز دارید که با نحوه مصرف عامل‌ها همخوانی داشته باشد، سوابق درآمدی که با زمان ارائه ارزش مطابقت داشته باشد و ردیابی هزینه که حاشیه سود شما را قابل مشاهده نگه دارد. این راهنما هر سه را بررسی می‌کند.
درآمد MCP در واقع چگونه به دست می‌آید
پروتکل Model Context Protocol سرور شما را به‌عنوان مجموعه‌ای از ابزارها و منابع در اختیار مشتریان هوش مصنوعی قرار می‌دهد که آن‌ها را از طریق JSON-RPC فراخوانی می‌کنند. چون هر فراخوانی برنامه‌نویسی‌شده است، شما گزینه‌های قیمتگذاری بیشتری نسبت به یک صندلی SaaS سنتی دارید — و هر یک به شکل متفاوتی ثبت می‌شود.
به‌ازای هر فراخوانی ابزار. ساده‌ترین مدل: هر فراخوانی متد هزینه ثابتی دارد. اندازه‌گیری و توضیح آن آسان است و زمانی خوب کار می‌کند که ابزارهای شما هزینه تقریباً یکنواختی داشته باشند. اما زمانی که یک جستجوی سبک متادیتا تقریباً هیچ هزینه‌ای برای شما ندارد، در حالی که یک ابزار گردش‌کار به ده‌ها فراخوانی API پایین‌دستی منشعب می‌شود، از هم می‌پاشد.
بر اساس حجم داده. وقتی متدها محموله‌های بزرگ برمی‌گردانند — محتوای سند، جاسازی‌ها، نتایج پرس‌وجو — دریافت هزینه به‌ازای هر مگابایت بازگشتی یا هر هزار توکن، قیمت را با هزینه همسو می‌کند، همان‌طور که ارائه‌دهندگان مدل APIهای خود را قیمتگذاری می‌کنند.
بر اساس نتیجه. به‌جای دریافت هزینه به‌ازای هر تلاش، به‌ازای هر اقدام تکمیل‌شده هزینه می‌گیرید: به‌ازای هر سند که با موفقیت خلاصه شده، هر فرمان دستگاه که اجرا شده، هر پرس‌وجو که نتایج معتبر برمی‌گرداند. مشتریان آن را دوست دارند چون فراخوانی‌های ناموفق یا خالی رایگان هستند؛ شما به اندازه‌گیری‌ای نیاز دارید که پیش از شمارش یک واحد بتواند موفقیت را از شکست تشخیص دهد.
بر اساس نشست یا حافظه. سرورهایی که وضعیت گفتگو را در میان فراخوانی‌ها حفظ می‌کنند می‌توانند به‌ازای هر نشست ایجادشده، هر دقیقه زمان نشست فعال یا هر بلوک زمینه نگه‌داشته‌شده هزینه بگیرند. این برای دستیارها و عامل‌های بلندمدتی مناسب است که به لایه حافظه شما تکیه می‌کنند.
اشتراک ترکیبی به‌همراه مصرف مازاد. هزینه ماهانه پایه که سهمیه‌ای را شامل می‌شود، با هزینه‌های اندازه‌گیری‌شده پس از عبور از آستانه. این رایج‌ترین شکل در کسب‌وکارهای API در تولید است، چون پایه هزینه‌های ثابت شما را پوشش می‌دهد در حالی که مازاد با کاربران سنگین مقیاس می‌گیرد.
اعتبارهای پیش‌پرداخت. مشتریان بلوک‌های مصرف را پیشاپیش خریداری می‌کنند و آن‌ها را مصرف می‌کنند. برای جریان نقدی عالی است، برای حسابداری دشوارتر (در ادامه بیشتر توضیح می‌دهیم)، چون وجه دریافتی تا زمانی که اعتبارها مصرف نشوند درآمد کسب‌شده نیست.
پرداخت‌های بازارگاه. فهرست‌ها و بازارگاه‌های پیرامون سرورهای MCP سهمی از درآمد را برمی‌دارند و بقیه را به شما می‌پردازند — همان شکلی که فروش از طریق هر بازارگاه اپلیکیشنی دارد، با همان پرسش حسابداری ناخالص در برابر خالص.
پرداخت‌های خرد بومی عامل. پروتکل‌هایی مانند x402 به یک عامل اجازه می‌دهند به‌ازای هر درخواست در استیبل‌کوین روی HTTP پرداخت کند، بدون ثبت‌نام حساب و بدون صورتحساب. اگر این مسیر را انتخاب کنید، هر فراخوانی ابزار می‌تواند به یک فروش کوچک تبدیل شود، که پیامدهای واقعی برای نحوه ثبت درآمد و مبنای هزینه شما دارد. (برای پیشینه درباره نحوه کار این پرداخت‌های ماشینی، راهنمای ما درباره عامل‌های هوش مصنوعی که از طریق x402 به یکدیگر پرداخت می‌کنند را ببینید.)
معیاری را انتخاب کنید که مشتری آن را به‌عنوان ارزش درک می‌کند — این یک تصمیم محصولی است — اما بدانید که هر انتخاب در بالا الگوی حسابداری متفاوتی ایجاد می‌کند. بقیه این راهنما پول را در هر یک از این مسیرها دنبال می‌کند.
سیستم اندازه‌گیری شما سند منبع حسابداری شماست
در یک کسبوکار مبتنی بر مصرف، جریان رویدادهای مصرف همان چیزی است که برگه‌های زمان برای یک دفتر حقوقی هستند: سند منبعی که هر دلار روی صورتحساب را توجیه می‌کند. با آن این‌گونه رفتار کنید.
زیرساخت استاندارد این‌گونه است. سرور شما به‌ازای هر واحد قابل‌صورت‌حساب یک رویداد مصرف منتشر می‌کند — نام متد، هویت مشتری، مقدار، مُهر زمانی، موفقیت یا شکست. این رویدادها به یک لایه اندازه‌گیری (Stripe Billing Meters، یک پلتفرم صورتحساب مبتنی بر مصرف یا جمع‌کننده خودتان) جریان می‌یابند، که آن‌ها را به هر مشتری نسبت می‌دهد و در صورتحساب پایان دوره جمع می‌کند. صورتحساب اندازه‌گیری‌شده Stripe دقیقاً از این شکل پیروی می‌کند: شما در طول دوره مصرف را گزارش می‌دهید و در پایان دوره، آن رکوردها را جمع می‌زند و کل را صورتحساب می‌کند.
سه انضباط حسابداری از این خط لوله حاصل می‌شود:
- هر دوره سیستم اندازه‌گیری را با صورتحساب تطبیق دهید. واحدهای اندازه‌گیری‌شده ضربدر نرخ باید با درآمد مصرفی صورت‌حساب‌شده برابر باشد، همان‌طور که واحدهای ارسال‌شده ضربدر قیمت باید با فروش برابر باشد. هر شکافی یا مصرف سطح رایگانی است که قصدش را داشته‌اید، یا فراخوانی‌های ناموفقی که قیمتگذاری نتیجه‌محور شما بخشیده، یا نشت — مصرفی که سیستم اندازه‌گیری شما هرگز ندیده. نشت قاتل خاموش است: یک نقطه پایانی احراز هویت‌نشده یا یک ابزار اندازه‌گیری‌نشده، درآمدی است که کسب کرده‌اید و هرگز وصول نخواهید کرد.
- گزارش‌های خام مصرف را به‌عنوان رد حسابرسی خود نگه دارید. تجمیع‌ها آن چیزی است که صورتحساب می‌کنید؛ گزارش‌های سطح رویداد آن چیزی است که هنگام اعتراض مشتری به یک جهش یا پرسش حسابدار درباره اجزای یک عدد درآمد نشان می‌دهید. آن‌ها را حداقل به‌اندازه پنجره اعتراض صورتحساب، و ایده‌آل به‌اندازه سوابق مالیاتی خود نگه دارید.
- هویت را در لبه نسبت دهید. تصمیم بگیرید که طرف قابل‌صورت‌حساب، کاربر نهایی پشت دستور است یا دارنده کلید API که سرور شما را یکپارچه می‌کند، و آن تصمیم را در رویداد ثبت کنید. وقتی یک کلید سازمانی به عامل‌های پنجاه کارمند منشعب می‌شود، «مشتری کیست» یک پرسش حسابداری با پیامدهای مالیاتی است، نه فقط یک جزئیات صورتحساب.
ثبت صحیح درآمد مصرفی
اینجاست که اپراتورهای MCP بیشترین اشتباه را مرتکب می‌شوند: پول نقد به Stripe می‌رسد، آن را به‌عنوان درآمد ثبت می‌کنند و دفاتر بی‌صدا از واقعیت فاصله می‌گیرند. بر اساس ASC 606 — استاندارد شناسایی درآمد — قاعده برای قیمتگذاری مصرفی ساده است: درآمد را همان‌طور که مشتری مصرف می‌کند شناسایی کنید، چون هر واحد مصرف‌شده همان تعهد عملکردی است که برآورده می‌شود. هزینه‌های مصرفی ملاحظه متغیر هستند، یعنی آنچه را که واقعاً در دوره استفاده شده شناسایی می‌کنید، نه آنچه را که امیدوارید ارزش قرارداد باشد.
پرداخت به‌ازای مصرف خالص مورد آسان است. عامل‌ها در سپتامبر ۱۰۰٬۰۰۰ فراخوانی با نرخ اعلامی شما مصرف کرده‌اند؛ درآمد سپتامبر ۱۰۰٬۰۰۰ ضربدر نرخ است، حتی اگر صورتحساب تا اکتبر پرداخت نشود. هنگام صورتحساب، حساب دریافتنی ثبت کنید؛ درآمد در زمان وقوع مصرف. اگر می‌خواهید رفتار کامل اندازه‌گیری توکن و مصرف تحت ASC 606 را ببینید، راهنماهای ما درباره صورتحساب توکن‌ها و شناسایی درآمد SaaS مبتنی بر مصرف عمیق‌تر می‌روند.
ترکیب پایه به‌همراه مازاد به دو بخش تقسیم می‌شود. اشتراک پایه به‌طور متناسب در طول دوره خدمت شناسایی می‌شود — یک‌سی‌ام در روز برای طرح ماهانه — در حالی که مازاد هنگام وقوع مصرف اضافی شناسایی می‌شود. آن‌ها را در حساب‌های درآمد جداگانه نگه دارید. ترکیب آن‌ها دو عددی را که واقعاً کسبوکار شما را می‌گردانند پنهان می‌کند: MRR اشتراک قابل‌پیش‌بینی و درآمد مصرفی پرجهش.
اعتبارهای پیش‌پرداخت یک بدهی ایجاد می‌کنند، نه درآمد. وقتی مشتری بلوکی از اعتبارها می‌خرد، نقد را بدهکار و درآمد معوق را بستانکار کنید. هر بار که مصرف موجودی را کاهش می‌دهد، ارزش مصرف‌شده را از درآمد معوق به درآمد کسب‌شده منتقل کنید. باقی‌مانده‌ای که مشتریان هرگز بازخرید نمی‌کنند — مانده مصرف‌نشده — قاعده خودش را دارد: اگر تاریخچه شما اجازه می‌دهد سهم استفاده‌نشده را به‌طور قابل‌اعتماد تخمین بزنید، آن مانده مورد انتظار را به‌تدریج و متناسب با مصرف واقعی شناسایی می‌کنید؛ اگر برای تخمین زدن بسیار تازه‌کار هستید، تا زمانی که اعتبارها منقضی شوند یا بازخرید دور از ذهن شود صبر می‌کنید، سپس باقی‌مانده را شناسایی می‌کنید. سرورهای جدید MCP تقریباً همیشه در лагер دوم قرار می‌گیرند، پس مانده مورد انتظار را زودتر ثبت نکنید تا یک ماه را بهتر جلوه دهید.
قیمتگذاری نتیجه‌محور یک پیچیدگی زمانی اضافه می‌کند: درآمد زمانی شناسایی می‌شود که نتیجه به دست آمده و قابل‌اندازه‌گیری است، نه زمانی که فراخوانی آغاز می‌شود. اگر سیستم اندازه‌گیری شما فقط تکمیل‌های موفق را می‌شمارد، سوابق درآمد شما باید از همان شمارنده پیروی کنند — سیستم اندازه‌گیری و دفتر کل باید بر سر اینکه «یک فروش» چیست توافق داشته باشند.
دو عادت عملی همه این‌ها را قابل‌تحمل می‌کند. اول، یک حساب یا برچسب درآمد جداگانه برای هر系统 اندازه‌گیری (ابزارهای به‌ازای هر فراخوانی، حجم داده، نشست‌ها، مازاد) اجرا کنید، تا یک مشکل حاشیه سود در یک ابزار در یک کل ترکیبی پنهان نشود. دوم، یک بسته شدن پایان ماه اعمال کنید: مصرفی که مُهر زمانی سپتامبر دارد به سپتامبر تعلق دارد حتی اگر صورتحساب در ۲ اکتبر نهایی شود. خطوط لوله اندازه‌گیری با تأخیر دسته‌ای، خطاهای بسته شدن را به رایج‌ترین اشتباه اظهار در کسب‌وکارهای مصرفی تبدیل می‌کنند.
سمت هزینه: یک سرور MCP واقعاً چقدر هزینه دارد
درآمد به‌ازای هر فراخوانی ابزار بدون هزینه به‌ازای هر فراخوانی ابزار هیچ معنایی ندارد. بهای تمام‌شده کالای فروش‌رفته خود را از پایین به بالا بسازید:
- محاسبات و میزبانی. سرورها، کانتینرها یا فراخوانی‌های بدون سرور که ابزارهای شما را اجرا می‌کنند، به‌علاوه پهنای باند خروجی برای متدهای پرحجم.
- هزینه‌های API و مدل پایین‌دستی. هر فراخوانی LLM، جستجوی جاسازی، پرس‌وجوی جستجو یا درخواست API شخص ثالث که ابزارهای شما به نمایندگی مشتری انجام می‌دهند. اگر ابزار خلاصه‌سازی شما به‌ازای هر سند یک ارائه‌دهنده مدل را فراخوانی می‌کند، آن انتقال بزرگ‌ترین هزینه متغیر شماست و باید به‌ازای هر ابزار ردیابی شود، نه به‌عنوان یک توده ماهانه.
- هزینه‌های داده و مجوز. حق امتیاز یا هزینه‌های به‌ازای هر پرس‌وجو برای داده اختصاصی که سرور شما افشا می‌کند.
- سهم درآمد بازارگاه. سهم پلتفرم از فروش بازارگاه یک هزینه فروش است (یا کاهش در پرداخت خالص — یکی را انتخاب کنید و ثابت بمانید)، هرگز جبرانی که در درآمد دفن شده باشد.
- پردازش پرداخت. هزینه‌های کارت روی صورتحساب اشتراک، هزینه‌های درگاه روی صورت‌حساب‌ها، هزینه‌های شبکه روی تسویه استیبل‌کوین. در مقیاس پرداخت خرد این‌ها گاز می‌گیرند: یک هزینه ثابت به‌ازای هر تراکنش می‌تواند از حاشیه سود یک فراخوانی ابزار زیر یک سنت بیشتر شود، که دقیقاً دلیل انتخاب ریل‌های کم‌هزینه توسط پروتکل‌های پرداخت عامل است.
محاسبه واحد به‌ازای هر ابزار را قبل از قیمتگذاری انجام دهید. فرض کنید ابزار جستجوی کاتالوگ شما به‌ازای هر فراخوانی ۰٫۰۰۴ دلار در محاسبات به‌علاوه پرس‌وجوهای پایین‌دستی هزینه دارد و شما ۰٫۰۱ دلار دریافت می‌کنید. این شبیه ۶۰ درصد حاشیه سود ناخالص است — تا زمانی که پشتیبانی، زیرساخت اندازه‌گیری و بخشش فراخوانی‌های ناموفق آن را پایین بکشند. از هزینه اندازه‌گیری‌شده قیمتگذاری کنید، نه از احساسات، و هر بار که یک ارائه‌دهنده پایین‌دستی نرخ‌های خود را تغییر می‌دهد محاسبه را دوباره اجرا کنید.
رسیدهای استیبل‌کوین مستحق یک پاراگراف جداگانه هستند. برای اهداف مالیاتی، استیبل‌کوین‌ها دارایی هستند، نه ارز: ارزش بازار منصفانه در لحظه دریافت درآمد شماست و آن ارزش مبنای هزینه شما می‌شود. اگر سکه‌ها را نگه دارید و اتصال متزلزل شود یا بعداً با ارزش دیگری تبدیل کنید، تفاوت یک سود یا زیان است. در حجم پرداخت خرد، ردیابی به‌ازای هر تراکنش قابل‌مذاکره نیست — حدس تجمیعی از یک بازرسی جان سالم به در نمی‌برد — پس سوابق تسویه را به‌طور خودکار به دفاتر خود وصل کنید تا در پایان سال بازسازی نکنید.
مالیات فروش: API شما در ایالت‌های بیشتری از آنچه فکر می‌کنید مشمول مالیات است
این غافلگیری انطباق است که منتظر بیشتر اپراتورهای MCP است: فروش دسترسی API همان فروش نرم‌افزار یا محصولات دیجیتال است و ایالت‌ها این تعاریف را به‌سرعت گسترش می‌دهند.
- کالیفرنیا در ژوئن ۲۰۲۶ لایحه SB 122 را امضا کرد و مالیات فروش را به محصولات دیجیتال از جمله نرم‌افزار دسترسی از راه دور و SaaS گسترش داد، با اجرا از ۱ ژانویه ۲۰۲۷ — پایان دادن به معافیت چندین‌دهه‌ای در بزرگ‌ترین بازار ایالتی کشور.
- شیکاگو SaaS و نرم‌افزار ابری را تحت مالیات تراکنش اجاره اموال شخصی خود با نرخ ۹ درصد مالیات می‌گیرد، حتی اگر ایلینوی در سطح ایالتی مالیاتی بر SaaS وضع نکند.
- اوکلاهما مسیر مخالف را رفت و حکم داد که اشتراک‌های SaaS تحویل‌شده الکترونیکی معاف هستند — اثبات اینکه نمی‌توانید یک پاسخ واحد را در سراسر کشور فرض کنید.
آستانه‌های ارتباط اقتصادی تعیین می‌کنند که کجا باید وصول کنید: بیشتر ایالت‌های دارای مالیات فروش از آستانه ۱۰۰٬۰۰۰ دلار در فروش برای فروشندگان از راه دور استفاده می‌کنند، با کالیفرنیا، تگزاس و نیویورک در ۵۰۰٬۰۰۰ دلار. یک API اندازه‌گیری‌شده با دسترسی ملی می‌تواند در ایالتی که هرگز پا به آن نگذاشته‌اید، صرفاً بر اساس حجم تراکنش، از یک آستانه عبور کند.
چه باید کرد:
- قابلیت مالیات‌پذیری را به‌ازای هر ایالتی که مشتری دارید تعیین کنید، نه فقط جایی که زندگی می‌کنید. سیستم اندازه‌گیری شما قبلاً مکان مشتری را برای انتساب ثبت می‌کند — آن داده را برای ردیابی ارتباط دوباره استفاده کنید.
- فروش بازارگاه ممکن است پوشش داده شود. جایی که یک بازارگاه به‌عنوان تسهیل‌کننده بازارگاه واجد شرایط باشد، مالیات فروش شما را از طریق آن وصول و پرداخت می‌کند. فروش مستقیم از سایت خودتان یا نقطه پایانی x402 خودتان کاملاً مسئولیت شماست.
- وصول را زود خودکار کنید. یک موتور مالیاتی (Stripe Tax و رقبای آن) که به پرداخت متصل شود بسیار کمتر از ثبت‌نام، اظهارنامه و پرداخت دستی در ده‌ها ایالت هزینه دارد — و شواهد مکان مشتری را که حسابرسان می‌خواهند حفظ می‌کند.
- تقویم را زیر نظر بگیرید. با تاریخ اجرای ۲۰۲۷ کالیفرنیا و گسترش‌های مشابه در سایر مجالس قانونگذاری، موضع «ما برای نگرانی بیش از حد کوچک هستیم» به‌سرعت منقضی می‌شود.
پرداخت‌های بازارگاه و فرم‌های مالیاتی
اگر بخشی از درآمد شما به‌صورت پرداخت بازارگاه arrives، آن را همان‌طور که توسعه‌دهندگان فروشگاه اپلیکیشن ثبت می‌کنند ثبت کنید: فروش ناخالص را به‌عنوان درآمد و سهم پلتفرم را به‌عنوان هزینه ثبت کنید. فرم 1099-K شما (یا 1099-NEC، بسته به طبقه‌بندی پلتفرم) رقم ناخالص را گزارش می‌کند و IRS آن عدد را با اظهارنامه شما تطبیق می‌دهد — گزارش فقط واریز خالص، همان چیزی است که اخطارهای کم‌گزارشی را آغاز می‌کند. صورت‌های پرداخت ناخالص را هر ماه با واریزهای بانکی خالص تطبیق دهید و برنامه هزینه‌ای که تفاوت را توضیح می‌دهد نگه دارید.
همچنین به شکاف زمانی توجه کنید: تاریخ پرداخت پلتفرم تاریخ درآمد شما نیست. درآمد به دوره‌ای تعلق دارد که عامل‌های مشتری نهایی ابزارهای شما را مصرف کرده‌اند، حتی اگر بازارگاه دو هفته بعد پرداخت کند. برای فروش مستقیم همان اصل اعمال می‌شود — دوره مصرف تعیین‌کننده است، تاریخ تسویه نیست.
چک‌لیست پایان ماه برای اپراتورهای MCP
دفاتر خود را هر ماه به همان شکل ببندید و موارد لبه‌ای از تجمع باز می‌ایستند:
- مصرف اندازه‌گیری‌شده را به‌ازای هر مشتری و هر معیار بیرون بکشید و آن را به درآمد مصرفی صورت‌حساب‌شده گره بزنید. هر شکاف بالای سطح رایگان و مبنای بخشش شکست خود را بررسی کنید.
- صورت‌حساب‌های ترکیبی را به حساب‌های درآمد پایه (متناسب) و مازاد (به‌ازای مصرف) تقسیم کنید.
- برداشت‌های اعتبار پیش‌پرداخت را از درآمد معوق خارج کنید؛ موجودی‌های اعتباری کهنه را برای رفتار مانده مصرف‌نشده بررسی کنید.
- هزینه‌های API، میزبانی و داده پایین‌دستی را به‌ازای هر ابزار ثبت کنید؛ حاشیه سود ناخالص هر معیار را دوباره محاسبه کنید.
- صورت‌های ناخالص بازارگاه را با واریزهای خالص تطبیق دهید؛ صورت‌ها را با سوابق ماه بایگانی کنید.
- رسیدهای استیبل‌کوین را به ارزش بازار منصفانه ثبت کنید و مبنای هزینه را در طول تبدیل پیگیری کنید.
- مجموع مکان مشتری را با آستانه‌های ارتباط ایالتی بررسی کنید؛ وصول مالیات را در جایی که لازم است تأیید کنید.
- خروجی خام مصرف را با بسته بسته شدن ماه ذخیره کنید — این سند منبعی است که خودِ آینده‌تان (یا حسابرس) درخواست خواهد کرد.
مدیریت مالی خود را ساده کنید
درآمد اندازه‌گیری‌شده، موجودی اعتبار معوق، هزینه‌های انتقالی API و قابلیت مالیات‌پذیری در پنجاه ایالت، بخش‌های متحرک زیادی برای یک پروژه جانبی است که به‌عنوان یک سرور MCP آخر هفته آغاز شد. Beancount.io به شما حسابداری متن ساده با شفافیت کامل و کنترل بر داده‌های مالی‌تان می‌دهد — هر صورتحساب مصرف، برداشت اعتبار و هزینه بازارگاه به‌عنوان تراکنش‌های نسخه‌کنترل‌شده و آماده هوش مصنوعی که واقعاً می‌توانید حسابرسی کنید ثبت می‌شود. رایگان شروع کنید و دفاتر اقتصاد عامل خود را به‌اندازه سرورتان قابل برنامه‌ریزی نگه دارید.
