کدلپر | مرجع مهندسی نرم‌افزار، توسعه و فناوری

یه حقیقت ساده از همون اول: اگه شش ماه پیش لینوکس نصب کردی روی یه ماشین معمولی، احتمالاً الان روی Wayland هستی — حتی اگه ندونی. Fedora 40+، Ubuntu 24.04+، Arch، GNOME 49، و KDE Plasma 6 همه به‌صورت پیش‌فرض به Wayland رفتن. این دیگه یه بحث «آینده‌ی Linux» نیست. این وضعیت الان هست.

سوال واقعی اینه که چرا این اتفاق افتاد، چه چیزی هنوز نشکسته، و چه کسی نباید عجله کنه.

X11 چه مشکلی داشت

X11 در ۱۹۸۴ طراحی شد — و معماریش دقیقاً همون‌قدر که از اون زمان انتظار داری، قدیمیه.

مدل کار اینه که یه X server مرکزی وجود داره. هر برنامه برای رندر کردن چیزی به صفحه، یه درخواست می‌فرسته به X server، X server اون رو به compositor می‌ده، compositor نهایی می‌کنه. مشکل اینه که این X server مرکزی همه چیز رو می‌بینه: هر کیبورد فشرده‌شده، هر حرکت ماوس، هر پنجره‌ای که بازه. هر اپلیکیشن هم می‌تونه از X server بخواد ورودی اپ‌های دیگه رو بخونه. یعنی keylogger نوشتن روی X11 یه کار ده خطیه.

اوایل ۲۰۲۵ سه آسیب‌پذیری بحرانی (CVE-2025-62229، CVE-2025-62230، CVE-2025-62231) توی X.Org پیدا شد — باگ‌هایی که بعضی‌هاشون از بیست سال پیش توی کد بودن. اینا isolated incident نبودن؛ نشونه‌ی یه codebase چهل‌ساله‌ان که maintenance-only شده. هیچ توسعه‌ی فعالی روی X.Org اتفاق نمی‌افته — فقط security patch.

مشکل معماری دیگه‌ای هم وجود داره: رندرینگ کند. هر frame باید از برنامه به X server و بعد به compositor بره — این double-buffering بی‌دلیل توی hardware مدرن کاملاً غیرضروریه و توی بعضی حالت‌ها باعث tearing می‌شه.

Wayland چطور متفاوته

Wayland یه «سرور» مرکزی نداره. هر اپلیکیشن مستقیم به یه off-screen buffer رندر می‌کنه، و compositor مستقیم با driver کار می‌کنه تا frame نهایی رو به مانیتور بفرسته. واسطه نیست.

نتیجه‌های عملی این معماری:

امنیت: هر اپلیکیشن فقط ورودی‌های خودش رو می‌بینه. keylogger نوشتن روی Wayland از طریق protocol عملاً غیرممکنه. البته XWayland — که X11 appها رو روی Wayland اجرا می‌کنه — همچنان این ایزوله‌سازی رو نداره، ولی native Wayland appها ندارن.

رندر تمیزتر: چون compositor مستقیم با GPU کار می‌کنه، screen tearing توی حالت‌های معمولی اتفاق نمی‌افته. توی سیستم‌های با refresh rate بالا یا HiDPI این فرق محسوسه.

نه یه display server، بلکه یه protocol: این نکته مهمه. Wayland خودش یه نرم‌افزار نیست — یه spec هست. GNOME با Mutter، KDE با KWin، Hyprland، Sway — هر کدوم پیاده‌سازی جدا دارن. این یعنی تجربه‌ی Wayland از یه compositor به compositor دیگه می‌تونه فرق کنه.

وضعیت واقعی ۲۰۲۶

اگه از GNOME یا KDE Plasma استفاده می‌کنی، Wayland الان default هست و برای اکثر کارها بدون دردسر کار می‌کنه. طبق یه survey از ۳۹۲۳ کاربر Arch در ژانویه ۲۰۲۵، ۸۰ درصد روی Wayland بودن. GNOME از نسخه‌ی ۴۹ (۲۰۲۵) X11 session رو کاملاً حذف کرده. KDE Plasma 6.8 که اواخر ۲۰۲۶ یا ۲۰۲۷ میاد هم همین کار رو خواهد کرد.

