What the agent does
Your help desk receives a ticket and starts one run for it: the product's repository in resources, the customer's question in the prompt. The agent clones the repository into its own cloud sandbox and answers from code. In a Go product like miniflux/v2, it reads go.mod (module miniflux.app/v2, Go 1.26), sees the packages under internal/, and finds feed polling split between internal/cli/scheduler.go, internal/storage/batch.go, internal/reader/handler/handler.go and internal/model/feed.go.
For "why are some feeds refreshed less often than the interval I set?", the agent starts at Feed.ScheduleNextCheck in internal/model/feed.go. The interval begins at SCHEDULER_ROUND_ROBIN_MIN_INTERVAL, or under the entry_frequency scheduler at a value derived from the feed's weekly entry count. Then interval = max(interval, refreshDelay): a feed's own refresh delay can push the next check later than the configured interval, up to SCHEDULER_ROUND_ROBIN_MAX_INTERVAL. In internal/reader/handler/handler.go that delay is max(feedTTLValue, cacheControlMaxAgeValue, expiresValue), the RSS <ttl>, the Cache-Control max-age and the Expires header.
It reads the defaults instead of guessing them. internal/config/options.go sets POLLING_FREQUENCY to 60 minutes, BATCH_SIZE to 100, POLLING_SCHEDULER to round_robin, the round robin minimum to 60 minutes and the maximum to 1440 minutes, and POLLING_PARSING_ERROR_LIMIT to 3. The scheduler in internal/cli/scheduler.go wakes every polling frequency and takes one batch of feeds whose next check has passed, so an instance with many feeds can fall behind. WithErrorLimit in internal/storage/batch.go leaves out feeds that have failed the parsing error limit, which is a second reason a feed stops refreshing.
The agent writes the reply in the shape the prompt asks for: two short paragraphs a self-hosting customer can act on, naming the settings to check, the files and lines that prove each statement, and a confidence level. It changes no code. Where the answer depends on the customer's feed, such as a long <ttl>, it says which header or field to look at.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "A customer asks: why are some feeds refreshed less often than the interval I set? Find the answer in this repository's code, not its docs: start at Feed.ScheduleNextCheck in internal/model/feed.go, follow the refresh delay in internal/reader/handler/handler.go, the batch scheduler and the parsing error limit, and read the defaults in internal/config/options.go. Reply with JSON: answer (two short paragraphs a customer can read), files (paths and lines that prove it), and confidence. Do not change code.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The run's final answer is the JSON object the prompt asks for. answer explains in plain words that a feed's own TTL or cache headers can stretch its interval, that the batch scheduler handles a fixed number of feeds per pass, and that feeds over the error limit are skipped. files points at internal/model/feed.go, internal/reader/handler/handler.go, internal/cli/scheduler.go, internal/storage/batch.go and internal/config/options.go with line numbers. confidence comes with the one thing to check when it is not high.
Your webhook gets it as data.result in the run.completed payload, and GET /o/{org}/sessions/{id} returns the same result at any time. Your backend parses the object and puts the answer on the ticket as a draft. A support person checks the cited defaults against the customer's environment, for instance whether they set POLLING_SCHEDULER=entry_frequency, before sending it.
The session keeps every file the agent read and every search it ran, so an engineer can see the path from the question to the answer. That record is what makes the next similar ticket faster: the same files, the same lines, already found.
Run it on every new support ticket
Your help desk's webhook calls POST /o/{org}/sessions once per ticket, with the question in input. Using the ticket id as the Idempotency-Key makes a duplicate delivery return the run already started instead of a second one.
Point the API key's webhook at your backend to get each reply when its run finishes, signed per Standard Webhooks so you can verify it came from Rush. When the customer replies with their configuration, send it as a follow-up message to the same session and the agent answers with the code it has already read.
The use case this job follows, with its automation and trigger: Run an agent per customer task.
Why run it on Rush?
A question about polling intervals in a Go service sits across five packages and a configuration file. A Rush run starts with the repository cloned in its own sandbox and the tools to search it, and returns a reply your backend can parse, without a developer stopping their own work to trace it.
Tickets arrive in bursts and each one gets its own run, side by side. Every reply cites the lines it relies on, and the session keeps the full record of the investigation, so support can send a precise answer and engineering can check it in seconds.
Frequently asked questions
Does the agent run the Go code or just read it?
For this question reading is enough, and the prompt says not to change code. The sandbox has a shell, so if a ticket is easier to answer by running go test on one package, say so in the prompt and the transcript will show the output.
What if the answer depends on the customer's configuration?
The reply names the setting that decides it, such as POLLING_SCHEDULER or BATCH_SIZE, and the default the code uses. Put the customer's values in the prompt when you have them and the answer can be specific.
Can I use Codex instead of Claude Code?
Yes. agent takes claude, codex or opencode, and the request on this page uses codex. The repository, the prompt and the shape of the result stay the same.
How large can the reply be?
The webhook carries result up to 16 KiB. A two-paragraph answer with a list of files is well under that; past the limit the webhook leaves result out and the session read returns it.