Skip to main content
Besides reading and searching files, the model has tools that answer structural questions about your code: where a function is called, what a file imports, where a type is defined. These come from a code index that o4 builds for your project and from language servers you have installed. You don’t run these tools yourself. Ask a question and the model picks the right one:

​
The code index

When a session starts, o4 builds or updates a code index in the background. The index lives at .o4/index/codebase.db in your project. The first build covers every supported file, and later sessions only reindex files that changed. The index covers these languages: o4 skips files your .gitignore excludes and files larger than 1 MB. The index records symbols (functions, methods, structs, classes, traits), the calls between them, and each file’s imports. When the index exists, o4 also adds a short summary of the project’s structure to the model’s context at the start of a session.

​
Querying the index

The model queries the index with the codebase_query tool. It runs without asking for approval. If the first background build isn’t finished yet, the query waits up to 60 seconds for it, then runs anyway. changed_together reads your git history instead of the index, so it works for any file in a git repository.

​
Architecture diagrams

The show_architecture tool draws a diagram of the codebase from the index as a Mermaid flowchart. It runs without asking for approval. Ask for one when you want an overview:

​
Language servers

The lsp tool gives the model answers from a language server, which understands types and scopes that the index doesn’t. It supports:
  • goToDefinition, goToImplementation, and findReferences
  • hover, for type and documentation information
  • documentSymbol and workspaceSymbol
  • prepareCallHierarchy, incomingCalls, and outgoingCalls
o4 starts a language server the first time the model asks about a file of that type, and keeps it running for the session. The lsp tool asks for approval once per session in the default approval mode. It’s available in interactive sessions, not in print mode. With no servers configured, o4 uses these, if they’re installed and on your PATH:
In 0.2.74, o4 doesn’t send language servers the initialize request that the protocol requires first. Standard servers such as rust-analyzer answer every request with a “not initialized” error, so the lsp tool returns LSP error -32002 instead of a result. For definitions and callers, the model can use the code index above. See language servers and formatters for details.
o4 doesn’t install language servers. To add or change servers, see language servers and formatters.

​
Workspace Radar

Workspace Radar keeps a list of open items in your project that need attention. In o4 0.2.74, o4 adds items in two cases, both as warnings:
  • You quit a session with unresolved open threads. When you quit, o4 asks the model to list them as part of the session debrief (see /debrief). Each becomes an item titled Open thread: ....
  • A background task fails. The item is titled Task failed: ... with the task’s description, and its details hold the error. If the same task fails again, o4 updates the existing item and counts the failures, as in Task failed ×3: ....
The list is stored in .o4/radar.db in your project. When you start a session and there are open items, the chat shows a one-line digest, for example Workspace Radar: 2 warnings active (promise:2) · 1 new · /radar. “New” counts items added since the previous digest. Run /radar or press Alt+T to open the Radar pane. Alt+T is the remappable toggle_radar_pane action. Items are grouped by severity, so in 0.2.74 they all appear under Warnings. The selected item’s details show below the list. f and d close the pane and only fill in the prompt, so you can edit the request before you send it. Workspace Radar has no settings.

​
Project Scout

Project Scout looks at your project and suggests built-in tools and skills to turn off, and MCP servers to turn on or off, so the model’s context holds only what the project needs. Run:
/scout --diff opens the same pane. Scout only runs when you ask for it; it doesn’t open by itself when a session starts. Scout looks at the top of the project: manifest files such as Cargo.toml, package.json, or go.mod, folders such as tests, docs, or .github/workflows, the test framework, and the git history. From these it builds suggestions from a built-in set of rules, such as turning off test_run in a project with no test folder. The Project Scout pane lists each suggestion with a cost marker, its estimated token cost per request, the tool, server, or skill it affects, and the reason. The footer shows the total for your current setup and for the setup with your selections applied, for example Current: 6076 tok/req → Projected: 6076 tok/req (−0%) before you select anything. Suggestions start unselected. Applying replaces the [scout] section of .o4/config.toml in your project, and o4 says Scout recommendations saved to .o4/config.toml; restart session to apply tool, MCP, and skill changes. The changes take effect in your next session, and only in a trusted workspace, because o4 reads a project’s .o4/config.toml only there. Print mode (-p) ignores the section. The section looks like this. You can also write or edit it by hand:
Scout also writes first_run, profile_hash, and last_run, which have no effect in 0.2.74. See configuration for the full reference.