NVIDIA که قبلاً مشکل‌سازترین قسمت بود، با driver series 495+ وضعش خیلی بهتر شده. اکثر کاربران NVIDIA الان می‌تونن Wayland رو بدون دردسر زیادی اجرا کنن — ولی اگه GPU قدیمیه (GTX 1000 series و قدیمی‌تر)، ممکنه همچنان مشکل داشته باشی.

چه کسی نباید عجله کنه

Wayland برای همه مناسب نیست — حداقل نه الان:

اگه از SSH X forwarding (ssh -X یا ssh -Y) برای باز کردن GUI برنامه‌های remote استفاده می‌کنی، Wayland این رو natively پشتیبانی نمی‌کنه. باید از راه‌حل‌های دیگه مثل RDP یا VNC استفاده کنی.

اگه از ابزارهای automation روی desktop استفاده می‌کنی — xdotool، wmctrl، AutoKey — اینا روی Wayland کار نمی‌کنن چون Wayland به appها اجازه نمی‌ده ورودی سیستمیک simulate کنن.

اگه از window manager های سبک مثل i3، openbox، یا fluxbox استفاده می‌کنی، نسخه‌های Wayland بعضی‌هاشون بالغ نیستن. Sway جایگزین i3 روی Wayland هست، ولی feature parity کامل نداره.

اگه از VNC برای remote desktop استفاده می‌کنی، X11 network transparency همچنان این use case رو راحت‌تر می‌کنه.

setup چقدر سخته

برای کاربر معمولی با GNOME یا KDE، عملاً هیچ setup ای لازم نیست — چون اگه لینوکس مدرن نصب کردی، احتمالاً از قبل روی Wayland هستی. چک کردنش ساده‌ست:

echo $XDG_SESSION_TYPE   # باید "wayland" برگردونه

اگه X11 هست و می‌خوای Wayland امتحان کنی، توی login screen (GDM یا SDDM) می‌تونی session نوع رو عوض کنی — بدون نیاز به نصب چیزی. بعد از login کافیه echo $XDG_SESSION_TYPE بزنی و ببینی.

اگه بخوای برگردی، همون راه رو از login screen برعکس کن.

X11 appها چی می‌شن

اکثر X11 appها روی Wayland از طریق XWayland کار می‌کنن — یه X server که به‌عنوان یه Wayland client اجرا می‌شه. در عمل، بیشتر برنامه‌ها بدون تغییر کار می‌کنن. محدودیت‌ها از همون security model میان: appهایی که global pointer position یا synthetic input نیاز دارن زیر XWayland هم مشکل دارن.

جمع‌بندی واقع‌بینانه

Wayland برای اکثر کاربران لینوکس دسکتاپ الان انتخاب بهتریه — نه چون X11 خراب شده، بلکه چون Wayland معماری تمیزتر، امنیت ساختاری بهتر، و پشتیبانی از display مدرن (HiDPI، variable refresh rate) رو از اساس حل می‌کنه.

ولی اگه workflow ات به X forwarding، GUI automation، یا window manager هایی که Wayland equivalent ندارن وابسته‌ست، X11 هنوز گزینه‌ی درست‌تره. و این انتخاب هیچ ایرادی نداره — هر دو همزمان در دسترسند و X11 حداقل تا ۲۰۲۸ patch خواهد خورد.

npm 12 اومد — سه تغییری که ممکنه build‌ رو خراب کنه

اگه توی تیمت کسی هست که هنوز از git+https://github.com/... توی package.json استفاده می‌کنه، یا یه package داری که موقع install یه native build می‌زنه، این مقاله برای اون آدمه. npm 12 توی جولای ۲۰۲۶ منتشر می‌شه — pre-release از ۱۹ ژوئن بیرون اومده — و سه breaking change داره که هر سه‌شون می‌تونن یه CI pipeline رو بی‌سروصدا خاموش کنن.

زمینه‌ی این تغییرات مهمه: یه سال حمله‌ی supply chain. سپتامبر ۲۰۲۵، اتکرها ۱۸ package معروف از جمله debug و chalk رو hijack کردن — packageهایی که هفته‌ای ۲.۶ میلیارد بار دانلود می‌شن. مارس ۲۰۲۶، کتابخونه‌ی Axios از طریق credential دزدیده‌شده compromise شد. ژوئن ۲۰۲۶، یه کِرم به اسم Miasma 57 package رو توی دو ساعت آلوده کرد. همه‌ی این حمله‌ها از یه مکانیزم استفاده کردن که npm از ده سال پیش داشت: هر package می‌تونست موقع install کد دلخواه اجرا کنه، بدون هیچ اجازه‌ی صریحی.

