# Documentation
Create a `CodexConfig`, optionally attach the sanitized model catalog that the
host has already verified, open `Codex`, then build an `AgentRequest`. Add dynamic
functions with `DynamicTool::new`. Iterate `AgentTurn::next_event`:
- append `AgentEvent::ProviderInput` directly to any transparent transport log;
- execute `AgentEvent::ToolCall` in the application and return a matching
`ToolResult` with `AgentTurn::respond`;
- consume `AgentEvent::Completed` as the terminal turn result.
One dynamic function call represents one application operation. Codex may make
several calls in a model response. This crate exposes and completes dynamic
calls sequentially in server-request order.
Dynamic tools are declared only on fresh threads. Codex persists their
definitions with the thread and restores them during `thread/resume`.
Every app-server process receives `tool_output_token_limit=180000`, overriding
the selected model's smaller default tool-output policy.
The runtime intentionally exposes exact outbound JSONL rather than a friendly
rendering. This is the observable client-to-Codex boundary. It cannot claim to
show provider-side instructions or transformations that Codex does not expose.