Mastra Adds TTFC and TTFT Metrics to Agent Observability
Mastra has added latency metrics for every agent and model call in its platform and Studio, allowing developers to track how long users wait for a response and how quickly a model begins generating one. The metrics, TTFC and TTFT, can also be queried through Mastra’s CLI, Client SDK and observability endpoints.
- Mastra now records TTFC and TTFT on every span.
- The platform and Studio can filter and sort traces by both metrics.
- Self-hosted projects can use DuckDB, PostgreSQL or ClickHouse storage.
- Latency data is available through the CLI, Client SDK and observability endpoints.
Two metrics for different parts of the wait
TTFC, or time to first chunk, measures how long a user waits before seeing anything. TTFT, or time to first token, measures how long the model takes to start responding. Mastra says the two metrics together help identify where an agent is slow and provide a measure that teams can work to improve.
The company compares the approach with website performance metrics such as Time to First Byte and First Contentful Paint. Previously, Mastra users could use durationMs to see how long a run took, but they could not determine how long a user waited for the first response or whether that delay came from the model or their own code.
Metrics are available across traces and spans
Mastra now records TTFC and TTFT on every span, from the model call through to the agent run. Both are available as fields in trace queries and span queries, alongside status, environment and agent name.
In Mastra platform and Studio, the Traces tab supports filtering and sorting by time to first chunk and time to first token. On the platform, users can enable the corresponding columns in the column settings. Mastra’s description of the workflow also shows a coding agent querying the same data, tracing a latency gap to a slow input processor and suggesting three fixes.
The latency metrics work on Mastra platform and on self-hosted Mastra projects where storage.observability uses DuckDB, PostgreSQL or ClickHouse. Developers with trace data outside Mastra can bring existing history over through trace imports.
Four ways to query latency data
Mastra lists four access routes: Mastra CLI, Mastra platform and Studio, Mastra Client SDK, and observability endpoints. The examples in the announcement find runs from the last 7 days where users waited more than 10 seconds for the first chunk, as well as runs where the model took more than 3 seconds to start responding.
The CLI requires [email protected] or later. Studio requires [email protected] and @mastra/[email protected] or later, while the Client SDK requires @mastra/[email protected] or later. Requests need a platform access token and project ID. Mastra provides separate observability base URLs for the US and EU regions: https://observability.mastra.ai and https://observability.eu.mastra.ai.
For developers operating agents, the update adds a way to separate model startup delays from delays introduced by application code. That can make trace data more actionable when investigating slow runs, while keeping the same latency fields available through both hosted and supported self-hosted deployments.
