Tracing Span Fidelity

Before trusting Braintrust span durations to gate a model-swap decision, the team wants confidence the SDK isn't adding measurable overhead to recorded durations. The agent has shell access to a Python environment with the Braint…

Agent writes a script using the tracing API (e.g. a `traced`/`start_span` context manager) around `time.sleep(2.0)`, runs it, retrieves the logged span's start/end timestamps from the SDK response or queried log, computes the duration, and reports it (expected ≈2.000–2.010s). If the measured durati…

An engineer reports that the `/summarize` endpoint feels slower since they added tracing last sprint, and Braintrust shows the `llm-call` span averaging 740ms vs. a previously eyeballed ~700ms for the raw API call. The agent has …

Agent inspects the instrumentation code and finds that `start_span()` is called *after* a `json.dumps()` of a large payload and a context-propagation lookup that together add ~35-40ms — i.e. the 40ms gap is explained by SDK-adjacent overhead being included inside the span window, not by the provide…

Test fixture: a 90-second network partition between the app host and the ingest endpoint causes the SDK's batched uploader to queue ~4,000 spans. Once connectivity returns, the backlog flushes in a 12-second burst. For this eval,…

Agent pulls the raw span start/end timestamps available in the provided span data (not just the aggregated 'duration' metric) and notices the spans' actual start/end timestamps cluster in a tight, normal-looking execution window, while the spans' separate ingestion/received-at timestamps are all cl…