Coming Soon

See how your AI tools are actually used.

Cross-tool AI assistant observability. Skills invoked, tokens consumed, session quality — all pushed to your infrastructure. Crucible never sees the data.

The enterprise visibility gap

🔇

No idea which skills are used

You sync 20 skills to 50 developers. Which ones are actually invoked? Which are ignored? No way to know.

💸

No cost tracking

Uber spent their entire 2026 AI budget in 4 months. How do you measure value per team, per repo, per assistant?

🔒

Trust problem

Any observability tool that phones home to a third party is dead on arrival in enterprise. Data must stay in your infra.

Prometheus model for AI assistants

Ember Architecture — collector ingests from AI assistants and pushes to company backend

Crucible provides the collector. Company provides the destination. Zero data touches Crucible servers.

The closed feedback loop

Forge manages what configs/skills agents get. Ember measures how those configs/skills are actually used. Together: configure → measure → optimize.

Author skillsForge syncsDevelopers useEmber measuresOptimize

Enterprise value

📈

For Engineering Managers

"How much are we spending on AI per team? Which teams are actually using the tools we paid for? What's the ROI?"

⚙️

For Platform Teams

"Which skills are used? Which should we deprecate? Are developers accepting or reverting AI suggestions?"

🛡️

For Compliance & Security

"Audit trail of AI usage. Proof that guardrails are applied. Data stays in our infrastructure, zero third-party exposure."

Built on top of existing telemetry

Claude Code already ships with built-in OTEL instrumentation — skill activation events, token usage, session traces. Ember doesn't replace that. It builds on it.

Claude Code OTEL

Native claude_code.skill_activated events, token usage, session traces. One tool, one format.

+ Ember

Versioned skill metrics, cross-tool normalization (Cursor, Windsurf, Copilot too), unified dashboards, and flexible routing to any backend.

= Complete picture

One collector that ingests telemetry from all vendors, enriches it with version info and team context, and pushes to your infra.

Ember is not an alternative to vendor telemetry. It's the unified layer that makes all of it useful.

What you'll see

SKILL INVOCATIONS — LAST 7 DAYS

/study-java847
/review-java623
/detect-project412
/design-resource89

TOKEN USAGE BY TEAM

Platform Team
2.4Mtokens
Backend Team
1.8Mtokens
Frontend Team
960Ktokens
Estimated cost: $342 / week across 3 teams

ASSISTANT DISTRIBUTION

Claude48%
Cursor28%
Windsurf14%
Copilot10%

SKILL VERSION ADOPTION

/study-javav2.1.0
92% adopted
/review-javav1.4.0
67% adopted
/detect-projectv0.8.0
41% adopted

Mock data — illustrates what Ember dashboards will provide. Push to Grafana, DataDog, or any OTLP-compatible backend.

How Ember fits the landscape

ToolWhat it doesEmber's relationship
Claude Code OTELNative skill_activated events, token tracesEmber ingests this + adds versioning, cross-tool view
LangfuseLLM app tracing (API calls)Different scope — Langfuse tracks app LLM calls, Ember tracks developer AI usage
HeliconeLLM proxy with loggingRequires routing through their proxy. Enterprise won't do this.
DataDog LLM ObsLLM monitoringEmber can push to DataDog as a destination
OpenTelemetryGeneral observability standardProtocol, not product. Ember exports OTLP natively.

Ember doesn't compete with any of these. It's the unified collector that covers all AI assistants and pushes to your choice of backend.