Manage Signals from the CLI

lmnr-cli signal creates, inspects, updates, and deletes Signals from your terminal. Keep a Signal’s prompt and schema in your repo, ship changes from CI, or hand the surface to a coding agent that can shell out.

signal ships in the standalone lmnr-cli npm package. You do not need the @lmnr-ai/lmnr SDK installed to use it.

Install and authenticate

# Run directly with npx (no install)
npx lmnr-cli@latest signal list

# Or install globally
npm install -g lmnr-cli

The CLI authenticates as you, the signed-in user, and resolves which project to target from the directory you run in. Run setup once per project:

lmnr-cli setup

That logs you in and writes .lmnr/project.json, so every signal command in that directory (or any subdirectory) targets that project. Override per command with --project-id <uuid>. See Authenticate and Directory-scoped projects. The rest of this page assumes a global install. With npx, prefix each command with npx lmnr-cli@latest.

Create a Signal

A Signal is a prompt, a schema, a trigger, and filters. At minimum signal create needs a name, --prompt, and --schema:

lmnr-cli signal create "Refund requests" \
  --prompt "Detect when the user asks for a refund. Extract the reason they gave." \
  --schema '{"properties":{"reason":{"type":"string","description":"Refund reason"}}}'

Created signal "Refund requests".
Refund requests (50da5457-4b5d-4937-b834-4a73f50ce473)
  prompt:       Detect when the user asks for a refund. Extract the reason they gave.
  fields:       reason
  trigger:      root-span-finished
  filters:      {"value":"1000","column":"total_token_count","operator":"gt"}
  mode:         realtime
  sample rate:  none
  status:       active
  llm profile:  env
  model:        env default

llm profile: env means the Signal runs on the deployment’s own model credentials, which is how every Signal on Laminar Cloud runs. On a self-hosted deployment you pick a profile instead: see Run a Signal on an LLM profile. The trigger defaults to root-span-finished, the filter to total_token_count > 1000, and the mode to realtime, so the Signal is already live on new traces. See Triggers and Filters for how they work. --schema takes a JSON Schema object:

Field names must be identifiers: ^[a-zA-Z_][a-zA-Z0-9_]*$.
Field types are string, number, or boolean. For a fixed set of values, use "type": "string" with an enum array.
Every field is required. type and required are filled in for you if you omit them.

To override the trigger, filters, or mode from the CLI:

lmnr-cli signal create "Fabricated tool data" \
  --prompt "The agent presented information not supported by the tool results it received." \
  --schema '{"properties":{
      "failed_tool":{"type":"string","description":"The tool that failed"},
      "severity":{"type":"string","enum":["low","high"],"description":"How bad it is"}}}' \
  --trigger span-name --span-name agent.run --span-name worker.step \
  --filter '{"column":"status","operator":"eq","value":"error"}' \
  --mode realtime \
  --sample-rate 25

Created signal "Fabricated tool data".
Fabricated tool data (0e5b6466-eeab-47f9-a5d4-6b2ff6c7a365)
  prompt:       The agent presented information not supported by the tool results it received.
  fields:       severity, failed_tool
  trigger:      span-name: agent.run, worker.step
  filters:      {"value":"error","column":"status","operator":"eq"}
  mode:         realtime
  sample rate:  25
  status:       active
  llm profile:  env
  model:        env default

--filter takes JSON {"column":"...","operator":"...","value":"..."} and is repeatable. Columns: total_token_count, status, span_names. Pass it on create to replace the default.

--span-name is the trigger flag. span_names is a filter column: it matches a name anywhere in the trace.

Two more flags shape a new Signal:

--sample-rate <1-95> evaluates only that percentage of matching traces. Omit it for no sampling.
--disabled creates the Signal paused. Turn it on later with signal update --no-disabled.

Creating a Signal also creates two alerts: a Critical-severity event alert and, when clustering is enabled, a New cluster alert. Both notify you in-app and by email. Route them to Slack, change their severity, or add output-schema filters from the Signal’s Settings > Alerts section. See Alerts.

List and inspect Signals

lmnr-cli signal list

ID                                    Name                  Status  Sample  Trigger                            Filters  Mode
50da5457-4b5d-4937-b834-4a73f50ce473  Refund requests       active  -       root-span-finished                 1        realtime
0e5b6466-eeab-47f9-a5d4-6b2ff6c7a365  Fabricated tool data  active  25%     span-name: agent.run, worker.step  1        realtime

Columns are truncated to fit your terminal width. Pass a name to filter the list by case-insensitive substring, and signal get to see one Signal in full:

lmnr-cli signal list refund
lmnr-cli signal get "Refund requests"

Every command that takes a <signal> accepts either an id or a name, so you rarely need to look up a uuid. An ambiguous name is an error listing the candidates rather than a silent pick, since update and delete change things:

$ lmnr-cli signal get "Checkout"
ERROR: "Checkout" matches 2 signals: Checkout timeouts (80345fd4-…), Checkout failures (b8f0bbd5-…). Pass the id instead.

