Use this page when you want to configure the built-in Adaptive plugin component
as a whole. The component kind is adaptive.
Adaptive plugin configuration uses the generic NeMo Relay plugin document shape.
Field names stay snake_case in every binding and in plugins.toml, even when
language helper functions use language-native naming conventions.
For plugin file discovery, precedence, merge behavior, editor controls, and gateway conflict rules, see Plugin Configuration Files.
The top-level adaptive object contains:
The requested area pages cover Adaptive Cache Governor (ACG) and Adaptive Hints. State, telemetry, tool parallelism, and policy remain whole-plugin settings:
state.backend.kind = "in_memory" for local experiments.telemetry when adaptive learners should consume runtime events.tool_parallelism.mode = "observe_only" until scheduling behavior has
been validated.policy.unsupported_value = "error" for rollout safety.plugins.toml ExampleThis configuration activates adaptive telemetry, keeps tool parallelism
observational, injects adaptive hints, and leaves ACG in passthrough mode so
requests can be observed without provider-specific cache translation.
Use the manual runtime API when an integration needs to own adaptive lifecycle directly instead of activating the top-level plugin component.
Validate plugin configuration before initialization. Disabled adaptive
components are still validated, which lets operators prepare a rollout before
setting enabled = true.
Common validation failures include:
Clear plugin configuration during shutdown or test cleanup. Clearing the plugin configuration deregisters adaptive subscribers and intercepts owned by the plugin runtime.
Start by enabling state and telemetry in a development environment. Run representative instrumented workflows, inspect emitted events and adaptive reports, and then enable active behavior one area at a time. Keep rollback as a configuration change.