npm 12 این رو عوض می‌کنه.

تغییر اول: install scripts دیگه خودکار اجرا نمی‌شن

این مهم‌ترین و شکننده‌ترین تغییره. تا الان وقتی npm install می‌زدی، هر package ای می‌تونست preinstall، install، و postinstall اجرا کنه — بدون اینکه بدانی. از npm 12، این scriptها به‌طور پیش‌فرض block می‌شن مگه اینکه صریح approve‌شون کرده باشی.

چیزی که خیلی‌ها نمی‌دونن: این شامل native addon ها هم می‌شه. اگه یه package یه فایل binding.gyp داشته باشه، npm قبلاً به‌طور خودکار node-gyp rebuild رو می‌زد — حتی بدون هیچ install script صریحی. این همون مکانیزمی بود که Phantom Gyp attack ازش سوءاستفاده کرد: یه binding.gyp صد و پنجاه‌وهفت بایتی داخل یه package آلوده، و npm خودش کد مخرب رو compile و اجرا می‌کرد. npm 12 این رو هم block می‌کنه.

برای دیدن اینکه الان کدوم packageها script دارن:

npm approve-scripts --allow-scripts-pending

این دستور لیست می‌ده بدون اینکه چیزی رو approve کنه. بعد از اینکه تیکرهایی که بهشون اعتماد داری رو approve کردی:

npm approve-scripts <package-name>

این approve به package.json commit می‌شه — یعنی می‌تونی توی PR review کنی و ببینی چه packageای اجرای script گرفته.

یه edge case مهم: npm rebuild هم subject to این block هست. اگه یه package توی allowlist نباشه، npm rebuild <package> بی‌سروصدا skip می‌کنه. راه‌حل:

npm approve-scripts <package>
npm rebuild <package>

تغییر دوم: Git dependency ها block می‌شن

اگه توی package.json ات چنین چیزی داری:

"some-lib": "git+https://github.com/org/repo.git"

از npm 12 این کار نمی‌کنه مگه اینکه --allow-git استفاده کنی.

این تغییر از فوریه ۲۰۲۶ اعلام شده بود. دلیلش اینه که یه Git dependency می‌تونه یه .npmrc داخل خودش داشته باشه که مسیر اجرایی git رو override کنه — حتی وقتی --ignore-scripts هم گذاشته باشی. خیلی از تیم‌ها فکر می‌کردن --ignore-scripts محافظشون می‌کنه، ولی این attack vector کاملاً جدا بود.

اگه از Git dependency برای یه package داخلی استفاده می‌کنی، بهترین راه اینه که به یه registry مایگریت کنی — GitHub Packages، Nexus، یا Artifactory. اضافه کردن --allow-git به هر CI script، مشکل رو حل نمی‌کنه، فقط جابه‌جاش می‌کنه.

تغییر سوم: remote URL ها block می‌شن

مشابه Git، اگه package ای داری که از یه URL مستقیم نصب می‌شه:

"internal-tool": "https://cdn.internal.com/packages/tool-1.2.3.tgz"

از npm 12 بدون --allow-remote کار نمی‌کنه.

remote URL ها unverifiable ان — npm نمی‌تونه تضمین کنه که اون tarball دستکاری نشده. حل درست اینه که به یه registry بری که integrity check داره.

چطور الان آماده بشی

npm 11.16.0 آخرین نسخه‌ی stable از 11.x هست. اگه upgrade کنی، همه‌ی این blocking ها به‌صورت warning نشون داده می‌شن — نه error. یعنی می‌تونی قبل از اینکه npm 12 بیاد ببینی چی می‌شکنه:

npm install -g npm@11.16.0
npm install   # warnings نشون می‌ده ولی نمی‌شکنه
npm approve-scripts --allow-scripts-pending   # لیست می‌ده

بعد از اینکه لیست گرفتی، packageهایی رو که بهشون اعتماد داری approve کن و package.json رو commit کن. یه چیزی که نباید بکنی: همه رو با یه flag blanket approve کنی فقط برای اینکه warning‌ها ساکت بشن — این کل هدف تغییر رو از بین می‌بره.

