Pluggable Logger

VernLLM accepts a custom logger through the logger option. The logger must implement the Logger interface:

interface Logger {
  debug(message: string): void;
  warn(message: string): void;
  error(message: string, meta?: Record<string, unknown>): void;
}

Note debug and warn only ever receive a single message string, meta is error-only.

import pino from 'pino';
import type { Logger } from 'vern-llm';

const pinoInstance = pino();

const pinoLogger: Logger = {
  debug: (msg) => pinoInstance.debug(msg),
  warn: (msg) => pinoInstance.warn(msg),
  error: (msg, meta) => pinoInstance.error(meta, msg),
};

const llm = new VernLLM({
  client: fromOpenAI(openai),
  model: 'gpt-4o',
  logger: pinoLogger,
});

What gets logged, at each level

Every internal log line is prefixed [VernLLM] or [VernLLM:<requestId>] so multiple concurrent calls (and multiple VernLLM instances) stay distinguishable in one log stream:

Default logger behavior

If no logger is provided, VernLLM uses a console-based logger, and debug messages from it are controlled by the debug option:

• debug: true enables debug logging.
• debug: false disables debug logging.
• When debug is not provided, debug logging defaults to disabled (false).

warn and error messages are always emitted regardless of the debug option.

debug only controls the default console logger. If you supply a custom logger (see above), VernLLM calls its debug() method on every debug event regardless of the debug option, your logger's own implementation decides whether that call actually emits anything. A logger wrapping something like pino, which is typically gated by its own log level rather than a boolean passed in at construction, will see every debug call whether or not debug was ever set.

Redacting debug output

If prompts or responses can contain sensitive data, pass redact to scrub it before it reaches the debug logger:

const llm = new VernLLM({
  client: fromOpenAI(openai),
  model: 'gpt-4o',
  debug: true,
  redact: (text) => text.replace(/\b\d{3}-\d{2}-\d{4}\b/g, '[REDACTED]'),
});

redact is applied at exactly two call sites internally, both debug-level:

• The success path: the response content is passed through redact (or, for a tool-call-only turn with no text, a placeholder like [2 tool call(s)] is, since there's no text to redact) before being truncated to 800 characters and logged.
• The failure paths: the stringified provider error is passed through redact, for both a normal call failure and a stream-open failure.

These are the one place an app has no other way to intercept: they're direct logger.debug calls, not something routed through a callback. Everything else that could carry the same content, onEvent payloads, LLMError.cause, onUsageFailure, already goes straight to a callback your own code controls, so redacting it there needs no help from VernLLM.