So rechnen Sie das Bluesky-API-Rate-Limit in Posts pro Stunde um

Was ist das Bluesky-API-Rate-Limit?

Jedes Bluesky-API-Rate-Limit, das Schreibvorgänge regelt, wird in Punkten statt in Anfragen bemessen: Ein Bluesky-PDS gibt jedem Konto 5.000 Punkte pro Stunde und 35.000 Punkte pro Tag, und ein CREATE kostet 3 Punkte, ein UPDATE 2 Punkte und ein DELETE 1 Punkt. Anfragen, die ein Limit überschreiten, erhalten eine HTTP 429 Antwort.

Fast jede andere Social-API zählt Aufrufe. Bluesky zählt die Datensatzoperationen innerhalb dieser Aufrufe, summiert sie pro Konto (pro DID, nicht pro App-Passwort oder pro Token) und legt das Punktebudget über ein separates HTTP-Anfragebudget. Die offizielle Seite zu Rate-Limits sagt es direkt: „These limits are on top of any related HTTP API requests."

Die Punktekosten, direkt aus der Dokumentation:

Die Dokumentation rechnet das für genau einen Fall in Datensätze um, für Likes, und hört dann auf. Der Rest der Rechnung steht weiter unten.

Wie viele Posts pro Stunde schafft ein Bluesky-Konto?

Ein Konto kann 1.666 Datensätze pro Stunde und 11.666 Datensätze pro Tag anlegen, und ein Bluesky-Post ist ein Datensatz. Teilen Sie das Budget durch die Kosten:

Die CREATE-Zahlen werden abgerundet und lassen jede Stunde zwei Punkte liegen, denn 5.000 geteilt durch 3 ergibt 1.666,67 und 35.000 geteilt durch 3 ergibt 11.666,67. Die Dokumentation nennt 1.666 und 11.666, was dazu passt.

Bündeln hilft bei den Punkten nicht. Ein einzelner Aufruf von com.atproto.repo.applyWrites kann viele Datensatz-Schreibvorgänge tragen, und die Dokumentation ist eindeutig, dass die Limits „sum up all of those individual record writes." Wobei Bündeln hilft, ist das Anfragebudget, dazu weiter unten mehr.

Ein Post, ein Like, ein Repost und ein Follow kosten alle dieselben 3 Punkte. Die Datensatz-Collections heißen app.bsky.feed.post, app.bsky.feed.like, app.bsky.feed.repost und app.bsky.graph.follow, und das Budget unterscheidet nicht zwischen ihnen, also schöpfen ein Follow-Bot und ein Posting-Bot aus demselben Topf.

Warum entspricht das Tageslimit nur sieben Stunden des Stundenlimits?

Die Tagesobergrenze von 35.000 Punkten ist exakt das Siebenfache der Stundenobergrenze von 5.000, also erschöpfen sieben Stunden im Vollgas den ganzen Tag. Die Dokumentationsseite sagt das nirgends, und es ist das Nützlichste, was Sie wissen sollten, bevor Sie einen Scheduler schreiben.

Wäre die Stundenobergrenze die einzige Beschränkung, erlaubte ein Tag 5.000 mal 24, also 120.000 Punkte. Die Tagesobergrenze liegt bei 29 Prozent davon. Die Stundenobergrenze ist ein Burst-Kontingent, die Tagesobergrenze ist das echte Budget.

Die tragfähige Rate ist das, worauf es bei allem ankommt, was dauerhaft läuft:

Diese letzte Zeile ist die Zahl, um die herum Sie entwerfen sollten. 11.666 Creates über 1.440 Minuten sind 8,1 pro Minute, ein Schreibvorgang alle 7,4 Sekunden. Ein Worker, der schneller läuft, borgt sich Budget aus dem späteren Tagesverlauf, und ein Worker an der Stundenobergrenze ist ab Stunde acht pleite.

Was kostet ein Thread, eine Bearbeitung oder ein gelöschter Post wirklich?

Ein Thread kostet 3 Punkte pro Post darin, weil jeder Post in einem Thread ein eigener Datensatz ist. An der Antwortstruktur ist nichts gratis. Hier die Rechnung für die Schreibmuster, die Leute tatsächlich fahren:

Bilder und Videos verändern die Anfragezahl, nicht die Punktzahl. Einen Blob über com.atproto.repo.uploadBlob hochzuladen ist kein Datensatz-Schreibvorgang und kostet daher null Punkte: Ein Post mit vier Bildern sind fünf HTTP-Anfragen und 3 Punkte. Größenlimits für Blobs und die Grenze von 300 Graphemen im Posttext sind eigene Themen, und keines davon berührt das Schreibbudget.

Welches Limit greift zuerst, das Punktebudget oder das Anfragebudget?

Bei einem einzelnen Konto greift das Punktebudget zuerst, und bei einer Flotte von Konten hinter einer IP greift das Anfragebudget zuerst. Bluesky wendet beides gleichzeitig an: 3.000 Anfragen pro fünf Minuten gemessen pro IP, über alle Endpunkte hinweg, und das Punktebudget gemessen pro Konto.

Rechnen Sie das Anfragelimit in dieselben Einheiten um. 3.000 pro fünf Minuten sind 600 pro Minute und 36.000 pro Stunde. Ein Konto, das mit Vollgas schreibt, schafft 1.666 Creates pro Stunde, ein Zwanzigstel des IP-Kontingents, also sieht ein einzelner Bot das IP-Limit nie.

Stellen Sie jetzt mehrere Konten hinter eine IP. Gleichmäßig verteilt macht ein Konto an seiner Stundenobergrenze 1.666 geteilt durch 12, also 138,8 Schreibanfragen pro Fünf-Minuten-Fenster. Teilen Sie 3.000 durch 138,8, und Sie bekommen 21,6. Einundzwanzig Konten passen mit 2.915 Anfragen unter die IP-Obergrenze, das zweiundzwanzigste überschreitet sie mit 3.054. Dieser Kipppunkt ist nirgends veröffentlicht, und er ist der Grund, warum sich Multi-Konto-Automatisierung von einem Server anders verhält als derselbe Code auf einem Konto. Die Dokumentation sagt nicht, wie die beiden Budgets zusammenspielen, wenn sie kollidieren, nur dass es beide gibt.

Welche Login-Limits gibt es, und warum greifen sie vor den Schreiblimits?

com.atproto.server.createSession ist auf 30 pro 5 Minuten und 300 pro Tag pro Konto gedeckelt, was 39 mal strenger ist als das Schreibbudget, das dahinter liegt. Eine Automatisierung, die sich für jeden Post frisch einloggt, hat eine echte Obergrenze von 300 Posts pro Tag, nicht 11.666, denn 11.666 geteilt durch 300 ergibt 38,9.

Der vollständige Satz an Konto- und Identitätslimits aus der Dokumentation:

Fehlgeschlagene Logins werden separat und viel härter gemessen, und die Dokumentation erwähnt das überhaupt nicht. Am 10. September 2026 lieferte eine com.atproto.server.createSession Anfrage an bsky.social mit ungültigen Zugangsdaten zurück:

HTTP/2 401
ratelimit-limit: 10
ratelimit-remaining: 9
ratelimit-policy: 10;w=86400
 
{"error":"AuthenticationRequired","message":"Invalid identifier or password"}

Zwei weitere Fehlversuche senkten ratelimit-remaining auf 8 und dann 7, der Zähler ist also live. Ein Fenster von 86.400 Sekunden sind 24 Stunden: zehn falsche Passwörter am Tag, gegenüber einem dokumentierten createSession-Kontingent von 300. Verbrennen Sie zehn Versuche beim Debuggen eines App-Passworts, und Sie sind bis zum Reset-Zeitstempel von diesem Endpunkt ausgesperrt, ohne eine Seite in der Dokumentation, die erklärt, warum.

Die Dokumentation veröffentlicht auch kein Limit für com.atproto.server.refreshSession, den Endpunkt, den ein wohlerzogener Client statt createSession ansprechen sollte. Speichern Sie das Refresh-Token, erneuern Sie die Session, und die Obergrenze von 300 pro Tag hört auf, Ihre Beschränkung zu sein.

Welche Rate-Limit-Header sendet Bluesky tatsächlich?

Antworten eines Bluesky-PDS tragen vier Header: ratelimit-limit, ratelimit-remaining, ratelimit-reset und ratelimit-policy. Die Seite zu Rate-Limits nennt sie nie beim Namen und sagt nur: „Many HTTP API services return rate limit headers on responses. Developers can use those to debug and understand the current limits, or even automate request throughput and backoff." Die atproto-XRPC-Spezifikation nennt einen Header, Retry-After, und das nur als optionale Beigabe zu einem 429.