کدوم پروژه‌ها بیشترین ریسک رو دارن

پروژه‌هایی که به احتمال بالا مشکل پیدا می‌کنن:

هر پروژه‌ای که native addon دارد — یعنی packageهایی مثل bcrypt، sharp، canvas، node-sass، یا هر چیزی که به C/C++ compile وابسته‌ست. این packageها برای کار کردن به script اجرا شدن نیاز دارن.

هر پروژه‌ای که Git dependency دارد — معمولاً برای fork های داخلی یا patched نسخه‌ها.

هر پروژه‌ای که از HTTPS tarball برای package های داخلی استفاده می‌کنه.

اگه از هیچ‌کدوم از اینا استفاده نمی‌کنی، احتمالاً npm 12 برات transparent باشه.

یه نکته درباره‌ی پکیج نویس‌ها

اگه خودت package نگهداری می‌کنی که native build داره، بهترین راه اینه که prebuilt binary بشیپ کنی — با ابزارهایی مثل prebuild، prebuildify، یا node-pre-gyp. packageای که install-time compilation نداره، نمی‌تونه از این attack vector استفاده بشه. این یه بهبود بلندمدت هست که ارزش وقت گذاشتن داره.

این بزرگ‌ترین تغییر امنیتی npm در شانزده سال گذشته‌ست. ولی فقط یه تغییر configuration نیست — یه تغییر مدل اعتماده. ده سال بود که هر npm install به‌معنای دادن حق اجرای کد دلخواه به همه‌ی چیزی بود که توی dependency tree ات بود. این پیش‌فرض داشت تغییر می‌کرد — فقط کمی طول کشید.

Hermes Agent: یک agent رایگان که میتونه کارای جالبی انجام بده

یه اعتراف صادقانه قبل از شروع: آنچه روی کاغذ درباره‌ی Hermes Agent نوشته شده — که «به‌طور خودکار یاد می‌گیره» — دقیقاً اون‌طوری که ادعا می‌شه کار نمی‌کنه. skill document می‌سازه، ولی به اون شکل خودکار و بی‌دردسری که تبلیغش می‌شه نیست. این رو از تجربه‌ی مستقیم می‌گم، نه از بنچمارک.

ولی اگه این انتظار رو کنار بذاری و بفهمی که Hermes واقعاً چی هست، یکی از بهترین agentهای open-source ای خواهد بود که امتحان کردی.

واقعیت: چقدر prompting می‌خواد

Hermes بدون توضیح درست کار نمی‌کنه. اگه prompt کوتاه و مبهم بدی، نتیجه متناسبه. ولی اگه یه prompt با جزئیات کافی بدی — دقیقاً مشخص کنی چی می‌خوای، چه محدودیت‌هایی داره، output چه شکلی باشه — آنچه در ادامه انجام می‌ده می‌تونه واقعاً چشم‌گیر باشه. کارهای طولانی، پیچیده، و چندمرحله‌ای که معمولاً agent‌های دیگه یا نصفه رها می‌کنن یا خراب تموم می‌کنن.

این یعنی Hermes «agent برای همه» نیست. agent‌ای است که با یه اپراتور حواس‌جمع، خوب کار می‌کنه.

ترکیب با 9Router: چرا مهمه

جذاب‌ترین بخش ماجرا اینجاست: Hermes با هر OpenAI-compatible endpoint ای کار می‌کنه. یعنی می‌تونی 9Router رو جلوش بذاری و از مدل‌های رایگان یا ارزون استفاده کنی — و Hermes همون کاری رو می‌کنه که با Claude یا GPT-4 انجام می‌داد.

عملاً می‌شه از agentی استفاده کرد که performance‌اش به agentهای گرون نزدیکه، با هزینه‌ای که نزدیک به صفره. این ترکیب رو امتحان کردم و کار می‌کنه.

skill ها: چیزی که واقعاً ارزش داره

یه چیز که در عمل خیلی کاربرد داشت، سیستم skill هست — نه اون چیزی که agent خودش می‌سازه، بلکه skill هایی که خودت با Claude می‌سازی و بهش می‌دی. می‌تونی یه workflow پیچیده رو یه بار به‌درستی توصیف کنی، بذاریش توی یه skill، و بعد هر بار که Hermes به اون task می‌رسه، از همون توصیف استفاده کنه. این‌طوری دیگه لازم نیست هر بار از اول توضیح بدی.

