Search

Search queries across the step trace of every run in your account. Find a specific tool call, locate the item that produced a particular output, or filter by error pattern without paging through the runs list.

What "search" actually searches

Search operates over steps — the nodes inside each item's trace — not raw container stdout. Each step has:

• Step type (llm_call, tool_call, tool_result)
• Input and output payloads (JSON)
• Tool name (for tool calls)
• Error message (for failed steps)
• Token counts and cost

Anything that lives in those fields is queryable. What's not queryable: arbitrary print() output, provider-side logs, or anything your code wrote to stdout that wasn't returned through a step.

Papayya deliberately doesn't capture raw container output. We capture the structured trace. It's more useful for debugging specific behavior and keeps storage bounded.

What you can search for

• Error substrings — "timeout", "rate limit", "invalid JSON"
• Tool names — find every item that called search_database or send_email
• Input patterns — locate the item that processed a specific customer ID
• Output patterns — find items where a particular verdict or classification was produced

Using Search

The Search page in the dashboard opens a query box scoped to your current project. Results are grouped by run, with the matched step highlighted inline under its item.

Each result links to the full item detail so you can see the step in context.

Tips

• Exact phrases match best — specific error messages or tool names beat generic words.
• Combine with outcome filters — searching "null" across failed items finds crashes; across degraded items it finds refusals and empty completions; across all items it finds noise.
• Search fades as data ages — step retention follows your retention policy; items purged from hot storage are no longer searchable.

API

There is no dedicated /v1/search endpoint. The queryable step surface is the steps endpoint, filterable by outcome and error category:

GET /v1/steps?q=<query>&project_id=<id>&outcome=failed
GET /v1/steps/error-categories

Returns matching steps with their parent item id and run id, plus a snippet. Use the item id to fetch full context (GET /v1/durable/runs/{itemId}).

When to reach for something else

• Real-time debugging — search is for "find me the item that did X." For active debugging, open the run detail page and watch its items and steps stream in.
• Aggregate metrics — for counts, cost totals, or trends, use the Usage page or query the API directly.
• Cross-project queries — search is project-scoped by default. For account-wide queries, use the API with an explicit account filter.
• Recovering bad items — search finds them; replay re-drives them.