Can we get exact numbers for these rate limits? "low", "medium", "high", and "very high" aren't very useful in the context of me trying to figure out if I should drop everything I am doing and allocate the next week to implementing OAuth 2.0 support for my bots and other hobby projects. One thing I will say about this change is that while I do completely understand that there is a need to cut down bot traffic to our servers, a change that involves rate-limiting contributor workflows, especially those who are performing (often) load-bearing moderation tasks, does not feel like a good way forward. Also, implementing OAuth 2.0 (and subsequently getting it approved) for support is non-trivial, especially for "home-grown" bots. Absent any evidence that community-run "home-grown" bots are the root of this problem, I feel like asking them to implement such a solution is counterproductive in this context.
A few points wrt to some other parts of the announcement:

Otherwise, authenticating using session cookies or OAuth 2.0 will grant a higher limit.
What about bot passwords (and OAuth 1.0a, as other folks have asked)? Note that adding OAuth 2.0 support is currently a significant burden compared to simply providing a proper UserAgent (which was the previous policy). I don't even know how I would implement OAuth 2.0 support for my Go bot (and random Python script) without spending a non-trivial amount of time reviewing the associated documentation.

Request the bot flag from your local wiki community
To my knowledge, this is also not a trivial process in many communities (e.g., enwiki). If I need to start a month-long (or more) discussion just to retrieve (say) the data for all recently reverted edits to perform my own analysis and/or make 1000 edits using Pywikibot, I feel like a contributor might ask/feel: "Will it be easier to just not do this task?"

Use Wikimedia Enterprise APIs for high-volume usage
This is the part I'm extremely uncomfortable with. I feel very strongly that community members who are contributing in mission-aligned ways should not be asked to shift to use a closed-source, monetary contributions-gated, out-of-date version of our own data that they have spent hours curating. I feel this is a very clear line in the sand: community members should NOT have to pay (i.e., buy/sign up for an Enterprise subscription) to access Wikimedia data. If we ever end up in a scenario where a contributor feels compelled to pay for a Wikimedia Enterprise account, we have done something seriously wrong. (The only caveat to that statement is if we have a contributor who founds an AI startup/Google alternative, or similar)

Regards,
Sohom Datta
---
Open-source contributor @Wikimedia

On Mon, Mar 2, 2026 at 12:25 PM Jonathan Tweed via Wikitech-l <wikitech-l@lists.wikimedia.org> wrote:
On Mon, 2 Mar 2026 at 16:52, Roy Smith <roy@panix.com> wrote:
>
> Why 2.0?  All of my OAuth consumers use 1.0a.  Will I need to generate new consumer keys?

This is primarily because OAuth 2.0 uses access tokens that are
formatted as JWTs, which we can validate extremely efficiently in
services outside of MediaWiki. That means we can use authentication as
a signal in abuse detection at the CDN without affecting performance,
likewise using it to apply global API rate limits in an API gateway
that sits in front of all MediaWiki instances.

If tools are running on WMCS, this will exempt you from the limits
even when using OAuth 1.0.

For tools outside WMCS, OAuth 1.0 consumers will work as long as you
also send cookies as this will include a JWT cookie in the request
that we can validate in place of an OAuth 2.0 access token.

If neither of these are possible, then yes, it would make sense to
generate new OAuth 2.0 clients.

Best
Jonathan
_______________________________________________
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/