Tool catalog and session events

DataMind Oda works by taking steps: it reads files, runs commands, searches the web, delegates to helper agents and more. This page is the reference behind those steps: which tools Oda can use, how a chat is recorded, and the codes and counts a record can carry.

The tools Oda can use

Oda can use a wide set of tools. The list below covers the families common to most chats; how tools are offered to a model and controlled is on Tools and how they are offered.

Files and folders. read and read_image read files and images; write creates files; edit changes them; glob finds files by name; grep searches inside them.
Commands. bash and pwsh run commands in the Bash and PowerShell shells; the rows they leave in a chat are on Commands Oda runs.
Code runs. run_code runs a small program that can call Oda's other tools from inside it.
The web. web_search searches the web; web_fetch opens a page and reads it.
Planning. todo_write keeps a task's to-do list; the goal tools (create_goal, get_goal, update_goal) set and follow a goal over its rounds.
Delegation. subagent and subagent_fork hand part of a task to a helper agent; Delegating work to subagents covers it.
Teams. spawn_teammate starts a teammate; send_message, wait_agent, interrupt_agent and list_agents message, wait for, stop and list teammates; the shared task board uses team_task_create, team_task_list, team_task_get and team_task_update.
Skills. skill loads a skill; skill_create writes one; skill_install installs one from a folder, an archive or a link.
Scheduled tasks. scheduled_task_create, scheduled_task_list, scheduled_task_update, scheduled_task_pause and scheduled_task_delete manage work that runs on a schedule.
Memory. memory_save, memory_list, memory_update and memory_delete keep what Oda remembers between chats.
Earlier chats. session_search looks through your earlier chats on this computer; session_event_search, session_event_read, session_event_trace and session_trace read single chats and their records closely, as Session search and history paging describes.
Workflows. workflow runs a written plan that spreads many small tasks across helper agents in one go.
Questions. ask_user_question asks you a question when Oda needs a decision mid-task.

Which tools a chat actually has depends on its preset: in a preset's Capabilities section, switches such as Read and edit files and Web search and pages turn capabilities on and off (Create a custom preset). The list above is the common set.

Where a tool name can appear

Tool names come from Oda's record, so you may meet them while reading a chat.

A step that cannot be laid out as its usual card falls back to a plain block with the recorded input and output, under the tool's name. Tool calls in the chat covers the cards and the fallback.
Inspect opens the recorded view of a step when one was kept, and it keeps the call's details.
Oda's own log files on this computer keep the original wording of what Oda did. What Oda shows and what its logs keep explains what is reworded and what stays as it is.

How Oda's work is recorded

Every chat is saved on your computer as a record that grows as the chat works. Oda adds each fact as it happens and never rewrites what is already written; opening a chat reads the record and continues it. The shape of the record, its turns and steps, is on Sessions and the transcript.

A record's entry is one fact: a message, an answer, a step starting or ending, a tool call and its result, or a note Oda keeps for itself, such as the instructions it was following.
Some entries make up the conversation: they are what you read in a chat and what the model reads back when the work continues. Others are kept for Oda's own use and never enter the conversation, such as the inner calls a program makes while it runs.
A record entry of a kind this version of Oda does not know stops the chat from opening, unless the entry is marked as safe to ignore. Oda refuses rather than guess; Opening sessions from other versions covers that case.

How the record reaches Oda's parts

Oda is built from parts, and a part can watch the record as it grows. Each fact reaches the watchers in one of three ways:

Announced. The fact goes out to every watcher. None of them can change it, and a watcher that fails is set aside: its failure is logged, and the other watchers and the work carry on.
Passed through. The fact travels from part to part in order, and each part may adjust it before the next part sees it. What comes out of the last step is what the work uses.
Waited on. The parts hear the fact one after another, and the work waits for each of them to finish before the next begins.

The way a fact is shared is fixed by Oda's design, one way per fact, and nothing you set in the app changes it.

The codes in Oda's records

A step's record can carry a short code describing how it ended, and the code stays with the record of that step. You do not need the codes to keep working, but they help when you report a problem: send them exactly as they appear.

