While DataMind Oda works, it can receive two small readings about its own situation: a time reading with the current time, the request's time zone and how long has passed since the last step, and a terminal reading that names the tmux session, window and pane Oda's process runs in. Both readings are opt-in context for advanced setups. This page covers what each reading contains, when it is added, and the settings behind it.
web and headless profiles.At each step Oda begins, it can add a reading in three lines:
Time sampled while preparing turn <turn>, step <step>: <timestamp> Browser time zone for this request: <zone-policy>. Elapsed since the preceding <baseline>: <duration-or-unavailable>.
YYYY-MM-DDTHH:MM:SS±HH:MM[Zone], for example 2026-07-15T09:01:01+08:00[Asia/. Times show whole seconds.Elapsed since the preceding model-visible message:), and from the previous reading in the same turn at later steps (Elapsed since the preceding step context:). With no earlier point to measure from, it reads unavailable.1d 1h 1m 1s or 0s, and a clock that moves backwards counts as 0s.Each message can carry the time zone of the app or browser that sent it; Prompts, queue and steering covers that side. For one turn, Oda looks at the messages in it and classifies the zone:
Browser time zone for this request: Europe/Browser time zone for this request: mixed ["America/Browser time zone for this request: unavailable.The zone must be UTC or an IANA name in Area/ form; another spelling is not used as the turn's zone. When the turn has no single zone of its own, the timestamp falls back to the configured timeZone, or to the zone of the computer running Oda when none is set. The fallback only formats the clock: the line still tells Oda to ask about dates and times that come without a zone, rather than to treat the fallback as something you stated.
| Setting | Default | What it does |
|---|---|---|
timeZone | the computer's zone | The zone that formats the timestamp when the turn has no single zone of its own. |
refreshIntervalMs | 0 | The smallest gap between readings, in milliseconds. At 0, a reading is added at every step Oda begins. |
time-context: invalid IANA timeZone "<value>", time-context: refreshIntervalMs must be a non-negative safe integer, got <value>, and, when no zone is set and the computer's own zone cannot be read, time-context: failed to resolve the system time zone.When Oda runs inside tmux, it can add a reading that names where its terminal sits. Oda takes one read-only look at tmux on the first step of a turn, and adds a reading only when the location has changed since the last one; a pane moved or resized mid-turn is reflected in the next turn. An unchanged location adds nothing.
tmux location (turn <turn>): session <session>, window <index> "<name>", pane <index> <pane-id> window active=<0|1>, pane active=<0|1>, layout <window-layout>
tmux location query failed: <message>; injecting no location this turn.| Setting | Default | What it does |
|---|---|---|
refreshIntervalMs | 0 | The smallest gap between readings, in milliseconds. At 0, a reading is added at each turn whose location changed. |
tmux-context: refreshIntervalMs must be a non-negative safe integer, got <value>.At each step Oda begins, unless the step is cancelled before it starts or a refreshIntervalMs interval is still running. With the default 0, a reading is added at every step.
The zone of the request when the turn's messages carry exactly one: the timestamp is formatted in it. When they carry several or none, the line lists them or reads unavailable and asks for clarification, and the timestamp itself is formatted in the fallback zone, the configured timeZone or the computer's zone when none is set.
unavailable mean in a reading?A value with nothing to report: in the elapsed line it means there was no earlier point to measure from, and in the zone line it means the request carried no zone. It is not an error.
No. The reading guides how Oda interprets dates and times in its answers. A tool that requires a zone still needs one stated, and the fallback zone is not treated as something you gave.
As often as every step, by default. A positive refreshIntervalMs sets the smallest gap between readings in one chat, so a reading that falls inside the interval is skipped.
In the profile's configuration: timeZone and refreshIntervalMs for the time reading, and refreshIntervalMs for the terminal reading. These are advanced values; Command line and flags can print the configuration Oda will run.
On the first step of a turn, when Oda runs inside a tmux pane and the location has changed since the last reading. A pane moved or resized during a turn is reflected in the next turn.
Oda counts as inside tmux only when its own terminal is the pane itself. A window started from tmux, such as an editor's integrated terminal, inherits tmux's settings but sits in a different terminal, so a reading adds nothing.
The turn continues normally and no reading is added; Oda notes the warning tmux location query failed: <message>; injecting no location this turn. A failed look is not a failure of your task.
Pixel sizes and what other panes show. The reading carries Oda's own location and the window's pane layout, nothing from around it.
Yes. A reading is context: it is kept with the chat, replays with it, and is condensed by compaction like other recorded material, rather than shown among the message rows. System prompt, context and compaction covers how the chat keeps such records.