How to Build a Customer Support Chatbot Using OpenAI Dots and FastAPI
How to Build a Customer Support Chatbot Using OpenAI Dots and FastAPI
OpenAI dots is a persistent, user-facing agent product powered by GPT-6 Astra, not a standalone API model, open-weight model, or public model ID. It was introduced at OpenAI DevDay on September 29, 2026, and access is created inside ChatGPT for eligible Pro and Business Premium users, with Enterprise workspaces able to enable a beta. Because there is no documented Dots API endpoint, model ID, or SDK, a FastAPI-based customer support chatbot cannot literally call a dots endpoint. The reproducible path is to build an equivalent durable agent using the Agents API, the Agents SDK, or the Responses API, then wrap it in FastAPI for HTTP transport.
Quick Answer
If you need a customer support chatbot today and you want to align with the architecture OpenAI describes for Dots, build it with three documented layers: a FastAPI HTTP layer for routing and observability, the Agents API quickstart running on gpt-6-astra for orchestration, and hosted tools such as function calling, computer use, and programmatic tool calling for retrieval and ticket actions. Dots itself is not an endpoint you call; it is a product surface for end users, and OpenAI has not published a Dots API waitlist, developer keys, or SDK.
Official Status and Evidence
As of September 30, 2026, the following is documented by OpenAI:
- Dots launched at DevDay on September 29, 2026, per the Axios report.
- One dot is included for eligible Pro and Business Premium accounts; Enterprise, Edu, and Healthcare workspaces can enable the beta when an admin turns it on, per the dots workspace administration article and the getting-started guide.
- Each dot is described as a persistent agent with its own cloud computer and browser, connected tools, recurring work, follow-ups across supported channels, subagent delegation, and a time-budget setting for long-running tasks, per the same getting-started guide.
- OpenAI has not announced a Dots API waitlist, Dots developer keys, a public SDK, or a public model ID named
dots. - OpenAI has not published Dots per-token pricing, future allowance quantities, context window size, rate limits, latency targets, multimodal benchmark scores, hallucination rates, MoE architecture, tokenizer, knowledge cutoff, or a 1M-token context claim.
- Prompt caching, Batch API, Structured Outputs, supervised fine-tuning, and model optimization are OpenAI API platform features, not Dots-specific controls.
What OpenAI Dots Actually Is
Dots is a product layer that pairs the GPT-6 Astra model with a runtime that owns a cloud computer, a browser, persistent memory, connected tools, scheduled work, and subagent delegation. The dots privacy, security, and safety FAQs describe access controls, collaboration connections, local-computer access, and custom rules that admins can configure. The underlying foundation, GPT-6 Astra, is documented in the GPT-6 Astra safety report and Dots appendix. That appendix reports a scope-boundary evaluation and is not a general reasoning, coding, or latency benchmark.
Two design choices matter for support work. First, because Dots are persistent, they survive across sessions and can follow up on supported channels, which is well-suited to ticket lifecycle tasks. Second, the time-budget setting makes long-running investigations possible without keeping a synchronous user request open. Developers building a FastAPI service do not get either property for free; they must implement persistence, scheduling, and budgeting themselves on top of the Agents API.
Documented Dots Capabilities and Access Path
The supported way to use Dots is product access in ChatGPT, not an API call. The getting-started guide describes creating a dot in the desktop or web client and configuring its tools, schedule, and follow-up channels. Plan eligibility is documented for Pro and Business Premium; the official plan documentation does not list ChatGPT Plus as a Dots plan and does not use the legacy Team branding. Enterprise access is a beta permission that is off by default; an admin must enable it, and availability can vary by workspace and rollout geography. Treat any Plus or Team eligibility claim as unverified until OpenAI updates the plan page.
What Remains Undisclosed
OpenAI has not published the following for Dots, and you should not infer them from product behavior or unrelated ChatGPT features:
- Token prices, rate limits, context-window size, Batch API rates, caching rates, or add-on prices.
- SWE-bench scores, TTFT, tokens-per-second, multimodal benchmark scores, hallucination rates, or 10,000-request load tests.
- LoRA support, downloadable weights, quantization formats, VRAM requirements, Vertex AI hosting, or Azure deployment.
- Routing design, active-parameter count, token-pruning mechanism, tokenizer details, knowledge-cutoff date, constrained-decoding control, or self-correction mechanism.
- Independent benchmark numbers from Rewarx or any third party for this article batch.
Where the safety appendix reports numbers, they are limited in scope. The Dots safety appendix notes no severe breach in a cited scope-boundary evaluation, while moderate scope-violation flags rose from 8.6 percent with five intervening tasks to 19.7 percent with ten. Treat these as official safety evaluation results, not overall reliability scores.
Building Equivalent Support Agents with FastAPI and the Agents SDK
Because there is no Dots API, the reproducible pattern is a FastAPI application that talks to the Agents API. The Agents overview and Agents API quickstart document the Codex harness, session management, orchestration, context compaction, and recovery, and the documented quickstart uses gpt-6-astra, not a model named dots. The Agents SDK can use OpenAI-hosted, self-hosted, or no sandbox environments, which matters when support actions touch production systems.
A minimal pattern keeps three responsibilities separate:
- HTTP and policy layer (FastAPI): authentication, rate limiting, PII redaction, audit logging, and a deny-by-default allowlist of tool calls.
- Agent layer (Agents API or Agents SDK): long-running reasoning, tool selection, recovery, and context compaction, priced at the selected model's API rates plus standard tool and sandbox charges.
- Tool layer: documented features such as function calling, computer use, and programmatic tool calling for retrieval-augmented lookup, ticket updates, and refunder or escalation actions.
For predictable I/O, return a JSON Schema with Structured Outputs, but keep server-side validation and retries: no schema system guarantees literal zero failures across refusals, truncation, transport errors, tool errors, or unsupported schema features.
Tooling, Caching, Batch, and Fine-Tuning Caveats
Several platform features are easy to misattribute to Dots. Prompt caching and the Batch API are documented at the platform level, with the Batch API offering asynchronous processing, a 50 percent discount, and a 24-hour turnaround, and caching economics varying by model and cache behavior. Supervised fine-tuning and model optimization are model-specific on the API platform; OpenAI does not document LoRA, downloadable weights, edge quantization, VRAM deployment, Vertex AI hosting, or Azure deployment for Dots. None of these are Dots-specific controls, and current prices and rate limits must be read from the account and current models pages at publication time.
Safety, Scope Boundaries, and Governance
Customer support agents touch accounts, refunds, and personal data, so governance belongs in the architecture, not in a final review. Require least privilege on every tool, explicit approvals for consequential actions such as refunds or account changes, full audit logs of tool calls and arguments, data-governance review of retrieval sources, and incident handling for prompt-injection or tool-abuse cases. Treat the Dots safety appendix as a starting point, not a guarantee: it reports no severe breach in a cited scope-boundary evaluation while showing that moderate scope-violation flags can grow with task depth. Build human-review time and intervention rate into your SOPs, and never route financial, security, compliance, medical, or other high-stakes actions without a human checkpoint.
Evaluation or Implementation Framework
Before promoting any support agent to production, run a reproducible evaluation. The table below maps each claim an article might make to a measurable criterion and the evidence you would need.
| Claim or requirement | Measurable criterion | Evidence required |
|---|---|---|
| Completion quality | Resolved ticket rate, CSAT, escalation rate | Labeled tickets, blind review by two raters, dated samples |
| Tool success | Tool-call success rate, argument validity, schema conformance | Logged tool traces with prompts, dates, and settings |
| Intervention rate | Human takeover percentage, time to first intervention | Production audit logs with timestamps and reason codes |
| Provenance | Citation rate for retrieval answers, refusal accuracy | Grounded-answer eval set with ground-truth sources |
| Latency and throughput | p50 and p95 TTFT, tokens per second, sustained RPS | Load test from a known harness, raw logs, sample size |
| Error rate | 5xx rate, truncation rate, transport errors | Time-windowed error counters with version pinning |
| Cost | Cost per resolved ticket, cache hit rate | Per-request usage logs cross-checked with billing |
| Security boundaries | Prompt-injection success rate, scope-violation rate | Red-team scripts, dated runs, and pass/fail criteria |
| Human-review time | Minutes per approval, reviewer agreement | Time-stamped review records and inter-rater kappa |
Two evaluation gates are non-optional. First, a scope-boundary eval that mirrors the categories in the Dots safety appendix, extended to your tools. Second, a load test that records p50 and p95 TTFT, tokens per second, sustained RPS, and error rate at production-equivalent concurrency; only those numbers justify a latency or cost claim. Anything else is a hypothesis.
FAQ
Is OpenAI dots an API model I can call from FastAPI?
No. OpenAI documents Dots as a user-facing, persistent agent product powered by GPT-6 Astra. There is no documented dots endpoint, model ID, or SDK, and standard OpenAI platform API keys do not unlock one. Use the Agents API or Agents SDK as the developer equivalent, and check the current models page for supported IDs at publication time.
Which ChatGPT plan gets Dots, and is there a Plus option?
Official plan documentation includes Dots for Pro and Business Premium, with Enterprise, Edu, and Healthcare able to try the beta when an admin enables it. The documentation does not list ChatGPT Plus as a Dots plan and does not use the legacy Team branding, so do not infer Plus or legacy Team eligibility from unrelated ChatGPT features. Rollout is gradual and account availability may lag.
How is a Dots-style support agent actually implemented?
A documented pattern uses FastAPI for HTTP transport and policy, the Agents API for orchestration on gpt-6-astra, and documented tools such as function calling, computer use, and programmatic tool calling. Persistence, scheduling, and a time budget must be implemented on top, because the Agents API does not inherit Dots product behavior.
Can I fine-tune Dots or deploy it on Azure or Vertex?
OpenAI has not documented LoRA, downloadable weights, edge quantization, VRAM deployment, Vertex AI hosting, or Azure deployment for Dots. Supervised fine-tuning and model optimization are model-specific platform features, not Dots-specific controls. Treat any deployment claim as unsupported until OpenAI publishes it.
Is the Dots safety appendix a general reliability benchmark?
No. The Dots safety appendix is a scope-boundary evaluation; it reports no severe breach in a cited run while showing moderate scope-violation flags rising from 8.6 percent with five intervening tasks to 19.7 percent with ten. It is not a general reasoning, coding, creative-writing, or latency benchmark, and it should not be extended to unrelated capabilities.
Final Verdict
Treat Dots as a product surface, not an API. The reproducible path to a customer support chatbot is a FastAPI service that wraps the Agents API or Agents SDK, uses documented tools such as function calling and computer use, and is gated by a measurable evaluation framework covering completion quality, tool success, intervention rate, provenance, latency, throughput, error rate, cost, security boundaries, and human-review time. Early public reaction on September 29 to 30, including the Reddit threads on Dots and the DevDay reaction thread, is a dated sample with selection bias and is not a scientific consensus. Anyone building for finance, security, compliance, medical, or other high-stakes support must add human review, least privilege, approvals, audit logs, data-governance review, evals, and incident handling before going to production. This article is published by Rewarx and reflects OpenAI's documentation as of September 30, 2026; it implies no partnership with OpenAI and reports no independent benchmark for this batch.
Primary Sources and Verification Links
- OpenAI GPT-6 Astra safety report and dots appendix
- OpenAI dots workspace administration
- OpenAI dots getting-started guide
- OpenAI dots privacy, security, and safety FAQs
- OpenAI Agents overview
- OpenAI Agents API overview
- OpenAI Agents API quickstart
- OpenAI Agents SDK
- OpenAI function calling
- OpenAI programmatic tool calling
- OpenAI structured outputs
- OpenAI prompt caching
- OpenAI Batch API
- OpenAI computer use
- OpenAI model optimization
- OpenAI supervised fine-tuning
- OpenAI current models
- Axios report from OpenAI DevDay 2026
- Reddit discussion: Was anyone else underwhelmed by DevDay?
- Reddit discussion: OpenAI launches dots
- Rewarx Studio AI
Build Evidence-Checked AI Workflows
Rewarx Insights separates documented product capabilities from implementation patterns, proposed evaluations, and changing platform details. Verify current OpenAI documentation and account controls before production deployment.
Explore Rewarx