The open network deserves a real queue.
Bluesky has no scheduler of any kind, and the drafts it added in 2026 sit on one device with no publish time attached. This page documents what a Bluesky post really is underneath: an AT Protocol record capped at 300 graphemes, with byte-range facets that decide whether your links are clickable. Bluesky sits on the OctoSpark build list rather than in the product.
- 300 graphemes, not 300 characters, plus a separate 3,000-byte ceiling
- Links and hashtags only work when a client computes byte-offset facets
- Bluesky is on the build list and is not connectable in OctoSpark yet
Bluesky publishing is not built yet. Everything below is about how Bluesky itself works, and telling us you want it is what moves it up the queue.
The honest answer
Does Bluesky have a built-in scheduler?
No. Bluesky ships no scheduling of any kind. The 2026 composer added drafts, but they sit on the device that wrote them and carry no timer. Every post is published the moment you press the button, so anything queued in advance comes from a third-party client built on the AT Protocol.
Nowhere in the product. The bsky.app composer offers a Drafts button in the top right and a Post button beside it, with no date field anywhere between them, and the iOS and Android composers match it exactly.
There is no schedule control to find
Bluesky has never shipped a delayed-publish option on web, iOS, or Android. Scheduling has been an open feature request since the invite-code era and remains one. Every post goes live the instant you press Post, which is why every guide to scheduling on this network hands you straight to a third-party client.
Drafts arrived, a queue did not
Drafts landed in 2026 as one of the most requested additions to the app. A draft holds an unfinished post so you can come back to it, and that is the entire feature. There is no publish time, no ordering, and no notion of a post waiting its turn.
Drafts live only on the device that wrote them
Bluesky keeps drafts locally rather than in your repository on the server, so something started in the phone composer is not waiting for you on desktop. Third-party clients vary in whether they show them at all, because a local draft is an app convenience rather than part of the protocol.
The 300 cap counts graphemes, and bytes underneath
A post stops at 300 graphemes rather than 300 characters, so a family emoji assembled from several code points costs you one and not seven. A second ceiling of 3,000 raw UTF-8 bytes sits below it, which emoji-dense or non-Latin drafts can reach first. Links, mentions, and hashtags all spend from the same 300.
Links do not turn themselves into links
The protocol does not auto-detect a URL sitting in your text. A post record carries a facets array naming the UTF-8 byte range each link, mention, and hashtag covers. A client that computes those offsets from UTF-16 string indices publishes posts whose links are inert or highlight the wrong span of text.
App passwords are a blunt instrument
The legacy way a third-party tool posts for you is an app password, a revocable string carrying nearly the whole authority of your account. It cannot delete or migrate the account, and it cannot mint further app passwords, but beyond a checkbox governing direct-message access it is not scoped to posting.
Write limits are points, not post counts
The network meters writes on a budget of 5,000 points per hour and 35,000 per day, where creating a record costs three points, updating costs two, and deleting costs one. That lands around 1,666 new records an hour: invisible to a person, and a genuine ceiling for a bulk import of back catalogue.
Images and video cannot share a post
One post carries either up to four stills at 2MB each, raised from 1MB during 2026, or exactly one MP4 up to 100MB and roughly three minutes, extended from the original sixty seconds. There is no mixed attachment, and Bluesky-hosted accounts must verify their email before a first video upload.
Bluesky on its own vs OctoSpark.
| Capability | Bluesky natively | OctoSpark |
|---|---|---|
| Publishing at a chosen time | The composer publishes immediately. No date field exists on web, iOS, or Android, so a timed post is not something the app can express. | When Bluesky scheduling lands, a post will sit on the same calendar as every other connected channel and fire at the minute you set, through the queue that already runs today. |
| Where an unpublished post waits | In a drafts list stored on the device that wrote it, which does not follow you from phone to laptop. | Drafts will be held server-side against the workspace, so a post begun on a phone will be the post you finish on a desktop, and a colleague will be able to pick it up mid-sentence. |
| Counting toward the 300 limit | The official composer counts graphemes as you type and refuses to post past 300, without ever explaining what a grapheme is. | The counter will be taught the grapheme rule and the 3,000-byte ceiling sitting under it, rather than counting UTF-16 units and letting an emoji-heavy draft fail at the API instead of in the editor. |
| Making links and hashtags clickable | The Bluesky app computes facets invisibly on your behalf, which is why nobody using it knows the array exists. | Facet ranges will be derived from the UTF-8 bytes at publish time, so a link typed into a draft weeks earlier will still cover exactly the right span when the post finally goes out. |
| Publishing a reply chain | You post, wait for it to land, then reply to yourself, one step at a time, live and in order. | A chain will be queued as a single item, each step carrying both the root and the parent reference the protocol demands, taken from the URIs returned by the steps published before it. |
| Authorising a third-party tool | An app password generated under Privacy and Security, pasted into whatever tool asked for it, carrying near-total account authority. | We will build against AT Protocol OAuth, which Bluesky has told developers to adopt for new projects, and keep app passwords as a fallback for hosts that have not implemented the server side yet. |
| Staying inside the write budget | The points budget is invisible in the app, because a human tapping Post will never come close to spending it. | The publisher will pace writes against the 5,000-point hourly allowance the way it already paces other providers, so a large backfill will slow itself down rather than accumulate rejected calls. |
| Where your account is actually hosted | The app talks to whichever personal data server holds your repository, including one you run on your own hardware. | The host will be a field on the connection rather than a hardcoded bsky.social, because an account on a self-hosted server is the same protocol and has to work the same way. |
| Scheduling from an agent or a script | Anything programmatic means writing against the XRPC endpoints yourself, handling sessions, facets, and blob uploads by hand. | Bluesky will surface as one more account id on the existing CLI, REST, and MCP layer, so an agent already filling your queue will pick the channel up without learning a new verb. |
What you can schedule on Bluesky.
Text post
PlannedThe base unit of the network: a record holding up to 300 graphemes of text, a creation timestamp, an optional language tag, and the facet ranges that make any link or tag inside it live rather than decorative.
Planned as the first shape to ship. Text plus a scheduled time needs the least new product surface, and the genuine work sits in the grapheme counter and the facet computation rather than in the post call itself.
Image post
PlannedUp to four stills on one post, each under 2MB, in jpeg, png, gif, or webp. Alt text is set per image and is unusually well adopted on Bluesky compared with most networks.
Planned. Images are written to your own personal data server as blobs before the post record references them, which is a different two-step shape from the upload pipelines already built and will need a path of its own.
Video post
PlannedA single MP4 up to 100MB and around three minutes. It cannot share a post with stills, Bluesky-hosted accounts must verify their email before the first upload, and there is a daily ceiling per account measured in both clips and gigabytes.
Planned, and sequenced behind the image path. A per-day ceiling of that shape is exactly the kind of limit a scheduler has to model up front, rather than discover when a queued post fails at publish time.
Quote post
PlannedA post embedding another post by its URI and its content hash, so the original renders inside yours. Because the embed points at an immutable hash, a quote is a reference to a specific version rather than a copy of the text.
Planned. Storing a quote target against a scheduled post is trivial; resolving the URI and the content hash at publish time rather than at compose time is the part that has to be got right.
Reply thread
PlannedA run of posts where every reply carries two references: root, pointing at the head of the thread, and parent, pointing at the post immediately above it. Both are mandatory, which is what lets any client on the network reconstruct the thread.
Planned. Chained publishing already exists here for other networks, so the Bluesky-specific work is carrying two references forward through the chain instead of the single parent reference other platforms need.
Which Bluesky accounts work.
Bluesky-hosted account
The default arrangement, where your repository lives on Bluesky's own servers behind a bsky.social handle. Connecting one would take either an app password generated under Privacy and Security or an OAuth grant against that host. Neither flow is built, so nothing can be connected right now.
Account on a self-hosted personal data server
Running your own server is a first-class path on the AT Protocol rather than a workaround, so a connection flow has to ask which host to authenticate against instead of assuming one. That host-resolution step does not exist in the product yet.
Custom domain handle
A handle can be a domain you own, proven by a DNS TXT record or a file served from a well-known path. The handle is only a pointer: the stable identity underneath is a decentralised identifier, and that is what a durable connection would have to store.
Shared brand account
Bluesky has no seat model, no page object, and no delegated roles, so a brand account is simply an account several people can sign into. Team roles and approval gates would come from OctoSpark, which is the half of this that already works for the channels publishing today.
What supporting Bluesky would take
- A decision on authentication first. AT Protocol OAuth is what Bluesky has directed developers toward for new projects and is where we would start, with app passwords kept as a fallback for hosts that have not caught up.
- The host to authenticate against. Anyone can run a personal data server, so the connect form has to ask where your repository actually lives rather than quietly assuming bsky.social.
- Your decentralised identifier, not just your handle. Handles are domains and can be changed or moved; the identifier underneath does not change, so it is the value a lasting connection keys on.
- A registered OAuth client with published client metadata. The atproto profile expects a metadata document any server can fetch, which is closer to standing up a public identity than to pasting an API key into a settings page.
- A blob upload step before the post is created. Images and video are written into your repository first and referenced by the record afterwards, so the media pipeline has to be pointed at your server rather than at ours.
How to schedule a Bluesky post.
- 1
Pick how the tool will authenticate
Every Bluesky scheduler posts as you, using either an app password or an AT Protocol OAuth grant. App passwords are created under Settings, then Privacy and Security, and can be revoked one at a time. Leave the direct-message checkbox off unless the tool genuinely needs to read your DMs.
- 2
Write to 300 graphemes, then check the bytes
The cap is 300 graphemes rather than characters, so a compound emoji costs one and an accented letter costs one. A second ceiling of 3,000 raw UTF-8 bytes sits underneath and emoji-dense or non-Latin drafts can meet it first. Links, mentions, and hashtags all draw on the same allowance.
- 3
Build the post as a record, facets included
Scheduling here means writing a post record into your repository at the chosen moment. Text alone is not enough: the facets array must name the UTF-8 byte range of every link, mention, and tag, or they publish as plain inert text. Replies additionally carry both a root and a parent reference.
- 4
Pace the queue against the write budget
Writes are metered in points rather than post counts, at 5,000 an hour and 35,000 a day, with each record creation costing three. A person will never notice this. Importing a year of archived content will, so a queue that spaces its writes finishes and one that fires everything at once collects errors.
Agent native
Schedule Bluesky from your terminal, an MCP client, or any agent.
That account id does not resolve to anything yet. It is the shape support will take when it arrives, and the useful observation is how little of it is Bluesky-specific: the id changes and the rest is identical to the channels publishing now. Facets, blob uploads, and the root-and-parent references a chain needs will all be assembled server-side, so an agent will never have to know what a lexicon is.
octospark posts schedule pst_9f42 --account-id acct_bluesky_main --at 2026-12-04T09:15:00Z --dry-runSchedulers for other platforms.
Twitter post scheduler
Yes. Twitter/X has a free scheduler inside the web composer at x.com: pick a date and time, and the post waits in Unsent posts.
Read moreInstagram post scheduler
Yes, in two places. Any public Instagram account can toggle Schedule this post inside the app, up to 75 days ahead and 25 a day.
Read moreLinkedIn post scheduler
Yes. LinkedIn has a free native scheduler built into the post composer: click the clock icon, pick a date and time within the next three months, and the post publishes itself.
Read moreFeatures behind the Bluesky scheduler
- the networks wired up right nowBluesky is not among them. This is the honest current roster and the bar a new network clears before it joins.
- the CLI and MCP layer a new channel inheritsScheduling verbs here are provider-agnostic, so a network becomes agent-schedulable on the day its adapter lands rather than months later.
- drafting against a hard ceilingThree hundred graphemes is a real constraint, and a model told the limit in advance beats one whose output gets truncated at publish.
Bluesky scheduling, answered.
No, and it never has. There is no delayed-publish control on web, iOS, or Android, and adding drafts in 2026 did not change that, because a draft carries no date. Anything queued ahead of time on this network is going through a third-party client written against the AT Protocol.
300, counted in graphemes rather than characters, so a compound emoji built from several code points costs exactly one. A separate ceiling of 3,000 raw UTF-8 bytes sits beneath it and is usually only met by emoji-dense or non-Latin text. Links, mentions, and hashtags all count toward the 300.
The AT Protocol is the open protocol Bluesky is built on. Your posts are records in a repository you own, held on a personal data server and addressed by a portable identifier. Bluesky is one application on that network rather than the network itself, which is precisely why anyone can write a client.
Yes, and unusually openly. The write endpoints are the same ones the official app calls. There is no partner programme, no application review, and no paid access tier standing between a developer and a working client. Authorisation is the only real gate, which is rare among major networks.
Most tools ask for one today. You generate it under Settings, then Privacy and Security, and you can revoke each one individually. Bluesky has told developers to build against AT Protocol OAuth for new projects instead, so expect app passwords to become the fallback rather than the default path.
Not natively, since there is no scheduler to do it with. Structurally a thread is clear enough: every reply record carries a root reference to the head of the thread and a parent reference to the post above it, and a tool has to supply both using values it only learns as the chain publishes.
Yes. The XRPC endpoints and lexicon schemas are published openly at docs.bsky.app, and they are the same interfaces the first-party app uses. Set against the review queues and paid tiers guarding most social APIs, this is the least gated posting surface of any large network.
Yes, expressed in points rather than requests. You have 5,000 points an hour and 35,000 a day, where creating a record costs three, updating costs two, and deleting costs one. That is roughly 1,666 new posts an hour: far beyond human use, and squarely where a bulk importer lands.
Only through a third-party tool that supports video. A post takes one MP4 up to 100MB and around three minutes, extended from the original sixty seconds, and it cannot also carry stills. Accounts hosted by Bluesky must verify their email first, and a per-day ceiling applies to every account.
It does now. Drafts shipped in 2026 and live behind a button at the top right of the composer. The catch is that they are stored on the device that wrote them, so a draft begun on your phone is not sitting in the desktop composer, and no draft carries a publish time.
It should, and it is a fair thing to ask any tool before you pay for it. Hosting your own personal data server is a supported path on this protocol, and a client that hardcodes bsky.social as the host will simply fail to authenticate an account that lives somewhere else.
No. Bluesky is on the build list and is not in the product: no adapter, no AT Protocol client, and no Bluesky account type you could connect. We would rather write that plainly than display a logo we cannot stand behind. When it does arrive it will use the same queue, calendar, and agent surface as the channels shipping now.