signal get renders the trigger and filters in the same syntax the flags accept, so its output is copy-pasteable into signal update.

Machine-readable output

Every subcommand takes --json, which prints structured JSON to stdout while human-facing messages go to stderr. That keeps pipes clean for scripts and coding agents:

lmnr-cli signal get "Refund requests" --json

{
  "id": "50da5457-4b5d-4937-b834-4a73f50ce473",
  "projectId": "0cce3ee3-d6bb-437d-a2fa-bbfd72a935e2",
  "name": "Refund requests",
  "prompt": "Detect when the user asks for a refund. Extract the reason they gave.",
  "structuredOutput": {
    "type": "object",
    "required": ["reason"],
    "properties": {
      "reason": {
        "type": "string",
        "description": "Refund reason"
      }
    }
  },
  "sampleRate": null,
  "disabled": false,
  "createdAt": "2026-08-17T11:01:12.951925Z",
  "trigger": { "type": "rootSpanFinished" },
  "filters": [
    {
      "value": "1000",
      "column": "total_token_count",
      "operator": "gt"
    }
  ],
  "mode": "realtime",
  "version": 1,
  "llmProfileId": null,
  "llmProfileName": null,
  "model": null
}

version is the current version of the judge definition (the prompt and schema). The full history is signal versions, below. llmProfileId, llmProfileName, and model are null when the Signal runs on the deployment’s own credentials.

# Every Signal that is not currently active
lmnr-cli signal list --json | jq '.[] | select(.disabled) | .name'

Version history

Editing a Signal appends a new version of its definition: the name, prompt, schema, trigger, filters, mode, sampling, status, and LLM route as they were at that moment. An edit that changes nothing appends nothing. signal versions prints that history, oldest first, so you can see what the judge was asked at the time an old event was extracted:

lmnr-cli signal versions "Refund requests"

v1  2026-08-17T11:01:12.951925Z
  prompt:  Detect when the user asks for a refund. Extract the reason they gave.
  fields:  reason

v2  2026-08-19T09:20:41.118204Z
  prompt:  Detect refund asks only, ignore complaints.
  fields:  reason

Like get, it takes an id or a name. The human output shows the prompt and the payload fields of each version; with --json each entry is {"version","createdAt","definition"} and definition carries the whole snapshot. The version field on signal get is only the current pointer; this command is the log.

Update a Signal

signal update is a partial patch: any flag you omit keeps its stored value. Changing the prompt cannot clear your sampling, reactivate a paused Signal, or alter when it fires.

lmnr-cli signal update "Refund requests" --prompt "Detect refund asks only, ignore complaints."

Switching a Signal to batch processing leaves its trigger and filters untouched:

lmnr-cli signal update "Refund requests" --mode batch

Everything you can set on create, you can change:

# Change when it fires
lmnr-cli signal update "Refund requests" --trigger span-name --span-name agent.run

# Replace the whole filter set (--filter always replaces, never appends)
lmnr-cli signal update "Refund requests" \
  --filter '{"column":"total_token_count","operator":"gt","value":"5000"}'

# Run on every trace it fires for
lmnr-cli signal update "Refund requests" --no-filters

# Sampling on, then off
lmnr-cli signal update "Refund requests" --sample-rate 10
lmnr-cli signal update "Refund requests" --no-sampling

# Pause, then resume
lmnr-cli signal update "Refund requests" --disabled
lmnr-cli signal update "Refund requests" --no-disabled

A paused Signal stops evaluating new traces and rejects backfills, but keeps its existing events and clusters. See Pause and resume a Signal. An update with no flags is an error rather than a silent no-op:

$ lmnr-cli signal update "Refund requests"
ERROR: Nothing to update. Pass at least one of --prompt, --schema, --trigger, --filter,
--no-filters, --mode, --sample-rate, --no-sampling, --disabled, --no-disabled.

Run a Signal on an LLM profile

Pointing a Signal at an LLM profile is available on self-hosted deployments. On Laminar Cloud, Signals run on Laminar’s own model credentials and the flags below are rejected.

On a self-hosted deployment, each Signal runs on one LLM profile and one of that profile’s models. --llm-profile-id and --model set the pair, and they are required together on signal create:

lmnr-cli llm-profile list   # the ID column is what --llm-profile-id takes

lmnr-cli signal create "Refund requests" \
  --prompt "Detect when the user asks for a refund. Extract the reason they gave." \
  --schema '{"properties":{"reason":{"type":"string","description":"Refund reason"}}}' \
  --llm-profile-id 2cc210c3-3f6f-4655-a3fc-a12cf4dea5e5 --model llama-3.3-70b

signal update takes the same pair to move a Signal onto a different profile or model:

lmnr-cli signal update "Refund requests" \
  --llm-profile-id 23ea6106-6ec8-4d1b-b2bc-5423272244b3 --model gpt-5-mini

Both flags pass straight through, so the server’s own rules apply and its messages are what you see:

