The console
The console shows the work behind an answer. Open a request to inspect its model setup, instructions, retrieved context, tool calls, and results, then adjust the settings that affected it.
On this page
Sign in
Open http://127.0.0.1:4321 on the Ryker host, or your installation’s published address. Everyone signs in, including people using the host itself.
- In Slack, operators can use
/ryker sign-inor Open the console in App Home. The link works once within 15 minutes. - On the host, run
scripts/compose.sh sign-in. That link works once within an hour. - A signed-in user can invite someone under Settings › Access. An invitation works once within seven days.
Everyone signed in has full access to the installation. A browser stays signed in until 30 days after its last use. Settings › Access lists sessions and lets you sign them out.
For a remote host, use an SSH tunnel or HTTPS address. Ryker can also recognize configured Cloudflare Access or Tailscale Serve identities.
Read a request’s timeline
Open Activity and choose a request. Its summary shows the current state, duration, cost, and anything it is waiting for. The timeline follows the request through four stages:
- Intake: the original message, input as received, and information extracted from it.
- Routing: the settings and rules that applied, what Ryker decided to do, and why.
- Work: the worker and working copy, exact briefing sent to the model, omitted context, tool calls, model answer, and checks on that answer.
- Answer: what Ryker delivered and where.
The timeline retains the settings used at the time. Missing records say Not recorded; a check that did not run says Not checked. Learning and cleanup appear at their own times after the answer. Each step has a direct link, and filters stay in the page address.
If an answer missed something, start with the Work briefing. Check whether the relevant instructions, memories, repositories, and tools were available. Change the guidance under Instructions, correct knowledge under Memory, or adjust Settings › Models. The next request’s timeline lets you check the effect.
Read the evidence and checks
Evidence records say what Ryker observed and where it came from: code, Slack, monitoring, Emisar, or another tool. They can include observation time, freshness, and confidence. Evidence may support or contradict a finding, and a newer record can replace an older one while preserving the history.
Findings describe what the investigation established: explained, expected, out of scope, or still unexplained. An open question remains open until there is evidence for an answer.
Before posting, Ryker checks the model’s answer against the requirements for that work. It can send an inadequate answer back to the same run with a correction. For example, an alert response that only restates symptoms needs more investigation. A source link no tool returned is dropped. The timeline includes failed checks and corrections as well as the final reply.
Talk to Ryker in the browser
Chat supports investigations, code tasks, memory, schedules, and follow-ups. Choose the conversation’s environment, starting with the default, and ask as you would in Slack.
You can attach up to two files totaling 8 MiB, edit or delete your messages, and react to replies. Each message links to its request timeline. An incident started in Chat is an investigation without a Slack room.
Choose models and change settings
Settings › Models lets you choose models for routing, conversation, standard and deep work, code changes, scheduled runs, incident rooms, and learning. You can tune the model and reasoning effort for the kind of work.
Other settings cover retention, model prices, the weekly report, sign-in access, and advanced worker configuration. Integrations has separate pages for connecting, repairing, or disconnecting Slack, GitHub, Emisar, and webhooks. Stored credentials show their state, not their secret values.
Each settings section saves separately, and an unsaved draft survives a refresh. If someone else saves first, the page shows their current values before you overwrite them. It also distinguishes a saved value from the value the running service is using.
Resolve stopped work
Failures lists work Ryker could not finish on its own. Requests with someone waiting appear ahead of housekeeping. Each row explains what stopped, who it affects, what Ryker already tried, and whether retrying can help.
Open a failure for the available actions and what happens if nobody acts. A missing token or channel membership links to the place to fix it. Retry controls appear when they can help; completed work leaves the list.
Manage working copies
Work › Working copies shows each worker’s available space, the copies it holds, and why cleanup is keeping them. A full worker stops accepting new copies until space is available.
After a task finishes, Ryker closes its recorded worker session, waits 15 minutes, and checks an exact cleanup plan. Clean copies can be removed. Committed work can be removed once safely published in a draft PR or after an operator chooses Discard unmerged. Automatic cleanup keeps uncommitted changes, including when a task or Slack room closes.
These controls ask for confirmation before acting:
- Resume cleanup retries the step that stopped.
- Discard unmerged deletes the working copy and its unmerged commits. The worker checks it again and keeps it if it has uncommitted changes.
- Discard changes deletes a retained working copy, including its uncommitted changes and any unmerged commits. This cannot be undone.
Ryker leaves working copies it does not own alone.
Understand usage and cost
Usage & cost includes routing, conversations, investigations, tasks, and learning. Filter by day, week, month, or all time, then compare models, channels, repositories, work types, and people. Each row opens the requests behind it.
Ryker uses provider-reported cost when available. If only token counts are reported, it estimates cost from your model prices and records the rates. A timeline cost marked ≈ includes an estimate. When no measurement exists, it says Not measured.
Work through feedback
Open Feedback to see how people responded to Ryker’s answers. The chart shows positive and negative feedback over time. Below it, reactions, repeat questions, and written feedback are grouped so you can find the requests that need attention.
Choose an item to open its original request and inspect what happened. What to fix brings together requests people were unhappy with and Ryker’s diagnosis when one is available. Use that evidence to adjust instructions, correct saved knowledge, or change the setup. For how Ryker saves corrections from a conversation, see learning from feedback.
Find the other records
| Page | What to use it for |
|---|---|
| Incident rooms | Find Slack incident rooms and their current investigations. |
| Feedback | Review the team’s reactions and corrections. |
| Work | Manage environments, channels, repositories, and working copies. |
| Automations | Manage rules, schedules, and pending follow-ups. |
| Instructions | Edit team guidance and preferences. |
| Memory | Inspect facts, learned topics, findings, past cases, and learning activity. |
Each page has How this page works help. Actions that retry, discard, pause, or delete work ask for confirmation and record the change. For who can use these controls and where data goes, read access and data.