Code	What it means
`ABORTED_BEFORE_DISPATCH` (also recorded as `TOOL_ABORTED_BEFORE_DISPATCH`)	The call was stopped before it started, so nothing ran.
`ABORTED` (also recorded as `TOOL_ABORTED`)	The call was stopped after it had started.
`TOOL_NOT_STARTED`	After a crash: a call that had not been recorded as started, so nothing ran; it can be retried if it is still needed.
`TOOL_OUTCOME_UNKNOWN`	After a crash: a call whose result was never saved; Oda cannot tell whether it ran, so it does not repeat it blindly.
`USER_REJECTED`	The call did not run because you rejected it; a note you gave with the rejection stays with it.
`UNKNOWN_TOOL`	The call named a tool this chat cannot use; it fails as an ordinary error, and the task can continue.
`INVALID_ARGS`	The call's arguments were refused before it ran because they did not match the tool's shape.
`INVALID_TOOL_OUTPUT`	The tool's result did not match the shape it declares, so the call failed rather than keeping it.
`CODE_RUN_FAILED`	A code run ended in failure; the record carries the kind of failure and any captured output.
`CONTEXT_LENGTH`	A request went past the window of tokens the model can take at once.
`DATAMIND_<code>`	Refusal codes from your DataMind server; the family includes `DATAMIND_AUTH`, `DATAMIND_FORBIDDEN`, `DATAMIND_AUTH_UNAVAILABLE` and `DATAMIND_RENEWAL_FAILED`.
`TOKEN_EXPIRED`, `TOKEN_INVALID`, `AUTH_REQUIRED`, `IDLE_SESSION_EXPIRED`, `PASSWORD_CHANGED`, `SESSIONS_REVOKED`	The sign-in codes Oda renews for: it renews the sign-in once and tries the request again.

The full story behind stopped work is on Stopping Oda and queued messages, and the repairs after a crash are on Recovering sessions after a crash.

Token counts in a step's record

Every reply Oda records carries its usage: the tokens the model read and the tokens it produced for that step.
Part of what a model reads can come from its own cache rather than being worked through afresh, and Oda records that part separately as cache-read tokens.
Oda keeps the opening of a request stable between the steps of a turn, so from the second request of a turn, the unchanged earlier part is served from the cache.
The chat's own figures, such as decode tokens and timings, are on Chat navigation and stats.

Questions, answered

Which tools can Oda use?

The families common to most chats are listed above: files and folders, commands, code runs, the web, planning, delegation and teams, skills, scheduled tasks, memory, earlier chats, workflows and questions. Which set a chat actually has depends on its preset; see Create a custom preset.

Do all chats have the same tools?

No. A preset decides which capabilities a chat may use, for example through switches such as Read and edit files and Web search and pages, so two chats on two presets can have different sets.

Why does a step show a tool name I do not recognise?

The name is the tool's own name, kept with the record of the step. The list above maps the common names to what they do; when a step cannot be laid out as its usual card, its plain record keeps the name visible too.

What do `ABORTED_BEFORE_DISPATCH` and `ABORTED` mean?

A stopped call that had not started records ABORTED_BEFORE_DISPATCH: nothing ran. A call that had already started records ABORTED. What a stop does to the rest of the work is on Stopping Oda and queued messages.

What does `UNKNOWN_TOOL` mean?

The call named a tool this chat cannot use, so it failed without running, and the task can continue without it. It is ordinary feedback for Oda, not a broken chat.

What does `CONTEXT_LENGTH` mean?

A request needed more than the window of tokens the model can take at once, so it could not be sent as it was. Long chats are handled by summarising older parts, so the work can continue.

What do the `DATAMIND_` codes mean?

They are refusal codes from your DataMind server, covering sign-in and access; the family name is DATAMIND_<code>. A code in the renewing set (TOKEN_EXPIRED, TOKEN_INVALID, AUTH_REQUIRED, IDLE_SESSION_EXPIRED, PASSWORD_CHANGED, SESSIONS_REVOKED) means the sign-in needs renewing: Oda renews it once and tries the request again. If that fails, it says the sign-in could not be renewed and asks you to check the connection to your DataMind server.

What are cache-read tokens?

They are the part of a step's input that the model served from its own cache instead of reading afresh. Oda records them with the step's token counts. Because Oda keeps the opening of each request stable, from the second request of a turn the earlier, unchanged part comes from the cache.

Why does Oda refuse to open a chat with a record it does not know?

So it never guesses at history it cannot read fully. A record entry of a kind this version does not recognise stops the chat from opening, unless the entry is marked as safe to ignore; update DataMind Oda, or open the chat in the version that wrote it. See Opening sessions from other versions.

What happens to old entries when a long chat is summarised?

They stay in the record. Oda hides superseded entries from the active conversation; it does not delete them, so the chat's full history stays in its record.