> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/nemo/relay/llms.txt.
> For full documentation content, see https://docs.nvidia.com/nemo/relay/llms-full.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/nemo/relay/_mcp/server.

# Code Examples

This page collects concrete examples for the surrounding guide area.

## Dynamic Header Injection

Use an LLM request intercept when a plugin needs to inject tenant or routing metadata into every provider request.

LLM request intercepts receive three arguments: `name`, `request`, and `annotated`. The `request` object is immutable, however it is possible to return a new instance of the request with edits, the exception to this is when the intercept is written in Rust.

```python
from typing import Any

import nemo_relay

class HeaderPlugin:
    def validate(self, plugin_config: dict[str, Any]) -> list[dict[str, str]]:
        if "header_name" not in plugin_config or "value" not in plugin_config:
            return [{
                "level": "error",
                "code": "header-plugin.invalid_config",
                "message": "header_name and value are required",
            }]
        return []

    def register(self, plugin_config: dict[str, Any], context: nemo_relay.plugin.PluginContext):
        def add_header(
            name: str,
            request: nemo_relay.LLMRequest,
            annotated: nemo_relay.AnnotatedLLMRequest | None
        ) -> tuple[nemo_relay.LLMRequest, nemo_relay.AnnotatedLLMRequest | None]:
            # The request object is immutable, however we can return a new instance with updated headers.
            headers = request.headers.copy()
            headers[plugin_config["header_name"]] = plugin_config["value"]
            return nemo_relay.LLMRequest(headers=headers, content=request.content), annotated

        context.register_llm_request_intercept("inject-header", 100, False, add_header)

nemo_relay.plugin.register("header-plugin", HeaderPlugin())
```

```ts
import * as plugin from 'nemo-relay-node/plugin';

const headerPlugin: plugin.Plugin = {
  validate(pluginConfig) {
    if (typeof pluginConfig.header_name !== 'string' || typeof pluginConfig.value !== 'string') {
      return [
        {
          level: 'error',
          code: 'header-plugin.invalid_config',
          message: 'header_name and value are required',
        },
      ];
    }
    return [];
  },
  register(pluginConfig, context) {
    context.registerLlmRequestIntercept('inject-header', 100, false, ({ request, annotated }) => ({
      request: {
        ...request,
        headers: {
          ...(request.headers as Record<string, string>),
          [String(pluginConfig.header_name)]: String(pluginConfig.value),
        },
      },
      annotated,
    }));
  },
};

plugin.register('header-plugin', headerPlugin);
```

This pattern is useful for:

* Tenant identity
* Trace correlation
* Region or deployment routing

## OpenInference Export

Use a subscriber-oriented plugin when the component should watch the full lifecycle rather than rewrite requests.

```python
import nemo_relay

class OpenInferencePlugin:
    def validate(self, plugin_config):
        if "endpoint" not in plugin_config:
            return [{
                "level": "error",
                "code": "openinference-export.invalid_config",
                "message": "endpoint is required",
            }]
        return []

    def register(self, plugin_config, context):
        endpoint = plugin_config["endpoint"]

        def on_event(event):
            print("export", endpoint, event.kind, event.name)

        context.register_subscriber("openinference-export", on_event)

nemo_relay.plugin.register("openinference-export", OpenInferencePlugin())
```

```ts
import * as plugin from 'nemo-relay-node/plugin';

const openInferencePlugin: plugin.Plugin = {
  validate(pluginConfig) {
    if (typeof pluginConfig.endpoint !== 'string') {
      return [
        {
          level: 'error',
          code: 'openinference-export.invalid_config',
          message: 'endpoint is required',
        },
      ];
    }
    return [];
  },
  register(pluginConfig, context) {
    const endpoint = String(pluginConfig.endpoint);
    context.registerSubscriber('openinference-export', (event) => {
      console.log('export', endpoint, event.kind, event.name);
    });
  },
};

plugin.register('openinference-export', openInferencePlugin);
```

This is the right pattern when the component:

* Exports traces or metrics
* Aggregates events across tools and LLMs
* Should not change execution behavior

## Multi-Surface Policy Bundle

A plugin can register more than one runtime surface when one configuration document controls a related behavior bundle.

For example, a policy bundle can install:

* A telemetry subscriber
* LLM request intercepts for request metadata
* Tool guardrails for policy enforcement
* Sanitize guardrails for exported payloads
* Shared component-local state used by those hooks

Use this pattern when the configured behavior is easier to reason about as one component than as several unrelated plugin components. Keep each registered surface small and make the component config explicit about which surfaces are enabled.

## Framework-Facing Plugins

Plugins can stay framework-agnostic if they operate on the normalized runtime data rather than framework-specific objects.

Good examples:

* Rewrite provider headers
* Emit tracing data
* Attach scheduling hints
* Apply cross-framework safety policies