Inspect local health
- Open Settings → Usage.
- Choose Refresh if you need updated observations.
- Expand Diagnostics.
- Inspect usage persistence and pending records, then expand the affected harness.
- Read installation status, version, executable, credential route, readiness, usage freshness, and Capabilities and limitations where present.
An installed executable can still have an unready route. An unsupported native capability can reflect a CLI version qualification rather than bad credentials. Old, provisional, or failed accounting records also require a different diagnosis from a provider quota problem.
Export the diagnostic report
Choose Export diagnostics to create a JSON file. The export uses a defined set of fields, omits the local executable path, and includes harness versions, capabilities, route/readiness, quota freshness, and selected accounting/error metadata.
Inspect the file before sharing it. It can include session or request identifiers and operational metadata; a diagnostic export should not be treated as anonymous merely because secret fields are excluded. Avoid adding credential files, screenshots of API keys, or full environment dumps.
Add useful context
Include the OS, Rudr version, harness/version, selected route, exact UI action, expected outcome, actual error, and whether the task was running or idle. For installation, include the method and whether a fresh terminal sees the executable. For continuation, include source and destination harnesses and whether a linked session was created.
Exporting locally does not submit a report. Use Report a problem when you deliberately want to send information, authentication for setup, and accounting for cost-record issues.