چیزی که کشف کردم: sudo ندید

یه هشدار جدی: دسترسی sudo بهش ندید.

نه به‌خاطر اینکه مشکل امنیتی عجیبی داره — بلکه چون agent وقتی روی یه task پیچیده کار می‌کنه، ممکنه اشتباه کنه. و اگه sudo داشته باشه، اشتباهش می‌تونه جبران‌ناپذیر باشه. از تجربه‌ی مستقیم: یه دیتابیس محلی پاک شد. بعیدترین اتفاق ممکن بود ولی افتاد.

محدود کردن دسترسی‌ها — خصوصاً روی فایل‌سیستم — یه قدم ضروریه نه یه پیشنهاد احتیاطی.

اگر خیلی بیشتر بخواید امنیت رو رعایت کنید میتونید روی یک VM یا VPS رانش کنید و باهاش در ارتباط باشید از جاهایی که ساپورت میکنه (تقریبا همه کاری میشه کرد) ولی شخصا روی سیستمم هست (لینوکس) و تا الان مشکلی نداشتم و مستقیم توی ترمینال باهاش کار میکنم.

چیه و چی نیست

چیه: یه agent محلی قدرتمند برای کارهای پیچیده و طولانی که با راهنمایی درست نتایج خوبی می‌ده. اگه بهش skill های درست بدی و prompt دقیق بنویسی، کارهایی انجام می‌ده که معمولاً از agentهای open-source انتظار نداری. MIT، رایگان، سورس باز.

چی نیست: agent ای که بدون نظارت کار کنه، یا که به‌طور خودکار skill بسازه و بهتر بشه — حداقل نه به اون شکلی که توی marketing claim می‌شه.

مشخصات کلی

Hermes Agent از Nous Research فوریه ۲۰۲۶ منتشر شد و الان روی نسخه‌ی v0.18.2 هست. از یه gateway اجرا می‌شه و می‌تونی از Telegram، Discord، Slack، WhatsApp، Signal، و Email باهاش در ارتباط باشی. با هر provider ای کار می‌کنه — Nous Portal، OpenRouter، Anthropic، OpenAI، یا مدل محلی با Ollama. تا ژوئن ۲۰۲۶ به ۱۸۸ هزار ستاره‌ی GitHub رسیده، NVIDIA هم آن را به‌عنوان runtime مرجع برای Nemotron 3 Ultra انتخاب کرده.

# macOS / Linux
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# یا از طریق pip
pip install hermes-agent && hermes

Desktop app هم برای macOS و Windows مستقیم از سایت قابل دانلود هست.

9Router: وقتی rate limit دیگه نمی‌تونه جلوی کار کردن رو بگیره

یه اتفاق آشناست: وسط یه session طولانی با Claude Code یا Codex، یه پیام می‌بینی که quota تموم شده. نه اینکه کارت تموم شده — quota تموم شده. بعد یا باید صبر کنی تا reset بشه، یا دستی بری سراغ یه provider دیگه، یا tool رو ببندی و بری سراغ یه API key دیگه.

9Router برای همین مشکل ساخته شده. یه gateway محلی که بین ابزار AI تو و بیش از ۶۰ provider قرار می‌گیره، و وقتی یه provider به سقف رسید، خودکار به یه جایگزین می‌ره — بدون اینکه لازم باشه چیزی بزنی یا session رو قطع کنی.

ایده‌ی اصلی: سه tier، یه fallback خودکار

9Router روی یه مدل routing سه‌لایه کار می‌کنه:

Tier 1 — Subscription: اشتراک‌هایی که از قبل داری. Claude Code، OpenAI Codex، GitHub Copilot، Cursor. اگه اشتراک داری، 9Router اول از اینها استفاده می‌کنه.

Tier 2 — Cheap: مدل‌هایی که API key می‌خوان ولی ارزونن. GLM به ازای هر میلیون توکن ۰.۶۰ دلار، MiniMax M2.7 به ازای هر میلیون توکن ۰.۲۰ دلار، Kimi با ۹ دلار در ماه. وقتی Tier 1 تموم شد، اینجا میاد.

