What happened
A commit to OpenAI’s public OpenAPI repository on October 29, 2026 adds an experimental configuration surface named time_awareness to agent configurations. The boolean controls whether a model receives periodic current-time reminders. In the creation parameter schema, it defaults to false; builders must therefore opt in rather than assume that an agent has current-time grounding.
The change introduces an ExperimentalConfigParam object with time_awareness as its currently defined property. It also adds an effective-settings resource representation, where time_awareness is required, and exposes that representation through an experimental field on agent configuration resources. The schema describes these as experimental settings for an agent, which is an important limitation: this is a published interface change, not a promise of a stable long-term product contract.
The setting is not limited to an initial configuration. OpenAI also adds an overrides object for session-level agent configuration. Its time_awareness property can be omitted to retain the current setting. The session configuration describes experimental settings as merging by key, rather than replacing the complete object. In practical terms, a client can patch one experimental setting without having to resend every other experimental setting that might be added later.
The commit also changes the general description of session agent configuration to make that exception explicit. Omitted fields continue to inherit from an agent_id when one is supplied; supplied objects and arrays ordinarily replace the entire field; nullable fields can be reset with null. Experimental settings are the exception because they merge by key. The same public schema change places the experimental settings on agent creation, agent update, session configuration, and agent-detail responses.
This does not create a general clock API, a scheduler, or evidence that every agent should enable the setting. It creates a vendor-managed way for an OpenAI-hosted agent configuration to choose periodic temporal reminders. For an application that previously inserted timestamps into instructions or session messages, the relevant new question is whether to move that behavior into the configuration layer—and how that experimental behavior performs in its own workflows.
The public source is OpenAI’s OpenAPI-specification commit.
What the archive adds
This is a new fact in an active OpenAI Agents API story, rather than a restatement. The API documentation previously described pre-warmed OpenAI-hosted sandboxes, separating environment readiness from the moment a request begins. It subsequently added Scheduled Automations with cron and one-time runs. Time awareness adds another operational attribute to the configuration surface: how an agent is grounded while it runs.
Trend signal
This is a small supporting signal for Harness architecture outlives model choice. The meaningful change is not a new model capability; it is a configurable behavior in the agent runtime around the model. One experimental boolean is not enough to establish a durable platform direction, but it reinforces the distinction between selecting a model and defining the operating conditions in which it works.
Why it matters
Time is often implicit in an agent application even when the model has no dependable view of wall-clock time. A team may put a timestamp in the system prompt, append it to every turn, or build its own session middleware. OpenAI’s new option turns one version of that problem into a hosted configuration choice for users of this API.
That can reduce application-level prompt plumbing, but it also moves behavior into a setting that must be represented in deployment configuration, tests, and change management. Because session overrides merge by key, clients that update agent settings should distinguish the experimental object from ordinary nested objects: partial experimental updates have different semantics. Teams should treat that difference as an implementation detail to test, not as a reason to assume every nested configuration is patchable.
The more consequential lesson is architectural. Long-running agent behavior depends on operational context—time, environment readiness, scheduling, state, and tool access—not solely on a model identifier or a carefully written instruction. Configuring those conditions explicitly gives builders something observable to review and reproduce.
Limits and uncertainty
The source is a specification commit, not a product announcement, implementation guide, benchmark, or pricing page. It does not establish which models receive reminders, how frequently reminders arrive, their exact wording, whether they consume tokens, whether they are available in every account or region, or their effect on task quality. It also does not say when, or whether, the experimental setting will become stable.
Nor does the schema show whether time awareness improves planning, deadlines, scheduled work, or merely reduces obvious date-and-time mistakes. Builders should not infer availability beyond the published interface, a performance gain, or an SLA from this change alone.
Skill to build now
Add a compact configuration test for temporal assumptions in any long-running agent you operate. Run the same task with time_awareness disabled and enabled, then inspect whether the agent handles time-sensitive instructions differently and whether that difference is desirable. Store the setting alongside the agent version and session configuration. If your client updates settings, test that a partial experimental update preserves the other experimental keys, because that merge behavior differs from the replacement behavior described for ordinary supplied objects.
Reader takeaway
OpenAI’s Agents API schema now has an experimental switch for periodic current-time reminders, defaulting to off. The immediate value is modest, but the design is notable: temporal grounding is becoming a configurable runtime concern, and experimental settings have distinct patch semantics that API clients should test.
Open question
Will OpenAI document reminder cadence, model coverage, token effects, and availability before treating time_awareness as a stable Agents API capability?