Request-level traces
Follow validation, routing, provider execution, and response delivery using a shared trace identifier and OpenTelemetry-compatible instrumentation.
Products ASTER Pulse
Request intelligence
See every request. Understand every decision.
A proposed observability layer connecting model requests, routing decisions, token usage, and provider behavior in one understandable view.
Architecture Preview
Request intelligenceSample data
Requests20p95 latency760 msEst. cost$0.04
Architecture preview · Synthetic telemetry
The challenge
A clearer boundary. A better system.
A failed AI request may involve application code, routing policy, or a provider. Aggregate latency alone cannot explain which decision caused the problem or where the time went.
The approach
ASTER Pulse
Pulse would correlate a request with its spans, model selection, failure events, and usage estimates. The design prioritizes a useful explanation over a wall of disconnected metrics.
Product direction
Designed around the decisions that matter.
Proposed capabilities guide the engineering work. Their implementation is a separate validation step.
Usage and cost attribution
Associate tokens and estimated costs with a model and workspace. Mark estimates clearly and reconcile against provider records when available.
Provider health and SLOs
Separate local failures from provider failures. Build service-level views from well-defined latency and success criteria, with sample coverage visible.
Under the surface
Understand the system path.
- 01
Telemetry ingestion
Receive spans and events
- 02
Processing pipeline
Redact, sample, aggregate
- 03
Metrics storage
Bounded retention
- 04
Analytics API
Query request context
- 05
Dashboard
Explain behavior
DEMONSTRATION WORKSPACE
Every request has a story.
- Requests in sample
- 20
- p95 request latency
- 760ms
- Tokens · sample
- 6.4k
- Estimated cost
- $0.04
REQUEST LATENCY / SAMPLE SEQUENCE
TRACE / REQ_DEMO_01
Validation8 ms
Route selection4 ms
Provider inference612 ms
Response delivery12 ms
Total span duration 636 ms
Engineering considerations
The tradeoffs belong in the design.
- Privacy by default
- Avoid storing prompt bodies by default. Redact credentials and sensitive fields before ingestion; define access controls and deletion behavior.
- Sampling and cardinality
- Trace sampling affects what can be inferred. Request IDs belong in trace storage, not unbounded metric labels; workspace and model dimensions need limits.
- Retention and accuracy
- Raw traces and aggregates need different retention policies. Late events, clock skew, and incomplete token reports must remain visible in the analysis.
Practical contexts
Where the architecture earns its place.
Explain a slow request
Distinguish gateway overhead, provider latency, and response delivery before changing routing policy.
Investigate a budget shift
Compare token patterns and model selection across a controlled workload; treat cost figures as estimates until reconciled.
Development direction
Built in deliberate steps.
Architecture Preview
A planned product concept. The dashboard below is an interface study with synthetic telemetry, not a connected monitoring service or production performance claim.
- PHASE 01
Instrumentation model
Define span conventions, event schemas, and the boundary between metadata and sensitive content.
- PHASE 02
Telemetry prototype
Test ingestion, redaction, sampling, and request correlation with generated workloads.
- PHASE 03
Operational views
Explore trace search, provider comparisons, and SLO reporting once data quality is understood.
Proposed sequence. Milestones describe validation goals, not release commitments.
Connected by design
Explore the ecosystem.
Connect with AsteriaX
Build the next
AI application with clarity.
Explore ASTER Gateway or connect about an application workload, technical collaboration, or startup ecosystem opportunity.