Tier 3 — FREE: iFlow، Qwen، Kiro، OpenCode. کاملاً رایگان و بدون محدودیت ثابت. آخرین سنگر.

وقتی quota یه provider در Tier 1 تموم می‌شه، 9Router خودکار به Tier 2 می‌ره. وقتی Tier 2 هم تموم شد، به Tier 3 می‌ره. از نظر tool تو — Cursor، Cline، Claude Code — هیچ اتفاقی نیفتاده. همون endpoint جواب می‌ده.

نصب و راه‌اندازی

npm install -g 9router
9router

همین. یه dashboard محلی باز می‌شه که می‌تونی providerها رو اضافه کنی — OAuth برای اشتراک‌ها، API key برای بقیه. بعد هر tool ای که داری رو به این endpoint اشاره بده:

http://localhost:20128/v1

این endpoint با فرمت OpenAI کاملاً compatible هست، پس هر ابزاری که بتونه با OpenAI کار کنه — Claude Code، Codex، Cursor، Cline، Continue، و بقیه — می‌تونه از همین endpoint استفاده کنه.

راستی اگر فلگ t- رو به 9router پاس بدی میتونی ترمینال رو ببندی و توی بکگراند کارشو میکنه.

چیزهایی که توی مسیر اضافه شدن

Format Translator: اگه یه tool با فرمت OpenAI کار می‌کنه ولی می‌خوای به Anthropic یا Gemini وصل بشی، 9Router فرمت رو وسط راه ترجمه می‌کنه. نیازی نیست tool ات Anthropic Messages format بلد باشه.

Multi-Account: می‌تونی چند حساب از یه provider اضافه کنی و 9Router با round-robin بینشون load balance کنه. اگه یه حساب به محدودیت رسید، خودکار به حساب بعدی می‌ره.

RTK Token Saver: خروجی دستوراتی مثل git diff، grep، find و tree رو قبل از فرستادن به مدل فشرده می‌کنه. ادعای سازنده اینه که ۲۰ تا ۴۰ درصد توکن ورودی کمتر مصرف می‌شه. این به‌صورت پیش‌فرض فعاله و lossless هست.

Caveman Mode: یه system prompt تزریق می‌کنه که جواب‌های مدل رو کوتاه‌تر و متراکم‌تر می‌کنه. پنج سطح شدت داره. اگه با مدل‌هایی کار می‌کنی که verbose جواب می‌دن و می‌خوای توکن خروجی کمتر مصرف بشه، این feature کمک می‌کنه.

MITM Bridge: یه feature پیشرفته‌تر که ترافیک IDEهایی مثل GitHub Copilot، Kiro IDE، یا Antigravity رو intercept می‌کنه و به 9Router هدایت می‌کنه. این یعنی می‌تونی از اشتراک IDE هایی که داری برای call کردن هر backend ای که بخوای استفاده کنی. سازنده خودش تاکید کرده که باید policy هر tool رو بررسی کنی قبل از استفاده.

Cloud Sync + Tunnel: اگه بخوای از جای دیگه‌ای غیر از ماشین محلیت به 9Router دسترسی داشته باشی، یه Cloudflare tunnel می‌تونی راه بندازی.

یه نکته درباره‌ی provider های رایگان

Tier 3 شامل providerهایی مثل iFlow و Kiro می‌شه که «unlimited free» هستن. واقعیت اینه که این‌ها معمولاً quota دارن، ولی reset شون سریع‌تره یا سقفشون بالاتره از providerهای اصلی. اگه روی پروژه‌های سنگین کار می‌کنی، Tier 3 رو آخرین fallback در نظر بگیر، نه ابزار اصلی — چون کیفیت مدل‌های رایگان معمولاً پایین‌تره.

open source و رایگان

9Router با MIT license منتشر شده و سورسش روی GitHub هست. هیچ سرور مرکزی‌ای وجود نداره — همه چیز روی ماشین خودت اجرا می‌شه. پرداختی برای خود 9Router وجود نداره؛ هزینه فقط مربوط به providerهاییه که انتخاب می‌کنی.

برای کسی که چند اشتراک AI مختلف داره و هر ماه بخشی از quota هدر می‌ره، یا کسی که وسط کار به rate limit می‌خوره و باید دستی provider عوض کنه، 9Router یه مشکل واقعی رو حل می‌کنه.