Member at a project. Calls models from code, notebooks and coding agents;
wants a key without filing a ticket, and — when something breaks — wants to find
out where without waiting for an admin. Has no business with providers,
budgets, people or policy, and the dashboard should not put those in the way.
Two things make this persona sharper than “a user with a key”:
Their MCP servers and models are often local — an MCP server a coding agent
launched over stdio, a model on their workstation — so “where is the problem?”
means their machine, rolter, or the upstream, and they need to tell which.
They read their own request bodies to debug. A member of the project reads
captured bodies by default (#1820); a viewer does not.
Goal: “I call models through rolter with my own key, and when a call fails I
can see why.”
Dogfood account:engineer@rolter.local, member of project default/default
(the fleet’s project). engineer2@rolter.local is a member of
research/sandbox and should see none of it. See
dogfood data.
The observer watches: the time from first sign-in to the first successful call
(ui_events screen views → the first request_logs row on the engineer’s key),
and every screen the engineer opens while debugging E5 — the order they look in
is the finding.
The debugging loop, in the order an engineer should be able to walk it.
#
step
where
expect
status
E5.1
read the error the client got
the response body
OpenAI-style JSON whose type and code name the cause: 401 authentication_error; 403 model_not_allowed / route_not_allowed / provider_not_allowed / required_header_missing; 400 guardrail_blocked / plugin_blocked; 404 model_not_found (no such route); 402; 429 rate_limit_exceeded with Retry-After, or queue_full / queue_timeout; 503 queue_dropped; 502 pii_sanitizer_unavailable; other 5xx (no target, or the upstream)
verified (401, 404 here; 403 in P1.2)
E5.2
find the request
GET /api/v1/analytics/invocations?request_id=<x-request-id> (#1863); LLM Logs, filtered by status = error and model
the row: status, target, provider, error text, latency, retries, and the captured bodies
partial — #1861 (LLM Logs has no request-id search; the API filter lands with #1863)
E5.3
follow it into a trace
the row’s trace_id, copied from the LLM Logs drawer (#1983), in SigNoz
where the time went: queue, upstream, stream
works
E5.4
check whether the upstream is sick
Circuit Breaker, provider health
the provider behind the route: breaker state, uptime, recent failures