In a post on X, @chetaslua reports that a dots feature observed in a September 26 ChatGPT build appears under several internal names, including orbit, aeon and possibly o. The same report points to a workspace setting called orbit_enabled, a relationship between orbitId and aeon_id, and an access response named orbit_access_denied.

These references suggest that the labels may be connected in the client code, but they do not establish what dots does for users, whether it is publicly available or whether customers can use it. No official OpenAI announcement or product documentation is supplied here.

What the report identifies

The report is based on strings and code references observed in one ChatGPT build rather than on a documented product announcement. Its useful contribution is showing how several identifiers appear to fit together:

  • The screenshot shows a workspace setting labelled “Allow members to use dots.”

  • That setting reportedly maps to orbit_enabled.

  • The client reportedly assigns orbitId from aeon_id.

  • A request to /cloud-aeons/by-thread/{thread_id} can reportedly produce a 403 response containing orbit_access_denied.

  • One key in the dots-related block reportedly remains named settings.o.

Image shared by @chetaslua on X
Image shared by @chetaslua on X

Image credit: @chetaslua on X

The relationships are evidence about how that particular build was structured. They are not confirmation that dots, orbit and aeon are official public names for exactly the same feature in every context.

The clearest naming observation is that the build reportedly contains references to orbit and aeon alongside the user-facing “dots” label. The post also describes o as a possible additional internal name, based partly on a remaining settings.o key.

That last reference is less conclusive. A short internal key can be a leftover name, a local implementation detail or a label used for a related object. The available evidence does not explain whether o is an alias for dots, a separate setting or an unfinished naming artifact.

The supplied screenshot appears to show additional Enterprise-related configuration, including availableForEnterprise:!0, an “Enable dots?” confirmation and text describing dots as being in beta and not currently supporting data residency or Enterprise Key Management. Those code strings and messages are evidence of material present in the build, not proof that a user could access the feature or that a functioning rollout was underway.

The reported Enterprise setting

The screenshot shows a workspace setting labelled “Allow members to use dots.” The associated setting name is orbit_enabled.

The screenshot also includes a default message saying “Dots are not available for this workspace.” Because this appears as code text rather than a reported runtime result, it does not show whether the feature was unavailable in the reporter’s workspace.

Together with the Enterprise availability flag visible in the supplied screenshot, this indicates that the build contained workspace and Enterprise-related controls connected to the dots-labelled code path. It does not show that the feature was enabled for Enterprise customers, that the setting worked for every workspace or that Enterprise users could access a completed product. The source does not provide a reproducible test of the toggle or an official explanation of its intended behavior.

How aeon_id and orbitId are reportedly connected

The report says the client sets orbitId from aeon_id. In practical terms, that suggests the client may use an identifier returned or stored as aeon_id when making later requests that expect an orbitId.

That is a code-level relationship, not proof that the two names represent separate user-visible objects or that they identify the same feature in all parts of ChatGPT. The supplied evidence does not document where the identifier originates, how long it remains valid or what users would do with it.

What orbit_access_denied indicates

The reported request path /cloud-aeons/by-thread/{thread_id} can reportedly return HTTP 403 with an orbit_access_denied response. A 403 generally represents a refusal to authorize a request, but this observation alone does not reveal why access was refused.

Possible explanations could include workspace configuration, account permissions, rollout controls or an unavailable internal service, but the source does not distinguish among them. The response therefore indicates that the code accounts for an access-denied condition; it does not prove that dots is available behind the endpoint or that the endpoint can be independently reproduced.

What remains unknown

The report and supplied screenshot do not establish:

  • what dots is designed to do for ChatGPT users;

  • whether dots, orbit or aeon is an official product name;

  • whether the feature is publicly available or still under development;

  • whether the Enterprise-related flag corresponds to access for actual Enterprise customers;

  • whether the reported endpoint behavior can be reproduced; or

  • whether o is a true alias, a separate internal key or leftover code.

The screenshot does provide Enterprise availability signals and beta-related limitation text, but those strings do not confirm a functioning rollout or user access. For now, the strongest supported conclusion is narrower: one September 26 ChatGPT build reportedly contained a dots-labelled workspace setting and several related internal references, including orbit_enabled, aeon_id, orbitId and orbit_access_denied. Those references make the implementation appear connected, but they do not yet explain the feature’s user-facing purpose or availability.

Sources