Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/elastic/cursor-plugins/llm-obsnpx skills add elastic/cursor-plugins --skill llm-obsgit clone --depth 1 https://github.com/elastic/cursor-pluginsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00052 | $0.03642 |
| Opus 5 | $0.00026 | $0.01821 |
| Sonnet 5 | $0.00010 | $0.00728 |
| Haiku 4.5 | $0.00005 | $0.00364 |
Grade A, and why
observability-llm-obs scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to observability-llm-obs — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 243 lines — stays where its author put it; the contents beside it link to each section on GitHub.
LLM and Agentic Observability
Answer user questions about monitoring LLMs and agentic components using data ingested into Elastic only. Focus on LLM performance, cost and token utilization, response quality, and call chaining or agentic workflow orchestration. Use ES|QL, Elasticsearch APIs, and (where needed) Kibana APIs. Do not rely on Kibana UI; the skill works without it. A given deployment typically uses one or more ingestion paths (APM/OTLP traces and/or integration metrics/logs)— discover what is available before querying.
Where to look
- Trace and metrics data (APM / OTel): Trace data in Elastic is stored in
traces*when collected by the Elastic APM Agent, and intraces-generic.otel-default(and similar) when collected by OpenTelemetry. Use the generic patterntraces*to find all trace data regardless of source. When the application is instrumented with OpenTelemetry (e.g. Elastic Distributions of OpenTelemetry (EDOT), OpenLLMetry, OpenLIT, Langtrace exporting to OTLP), LLM and agent spans land in these trace data streams; metrics may land inmetrics-apm*or metrics-generic. Querytraces*andmetrics*data streams for per-request and aggregated LLM signals. - Integration metrics and logs: When the user collects data via
Elastic LLM integrations
(OpenAI, Azure OpenAI, Azure AI Foundry, Amazon Bedrock, Bedrock AgentCore, GCP Vertex AI, etc.), metrics and logs go
to integration data streams (e.g.
metrics*,logs*with dataset/namespace per integration). Check which data streams exist. - Discover first: Use Elasticsearch to list data streams or indices (e.g.
GET _data_stream, orGET traces*/_mapping,GET metrics*/_mapping) and optionally sample a document to see which LLM-related fields are present. Do not assume both APM and integration data exist. - ES|QL: Use the elasticsearch-esql skill for ES|QL syntax, commands, and query patterns when building queries
against
traces*or metrics data streams. - Alerts and SLOs: Use the Observability APIs SLOs
API (Stack |
Serverless) and Alerting API
(Stack |
Serverless) to find SLOs and alerting rules
that target LLM-related data (e.g. services backed by
traces*, or integration metrics). Firing alerts or violated/degrading SLOs point to potential degraded performance.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 243 lines · 52 tokens per session scan A 941b91ba93d3
observability-llm-obs is a skill published in the GitHub repository elastic/cursor-plugins (31 stars, last pushed 5d ago), licensed Apache-2.0. It adds 52 tokens to every session and 3,642 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to observability-llm-obs, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…
agent-host-chat-contributions
Build and review cross-cutting agent-host chat behavior through lifecycle contributions. Use when adding turn lifecycle side effects, prompt or context injection, restored-history transformation, protocol-action observation, or when reviewing changes that add code to AgentSideEffects or AgentService.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.