Nếu dịch vụ hoặc đại lý của bạn đã tự động hóa công việc với X (trước đây là Twitter), năm 2026 đã viết lại quy tắc hai lần. Vào tháng 2, nền tảng đã chính thức đóng cửa gói API miễn phí và chuyển các nhà phát triển mới sang thanh toán theo từng lần sử dụng. Vào tháng 4, tất cả các gói tự phục vụ đã loại bỏ các điểm cuối viết cho đăng ký, thích và trích dẫn - giờ đây chúng chỉ tồn tại trong các hợp đồng Enterprise, bắt đầu từ khoảng 42.000 đô la mỗi tháng. Và vào tháng 5, nền tảng đã cắt giảm giới hạn ở cấp tài khoản: hồ sơ chưa xác minh chỉ đăng tải 50 bài viết gốc mỗi ngày thay vì 2400 như trước đây.
Tiếp theo là phân tích những gì thực sự còn lại, chi phí cho các hoạt động, giới hạn nào bạn sẽ gặp phải đầu tiên và nơi nào proxy thực sự giải quyết vấn đề, còn nơi nào không làm thay đổi giới hạn.
Những gì đã bị loại bỏ và khi nào
Chương trình thay đổi trông như sau:
- Tháng 2 năm 2026 - gói miễn phí đã bị ngừng. Mô hình mặc định cho các nhà phát triển mới là trả tiền theo từng lần sử dụng, thanh toán cho các hoạt động thực tế.
- Tháng 4 năm 2026 - các điểm cuối theo dõi, thích và trích dẫn đã bị loại bỏ khỏi tất cả các gói tự phục vụ. Chúng đã được loại bỏ khỏi cấp miễn phí sớm hơn, nhưng giờ đây con đường đến chúng chỉ có qua Enterprise.
- Tháng 6 năm 2026 - gói legacy Basic với giá 200 đô la mỗi tháng đã chuyển sang mô hình thanh toán theo từng lần; không mở đăng ký mới cho Basic và Pro, các tài khoản cũ tiếp tục sử dụng quyền truy cập.
- Tháng 5 năm 2026 - giới hạn đã giảm ở cấp tài khoản, và chúng là chung cho API, web và ứng dụng di động.
Kết luận thực tiễn từ khối đầu tiên: bất kỳ sản phẩm nào được xây dựng xung quanh việc đăng ký tự động, tự động thích hoặc trích dẫn bài viết của người khác đều đã mất con đường tự phục vụ hợp pháp. Không phải là đắt hơn - mà là đã mất. Sự khác biệt là nguyên tắc: tăng giá có thể được điều chỉnh bằng ngân sách, nhưng việc thiếu điểm cuối không thể được khắc phục bằng bất kỳ điều gì khác ngoài hợp đồng Enterprise.
Những gì còn lại với thanh toán theo từng lần
Tự phục vụ hôm nay bao gồm bốn nhóm hoạt động: đăng bài, đọc bài và dòng thời gian, trả lời trong khoảng thời gian hạn chế và tin nhắn cá nhân cho những người đã đồng ý nhận. Giá cho các hoạt động:
- 0,015 $ - bài viết văn bản thông thường.
- 0,20 $ - bài viết có chứa liên kết. Sự khác biệt lớn hơn ba lần, và đây là điểm bị đánh giá thấp nhất trong tính toán ngân sách.
- 0,005 $ - đọc một bài viết, với giới hạn 2 triệu lượt đọc mỗi tháng.
Streaming và tìm kiếm toàn văn theo mô hình thanh toán theo từng lần không có sẵn - đây là lãnh thổ của Pro (cho những ai còn lại) và Enterprise. Gói legacy Basic cung cấp khoảng 50.000 bản ghi và 10-15 nghìn lượt đọc mỗi tháng với khoảng thời gian tìm kiếm là bảy ngày; Pro với giá 5000 đô la - khoảng 300.000 bản ghi và một triệu lượt đọc với lưu trữ và streaming.
Hãy tính toán kịch bản của bạn trước. Một đại lý nội dung, đăng 30 bài viết có liên kết mỗi ngày trên 20 tài khoản khách hàng, chỉ chi cho việc đăng bài 120 đô la mỗi ngày - 3600 đô la mỗi tháng. Cùng khối lượng mà không có liên kết trong nội dung bài viết - 270 đô la mỗi tháng. Cấu trúc đăng bài ở đây ảnh hưởng đến hóa đơn mạnh mẽ hơn là lựa chọn gói.
Hai bức tường khác nhau: giới hạn ứng dụng và giới hạn tài khoản
Đây là nơi thường xảy ra sai lầm. Trong X có hai giới hạn độc lập, và chúng được tính toán theo các thực thể khác nhau.
Đầu tiên - giới hạn ứng dụng và token. Đây là các giới hạn tần suất cổ điển của các điểm cuối trong các khoảng thời gian trượt:
- tìm kiếm bài viết mới - 300 yêu cầu cho mỗi người dùng trong 15 phút và 450 cho ứng dụng;
- tạo bài viết - 100 cho mỗi người dùng trong 15 phút và 10.000 cho ứng dụng mỗi ngày;
- đọc dòng thời gian - 900 cho mỗi người dùng trong 15 phút;
- xóa bài viết - 50 cho mỗi người dùng trong 15 phút;
- tin nhắn cá nhân - tối đa 1440 mỗi ngày cho mỗi tài khoản.
Cửa sổ bắt đầu từ yêu cầu đầu tiên, không phải từ mốc giờ tròn. Khi vượt quá, sẽ có HTTP 429 với mã lỗi 88, và trong tiêu đề x-rate-limit-reset có chứa Unix-timestamp của thời điểm đặt lại. Đây là tín hiệu duy nhất chính xác khi bạn có thể lặp lại yêu cầu: các lần thử mù với khoảng thời gian cố định chỉ tiêu tốn hạn ngạch và kéo dài thời gian bị chặn.
Thứ hai - giới hạn của chính tài khoản. Từ tháng 5 năm 2026, hồ sơ chưa xác minh bị giới hạn khoảng 50 bài viết gốc, 200 câu trả lời, 400 lượt theo dõi và 500 tin nhắn cá nhân mỗi ngày. Điều quan trọng: bộ đếm này là chung. Không quan trọng, hành động đến từ API chính thức, từ giao diện web hay từ ứng dụng di động - nó đều rơi vào cùng một giỏ.
Từ đây, có một điều mà ngành công nghiệp proxy không nói đủ lớn: thay đổi IP không làm thay đổi bất kỳ giới hạn nào trong số này. Các giới hạn của các điểm cuối gắn liền với token ứng dụng và ngữ cảnh người dùng, trong khi các giới hạn hành động gắn liền với chính tài khoản. Việc thay đổi địa chỉ sẽ không thêm cho bạn bất kỳ bài viết nào mỗi ngày. Chính xác là kết luận tương tự mà chúng tôi đã phân tích với ví dụ về giới hạn Reddit API và vai trò của proxy vào năm 2026: proxy chịu trách nhiệm cho tính khả dụng và địa lý, chứ không phải cho hạn ngạch.
Nơi nào proxy thực sự cần thiết
Điều này không có nghĩa là proxy không cần thiết trong công việc với X. Chỉ cần nhiệm vụ của chúng khác, và được định hình chính xác:
- Tính khả dụng địa lý và phát hành khu vực. Xu hướng, dòng thời gian địa phương, truy cập vào nền tảng từ các quốc gia nơi nó bị hạn chế. Ở đây, IP thực tế của khu vực cần thiết là quan trọng - proxy cư trú cung cấp địa chỉ của nhà cung cấp dịch vụ Internet thông thường, không khác gì so với lưu lượng của người dùng thực theo ASN.
- Đảm bảo cơ sở hạ tầng. Đại lý quản lý tài khoản của nhiều khách hàng không nên trộn lẫn các phiên của họ trong cùng một ngữ cảnh mạng. Một khách hàng bị hạn chế - những khách hàng khác không nên cảm thấy điều đó. Quy tắc đơn giản, và chúng tôi đã phân tích chi tiết trong tài liệu về nguyên tắc "một proxy - một tài khoản".
- Độ ổn định của kênh. Các nhiệm vụ dài hạn trong việc đọc dòng thời gian thường gặp phải sự cố mạng nhiều hơn là gặp giới hạn. Một kênh riêng biệt với độ trễ dự đoán - điều này có nghĩa là ít lần thử lại và ít hạn ngạch bị tiêu tốn.
- Thực hiện các kịch bản di động. Nếu quy trình phụ thuộc vào hành vi của khách hàng di động, địa chỉ của nhà mạng sẽ trông tự nhiên hơn đối với nền tảng so với địa chỉ của trung tâm dữ liệu. Đối với những nhiệm vụ như vậy, người ta sử dụng proxy di động.
Câu diễn đạt chính xác là: proxy giải quyết vấn đề "bạn đến từ đâu và độ tin cậy của bạn như thế nào", nhưng không phải là vấn đề "bạn được phép thực hiện bao nhiêu hành động". Người bán hứa hẹn điều ngược lại đang bán cho bạn một kỳ vọng sẽ không thành hiện thực.
Những gì không nên làm
Sau những thay đổi vào tháng 4, một số nhóm đang xem xét tự động hóa trình duyệt như một sự thay thế cho các điểm cuối đã đóng. Cần hiểu giá của giải pháp này.
Quy tắc của X yêu cầu thực hiện tất cả các tự động hóa thông qua API chính thức: việc thu thập dữ liệu từ giao diện, tự động hóa trình duyệt và API không chính thức bị cấm theo điều khoản sử dụng. Nền tảng đã kiện các hành vi thu thập dữ liệu từ năm 2023, và vào tháng 3 năm 2026 đã có một làn sóng cấm lớn vì "hành vi không xác thực". Theo ước tính của các chuyên gia, tài khoản được sử dụng để thu thập dữ liệu tự động sống từ ba đến mười bốn ngày trước khi bị chặn - và không có bất kỳ việc thay đổi địa chỉ nào có thể làm tăng thời gian này một cách nguyên tắc, vì quyết định được đưa ra dựa trên các tín hiệu hành vi và dấu vân tay, chứ không chỉ dựa trên IP.
Riêng biệt: xu hướng trong vài tháng gần đây - các nền tảng ngày càng chuyển từ các khối kỹ thuật sang các khối pháp lý. Vào mùa hè năm 2026, X đã yêu cầu đóng cửa các frontend công khai Nitter; chúng tôi đã phân tích điều này trong tài liệu về cách các nền tảng đã thay đổi vũ khí chống lại việc thu thập dữ liệu. Sự sáng tạo về cơ sở hạ tầng không còn là yếu tố rủi ro chính - mà là những bức thư từ các luật sư.
Cách tái cấu trúc công việc: quy trình thực tiễn
- Chia tách các hoạt động thành còn lại và đã mất. Đăng bài, đọc, trả lời và DM - vẫn còn. Theo dõi, thích, trích dẫn - đã chuyển sang Enterprise. Tất cả những gì được xây dựng trên nhóm thứ hai yêu cầu không phải là tối ưu hóa, mà là thay đổi mô hình sản phẩm.
- Tính toán ngân sách theo các hoạt động, không theo gói. Tính riêng các bài viết có liên kết: với 0,20 $ mỗi bài, việc đưa liên kết vào câu trả lời đầu tiên thay vì nội dung bài viết sẽ thay đổi hóa đơn hàng tháng một cách đáng kể.
- Đặt giới hạn tốc độ riêng của bạn. Token bucket ở phía bạn, được cấu hình thấp hơn một chút so với các giới hạn chính thức, rẻ hơn so với việc nhận 429 và xử lý hậu quả. Điều chỉnh lưu lượng đầu ra trước, thay vì dừng lại khi từ chối xảy ra.
- Xử lý 429 theo tiêu đề, không theo bộ đếm thời gian. Đọc x-rate-limit-reset và chờ đúng đến thời điểm được chỉ định.
- Phân tách khách hàng theo các ngữ cảnh mạng khác nhau. Một proxy riêng và một bộ thông tin đăng nhập riêng cho mỗi tài khoản - là quy tắc cơ bản giúp hạn chế phạm vi ảnh hưởng trong bất kỳ giới hạn nào.
- Theo dõi các giới hạn cấp tài khoản riêng biệt với các giới hạn API. Chúng được tính cùng với các hành động thủ công của chuyên gia SMM. Nếu người đó đăng bài bằng tay từ ứng dụng, bộ lập lịch của bạn sẽ nhận được ít hơn những gì đã dự kiến.
Kết luận
Năm 2026 đã biến X từ một nền tảng với API giá rẻ thành một nền tảng với tính phí theo từng lần và phân chia nghiêm ngặt: các hành động hàng loạt để thu hút chỉ có sẵn cho các hợp đồng doanh nghiệp, mọi thứ khác - đều phải trả tiền và trong các khuôn khổ hẹp. Đối với hầu hết các nhóm, phản ứng đúng là không tìm kiếm các con đường vòng, mà là tái cấu trúc quy trình theo bộ hoạt động còn lại, tính toán chi phí theo các hoạt động và hạn chế lưu lượng của chính mình trước.
Proxy trong sơ đồ này vẫn là một công cụ cần thiết nhưng được xác định rõ ràng: chúng cung cấp địa lý, độ tin cậy của kênh và sự cách ly giữa các tài khoản khách hàng. Nếu bạn cần chính hiệu ứng này - địa chỉ cư trú của ProxyCove với thanh toán theo lưu lượng sẽ giải quyết nhiệm vụ mà không có phí thuê cho các cổng không hoạt động. Nếu ai đó hứa hẹn với bạn về việc vượt qua hạn ngạch - tốt hơn là đọc lại phần về hai giới hạn một lần nữa.