Passing only one of the two is rejected. So is passing either one on Laminar Cloud.
The model has to be one the profile declares. Discover both with lmnr-cli llm-profile list.
There is no flag for moving a Signal back to the deployment’s environment credentials. Signals created before you added profiles keep running on them until you pin a profile.
Deleting a profile, or removing a model a Signal is pinned to, is refused while that Signal exists.

signal get shows the pair, with the profile name for readability:

  llm profile:  Internal gateway (2cc210c3-3f6f-4655-a3fc-a12cf4dea5e5)
  model:        llama-3.3-70b

See LLM profiles for how to create one and what each provider needs.

Delete a Signal

lmnr-cli signal delete "Refund requests"

Deleted signal "Refund requests" (844258b2-b786-435b-924a-3884d518c36a), its triggers, alerts, and events.

Deletion is permanent and cascades: the Signal’s triggers, its alerts, and every signal event it ever produced are removed. To stop a Signal without losing its history, pause it with signal update --disabled instead.

Reference

lmnr-cli signal [command]

Shared by every signal subcommand:

  --project-id <id>   Target project id. Defaults to the linked .lmnr/project.json
  --base-url <url>    Base URL for the Laminar API. Defaults to https://api.lmnr.ai or LMNR_BASE_URL
  --port <port>       Port for the Laminar API. Defaults to 443 or LMNR_HTTP_PORT
  --json              Output structured JSON to stdout

signal create

lmnr-cli signal create [options] <name>

Arguments:
  name                       Signal name (unique per project, max 255 chars)

Options:
  --prompt <prompt>          LLM instruction describing what to detect in a trace (required)
  --schema <json>            Payload schema as JSON (required)
  --trigger <kind>           root-span-finished | span-name. Omitted → root-span-finished
  --span-name <name>         Span name to trigger on (repeatable). Requires --trigger span-name
  --filter <json>            Filter as JSON (repeatable, ANDed). Omitted → the default >1000 tokens
  --mode <mode>              batch | realtime. Omitted → realtime
  --sample-rate <percent>    Evaluate only this percent of matching traces (1-95)
  --disabled                 Create the signal paused
  --llm-profile-id <id>      Workspace LLM profile to run the signal on (self-hosted only,
                             required together with --model)
  --model <name>             Model to use from that profile (self-hosted only)

signal update

lmnr-cli signal update [options] <signal>

Arguments:
  signal                     Signal id or name

Options:
  --prompt <prompt>          Replace the LLM instruction
  --schema <json>            Replace the payload schema (same shape as create)
  --trigger <kind>           Change when it is evaluated: root-span-finished | span-name
  --span-name <name>         Span name to trigger on (repeatable). Requires --trigger span-name
  --filter <json>            Replace ALL filters with these (repeatable, same syntax as create)
  --no-filters               Clear all filters (run on every trace it fires for)
  --mode <mode>              batch | realtime
  --sample-rate <percent>    Set the sampling percent (1-95)
  --no-sampling              Clear sampling (evaluate every matching trace)
  --disabled                 Pause the signal
  --no-disabled              Resume the signal
  --llm-profile-id <id>      Re-route the signal onto a workspace LLM profile (self-hosted
                             only, must be paired with --model). There is no flag to clear
                             the route back to the deployment's own credentials
  --model <name>             Model to use from that profile

signal list, get, versions, delete

lmnr-cli signal list [name]       # name filters by case-insensitive substring
lmnr-cli signal get <signal>      # signal is an id or a name
lmnr-cli signal versions <signal> # definition history, oldest first
lmnr-cli signal delete <signal>

Every command has examples in its own help text:

lmnr-cli signal --help
lmnr-cli signal create --help
lmnr-cli signal update --help

What’s next

Signals

How a Signal reads a whole trace and turns it into structured events.

Quickstart

Write your first Signal in the UI and run it over historical traces.

Alerts

Fire Slack or email notifications on the events your Signal produces.

CLI

The rest of lmnr-cli: setup, SQL queries, datasets, and debug sessions.

Overview

Tracing

Signals

Debugger

Evaluations

Datasets

Platform

Install and authenticate

Create a Signal

List and inspect Signals

Machine-readable output

Version history

Update a Signal

Run a Signal on an LLM profile

Delete a Signal

Reference

signal create

signal update

signal list, get, versions, delete

What’s next

Signals

Quickstart

Alerts

CLI

​Install and authenticate

​Create a Signal

​List and inspect Signals

​Machine-readable output

​Version history

​Update a Signal

​Run a Signal on an LLM profile

​Delete a Signal

​Reference

​signal create

​signal update

​signal list, get, versions, delete

​What’s next

Signals

Quickstart

Alerts

CLI

Install and authenticate

Create a Signal

List and inspect Signals

Machine-readable output

Version history

Update a Signal

Run a Signal on an LLM profile

Delete a Signal

Reference

signal create

signal update

signal list, get, versions, delete

What’s next