Left free to choose, OpenAI's Dots picked Cloudflare 8 of 8

Amplifying gave OpenAI's new Dots agent the same app request eight times and left every technology choice open. All eight builds came back on Cloudflare Workers, Cloudflare D1 and ChatGPT sign-in, and the authors of Amplifying's study say they never saw the agent compare providers.

At a glance

• The test app was a public status dashboard for 12 AI services, from OpenAI and Claude to OpenRouter and Cursor, collecting official status pages every 15 minutes and storing private watchlists.
• ChatGPT Sites supplied hosting, the database binding and sign-in, while Vercel, Neon, Supabase, Clerk and WorkOS scored 0 of 8 as integrations, even though all of them sit in ChatGPT's plugin directory.
• A live URL did not mean a finished app. Runs 3, 5 and 7 shipped with no active scraping schedule, and only Run 4 showed fresh collection while the browser was closed.

If you missed the launch: OpenAI unveiled Dots at DevDay in San Francisco on September 29, 2026. Dots are always-on agents powered by GPT-6 Astra, available to ChatGPT Pro and Business Premium users in eligible markets. In the launch presentation, Sam Altman showed a Dot updating an app and opening 3 GitHub pull requests. Amplifying says its earlier study of Claude Code found that deployment was fully determined by the stack, with Vercel for JavaScript and Railway for Python.

All 8 Dots builds ran on Cloudflare Workers, D1 and ChatGPT sign-in

The prompt asked for a public site anyone could read, plus accounts with private watchlists that survive sign-outs and device changes. It also wanted shared incident history and collection that keeps running after visitors close the page. Framework, hosting, database and authentication were left to Dots. Each run started with a new Dot with memory off, but all runs shared one account, and some Dots still referred to earlier apps.

All 8 projects used React with Vinext and Vite. Cloudflare Workers ran the apps. D1, a hosted database with SQLite semantics, kept incident history and watchlists on the server. ChatGPT Sites handled deployment, the D1 binding and sign-in, so nobody needed a separate Cloudflare login or API token.

Vercel hosting, Neon, Supabase, Clerk and WorkOS each scored 0 of 8 as service integrations. Some exports did carry Vercel's @vercel/og library in their saved lockfiles, pulled in through Vinext. Amplifying points out that a dependency written by Vercel is not evidence of Vercel hosting.

Runs 3, 5 and 7 shipped without an active scraping schedule

Scheduling was where the builds differed most. Five configured a schedule, and every one of them used a separate ChatGPT task to call the app. None set up Vercel Cron or a native Cloudflare Worker cron trigger. In Runs 2 and 4 the task hit a public status endpoint, Runs 6 and 8 called a protected collector with a private server secret, and Run 1 went through an owner-authenticated MCP connection.

Run 3 relied on a refresh button for the administrator. Runs 5 and 7 proposed the MCP route, but the connection was still pending or unconfigured at delivery, and both apps said so on the page. Only Run 4 gave clear evidence of unattended work: 8 sources had new collection timestamps from before the testers reopened the app.

Time to first delivery ranged from 13 to 29 minutes, with a median of 24m44s. Those times include incomplete results and time spent waiting for approvals.

All 8 collectors used hand-written adapters, and Amazon Bedrock stayed a gap

Every exported collector made direct HTTP requests and used its own parsers for Statuspage JSON, RSS feeds and provider-specific HTML or JSON. Amplifying found no integration with a commercial scraping service. Run 1's fetch helper is a typical example. It accepts only HTTPS URLs on a list of 12 approved hosts, gives up after 18 seconds and rejects any response larger than 8,000,000 bytes.

Coverage was uneven. Run 6 collected 10 sources. Run 7 delivered 7, with 4 collectors marked unsupported. Run 8 showed 7 fresh sources, and its export reported that OpenRouter recovered and brought the count to 8. Hosted Mistral collection returned 403 in Run 6 and 401 in Run 8, and Run 8's xAI endpoint returned 404. Amazon Bedrock stayed a gap, with no working collector in Runs 7 and 8.

The plugin directory listed Vercel, Neon, Clerk and WorkOS the whole time

ChatGPT's developer-tools directory has options for every layer of this app. For hosting there are Vercel, Render, Railway and Netlify. For data there are Neon, Supabase, MongoDB Atlas, Firebase and Convex, and for sign-in Auth0, WorkOS, Clerk and Descope. Firecrawl and Olostep handle scraping. AWS Core covers infrastructure for a whole app, and Replit, Lovable, Floot and Base44 build complete apps.

What each listing can actually do varies. Neon and MongoDB Atlas can manage database resources and WorkOS can manage a connected account, while Clerk lists SDK examples and Auth0 provides a skill. Amplifying connected no external services for these builds, and OpenAI's Dots setup guide makes connecting plugins optional.

Sites checks who the user is, and the app only reads the headers

Sign-in happens outside the app's code. ChatGPT Sites authenticates the visitor and passes the result in request headers such as oai-authenticated-user-id and oai-authenticated-user-email. All 8 exports contain the same helper, which reads those headers and returns a user, or nothing if they are missing. The app uses that ID to keep watchlists separate and checks an administrator allowlist before allowing a manual refresh.

Picture an office building where the front desk checks your ID and hands you a badge. The office upstairs reads the badge and trusts the desk. Amplifying makes the same point: reading arbitrary headers would not be safe on its own, and the helper relies on Sites to do the checking.

Scheduling follows the same pattern. A ChatGPT task requests a URL every 15 minutes. The app then decides whether collection is due and uses a database lock so two refreshes cannot overlap. Run 2 used waitUntil() to keep collecting after the response had gone out, while Run 4 waited for collection to finish before replying.

The report admits its limits. The test steps Dots described are its own claims, Run 4's evidence cannot rule out another caller hitting the endpoint, and accuracy across all sources is unverified. In our view, the weak spot of this default stack is the timer: hosting, storage and sign-in come ready-made, yet three of eight builds shipped with no active schedule. Amplifying argues that the setup keeps the customer relationship with OpenAI, which likely makes a directory listing a weak lever for rival vendors.

What would make Dots pick Vercel

Amplifying did not test builds with external plugins connected. It is still an open question whether a connected Vercel, Neon or Clerk account would change what Dots builds on. The study also does not show whether 15-minute collection keeps running over days, since only Run 4 showed unattended work. Amplifying's advice to vendors is that they need to give the agent a reason to use their product when hosting, storage and sign-in are already handled.