Hier eine echte Antwort. Ein com.atproto.server.describeServer Aufruf an bsky.social lieferte am 10. September 2026 zurück:

HTTP/2 200
ratelimit-limit: 3000
ratelimit-remaining: 2999
ratelimit-reset: 1789052966
ratelimit-policy: 3000;w=300

ratelimit-policy: 3000;w=300 ist die dokumentierte Grenze von 3.000 pro 5 Minuten, geschrieben als Limit und Fenster in Sekunden, was die veröffentlichte Zahl vom Server selbst bestätigt. ratelimit-reset ist ein Unix-Zeitstempel, keine Anzahl von Wartesekunden, warten Sie also bis zu diesem Moment, statt für seinen Wert zu schlafen.

Dieselbe Prüfung gegen public.api.bsky.app lieferte gar keine ratelimit- Header, passend dazu, dass die Dokumentation diese Endpunkte „generous" nennt, ohne eine Zahl zu veröffentlichen. Das Punktebudget taucht ebenfalls in keinem Header auf, da es nicht an einen einzelnen Endpunkt gebunden ist. Sie müssen es selbst mitzählen.

Gelten diese Limits für jedes Bluesky-Konto?

Sie gelten für Konten auf PDS-Instanzen, die Bluesky selbst betreibt. Die Dokumentation ist hier sorgfältig: „Bluesky is built on top of an open network (atproto), and other providers in the network are likely to have different rate-limits." Ein selbst gehostetes PDS setzt seine eigenen Zahlen, und das Bluesky-Relay legt föderierenden Servern eine separate Obergrenze auf, bei 50 Repository-Stream-Events pro Sekunde, 2.600 pro Stunde und 21.000 pro Tag.

Die Dokumentation schließt mit „All of the limits described here are likely to evolve over time. Hopefully upwards!" Behandeln Sie jede Zahl hier als Messwert vom 10. September 2026 und lesen Sie die Header zur Laufzeit, statt die Konstanten fest zu verdrahten. Beachten Sie außerdem, dass docs.bsky.app inzwischen einen 301 auf bsky.network ausgibt und den Pfad dabei beibehält, sodass die aktuelle Adresse der durchgehend zitierten Seite https://bsky.network/docs/rate-limits lautet.

Was bedeutet das, wenn Sie Bluesky-Posts über ein Tool planen?

Planungstools stehen unter demselben Budget wie jeder andere Client, weil die Limits zu Bluesky und zum Konto gehören. Eine Warteschlange geplanter Posts gibt 3 Punkte pro Post aus demselben Kontingent von 35.000 pro Tag aus, aus dem auch Ihre manuellen Likes und Follows schöpfen. Was ein Scheduler ändert, ist die Form der Ausgabe: Posts, die auf einem Kalender liegen, gehen zeitlich verteilt raus statt im Burst, was Sie unter der tragfähigen Rate hält statt an der Stundenrate. AdaptlyPost übernimmt die Bluesky-Postplanung zusammen mit Massenplanung und einem Content-Kalender und liest die Leistung über Bluesky-Analytics zurück. Denselben Beitrag über Multi-Konto-Posting in mehrere Netzwerke zu veröffentlichen, kostet auf der Bluesky-Seite trotzdem 3 Punkte, einmal, weil es ein Datensatz ist.

Häufig gestellte Fragen

Wie viele Posts kann ein Bluesky-Konto pro Tag absetzen?

11.666 Posts pro Tag, aus einem Tagesbudget von 35.000 Punkten bei 3 Punkten pro CREATE. Gleichmäßig über 24 Stunden verteilt sind das 486 Posts pro Stunde, also einer alle 7,4 Sekunden. Die Stundenobergrenze von 1.666 Posts ist ein Burst-Kontingent, und sie sieben Mal auszureizen erschöpft den Tag.

Zählt ein Like gegen dasselbe Bluesky-Rate-Limit wie ein Post?

Ja. Ein Like erzeugt einen app.bsky.feed.like Datensatz, also ein CREATE im Wert von 3 Punkten, genau wie ein Post. Posts, Likes, Reposts und Follows schöpfen alle aus demselben Stundenbudget von 5.000 Punkten pro Konto.

