Nanocodex
The batteries-included façade for the Nanocodex frontier-agent building blocks.
This crate contains no second runtime implementation. It re-exports the owned
agent lifecycle and gives the lower-level crates stable, named module paths.
Depending on nanocodex-agent directly creates the same agent.
Quick start
Build one owned agent, keep its cheap cloneable handle, and await typed turn results. The independent event stream is optional:
use ;
# async
Awaiting prompt means the private driver accepted and ordered the turn.
Awaiting the returned [Turn] waits for its complete [TurnResult]; it does
not wait for the turn's optional event stream to be consumed. Follow-on prompts
reuse the same retained context and transport without asking the caller to
manage response IDs or history.
Usage and USD estimates
Every completed turn reports aggregate provider usage. Cost remains explicit:
Nanocodex applies OpenAI's published gpt-5.6-sol standard or priority rates
automatically, while omitted provider usage remains distinguishable from zero.
use ;
# async
Progressive disclosure
The root exports only the golden-path types. Reach for a named module when an embedding needs more control:
- [
agent] — lifecycle policy, events, input, sessions, usage, and rollout - [
oai] — managed Responses sessions and the concrete Tower boundary - [
tools] — tool contracts, built-ins, Code Mode, and MCP observability— native tracing and OTLP setup when the default-offobservabilityfeature is enabled- [
prelude] — common imports for the owned-agent path
Detailed items retain the documentation from their owning crate. Each lower crate also includes its own focused guide and can be documented or consumed without the facade.
Canonical imports
Use the crate root for the common agent path and the module that owns a concept when reaching for its detailed API:
use ;
use ;
use ResponsesAttempt;
use Mcp;
#
The root convenience path and its owning module name the same type; for
example, [OpenAi] and [oai::OpenAi] are identical. The [agent] module
intentionally does not repeat sibling convenience exports: provider
configuration belongs under [oai], tool implementation belongs under
[tools], and lifecycle state belongs under [agent]. Applications that need
only one component can depend on its package directly and use
nanocodex_oai_api, nanocodex_tools, or nanocodex_agent.