Welchen HTTP-Status gibt Bluesky zurück, wenn ein Rate-Limit überschritten wird?

HTTP 429, in der Dokumentation beschrieben als „Too Many Requests." Die atproto-XRPC-Spezifikation sagt, bei einer 429-Antwort „may be a Retry-After header indicating a specific back-off time period." Prüfen Sie an PDS-Endpunkten ratelimit-reset für den Unix-Zeitstempel, an dem sich das Fenster leert.

Warum schlägt mein Bluesky-Login schon nach wenigen falschen Passwörtern fehl?

Fehlgeschlagene com.atproto.server.createSession Aufrufe an bsky.social liefern ratelimit-policy: 10;w=86400 zurück, also 10 Versuche pro 24 Stunden, mit dem Fehlertext {"error":"AuthenticationRequired","message":"Invalid identifier or password"}. Dieses Limit steht nicht auf der Seite zu Rate-Limits. Die dokumentierten 30 pro 5 Minuten und 300 pro Tag gelten für erfolgreiche Sessions.

Spart das Bündeln von Schreibvorgängen mit applyWrites Rate-Limit-Budget?

Es spart HTTP-Anfragen, keine Punkte. Die Dokumentation hält fest, dass com.atproto.repo.applyWrites „can write to many records in a single API call" und dass die Limits „sum up all of those individual record writes." Fünfundzwanzig Creates in einem Aufruf kosten 75 Punkte und eine Anfrage.

Gelten Bluesky-Rate-Limits auch für selbst gehostete PDS-Server?

Die veröffentlichten Zahlen gelten für PDS-Instanzen, die Bluesky selbst betreibt. Andere Anbieter im atproto-Netz setzen ihre eigenen, in den Worten der Dokumentation „likely to have different rate-limits." Das Bluesky-Relay legt jedem föderierenden PDS sehr wohl eine eigene Obergrenze auf, bei 50 Repository-Stream-Events pro Sekunde, 2.600 pro Stunde und 21.000 pro Tag, dazu maximal 100 Konten und standardmäßig 5 erstellte pro Sekunde.

Wie viele Bluesky-Konten können sich eine IP-Adresse teilen, bevor sie an das Anfragelimit stoßen?

Einundzwanzig Konten, die von einer IP aus mit voller Stundenobergrenze schreiben, bleiben unter dem Limit von 3.000 Anfragen pro fünf Minuten, bei 2.915 Anfragen. Ein zweiundzwanzigstes Konto überschreitet es, bei 3.054. Dieser Übergang zeigt sich erst, wenn mehrere Konten sich einen Server teilen, denn ein einzelnes Konto nutzt 139 der 3.000 Anfragen.

Kostet das Hochladen von Bildern oder Videos auf Bluesky Punkte aus dem Budget?

Das Hochladen eines Blobs über com.atproto.repo.uploadBlob kostet null Punkte, da es kein Schreiben eines Records ist. Ein Post mit vier Bildern kostet 3 Punkte für den Post-Record und braucht zusätzlich vier HTTP-Anfragen, eine pro Bild, macht insgesamt fünf Anfragen. Das Punktebudget erfasst nur CREATE, UPDATE und DELETE auf Records, keine Blob-Uploads.

Was sagt der Header ratelimit-reset eigentlich aus?

ratelimit-reset ist ein Unix-Zeitstempel, der angibt, wann das aktuelle Fenster endet, keine Sekundenzahl zum Warten. Eine Antwort von com.atproto.server.describeServer am 10. September 2026 lieferte ratelimit-reset: 1789052966 zusammen mit ratelimit-limit: 3000 und ratelimit-remaining: 2999. Warten Sie bis zu diesem Zeitpunkt, statt die Rohzahl als Sekunden zu verschlafen, und beachten Sie, dass der Retry-After-Header aus der atproto-Spezifikation ein eigenes, optionales Feld ist, das nur bei einer 429 mitgeschickt wird.

Wie oft kann ich meinen Bluesky-Handle ändern, ohne ein Rate-Limit zu treffen?

com.atproto.identity.updateHandle ist pro Konto auf 10 Änderungen pro 5 Minuten und 50 pro Tag begrenzt. Das ist deutlich enger als die 300-pro-Tag-Grenze von createSession, weshalb ein Skript, das Handles nach Zeitplan umbenennt, dieses Limit lange vor dem Schreibbudget erreicht.