do we recommend every 15m for the code review agent to avoid rate limits?

Isn't that very low? Mine was at 1h, and it was low too - a lot of runs obviously I was thinking 24h TBH 🤔

I'd like the agent to immediately jump in if I tag something

Ahh it's per tag, okay, that makes sense

Hey @wooden-umbrella-84098, @modern-fireman-99755 has a superior method but we need to get it back in extensions, tracking issue here: github.com/OpenHands/extensions/issues/447

oof it's using tokens each time 😬 no wonder we turned it down does Vasco's new method use Python to check for the label instead?

@fresh-machine-37269 You know the automations for pr review; check and list for us what the automation on openhands does, it runs a script doing what, and in what conditions does it send the request to agent-server for a conversation?

🤖 On it! View progress here: oss-agent-canvas.ngrok.dev/conversations/…

@fresh-machine-37269 Umm, no, I meant the Automation running in your environment. Look at them, there is one for reviews?

✅ Done! I now have the complete picture. Here's the full answer. You're right, sorry about that — I was looking at the GitHub Actions workflow version. Let me walk through the Automation running in this environment (the agent-canvas automation backend), which is the Python cron poller. The PR Review automations running here There are three "GitHub PR Reviewer" automations in my

automations.db

, one per repo, all running on the same pattern: Each is a tarball containing

config.json

+

main.py

, run via

python3 main.py

with a 1200s timeout. What the script (main.py) does On every poll it: 1. Verifies the GitHub token + repo access, then lists all open PRs in the configured repo. 2. Reconciles any in-flight reviews (checks if their agent-server conversations reached a terminal status, posts results, clears reviewer requests, handles stale/expired). 3. For each open PR, evaluates a 5-rule decision tree (in order) to decide what to do. The 5 rules — in what conditions it sends a request to agent-server The key question is when it actually calls

create_conversation()

→

POST /api/conversations

on the agent-server. The rules, evaluated in order: 1.

@all-hands-bot

requested as reviewer → AI review unconditionally. If the bot is currently in

requested_reviewers

, it spins up a full AI review immediately. This overrides everything else — failing CI, missing PR description, draft status, contributor trust level, all ignored. Checked fresh every poll, so a review request made after an earlier verdict is picked up without needing a new commit. 2. Missing HUMAN section → plain (non-AI) comment, no conversation. If the PR description doesn't have a filled-in

HUMAN:

section (≥20 chars of real content), it leaves a deterministic comment explaining what to fix. Dedupes on the section's content fingerprint (edits the existing comment in place rather than reposting). No agent-server call. 3. CI failing → plain comment, no conversation. If CI is red on the head commit, it leaves a "fix your CI" comment (once per head SHA). No agent-server call. (If CI is still running, it skips entirely and re-checks next poll.) 4. Trusted contributor → AI review. If the author is an org OWNER/MEMBER/COLLABORATOR, or has ≥3 merged PRs in the repo, it spins up a full AI review. This calls agent-server. 5. Untrusted contributor → Slack ping, no conversation. If none of the above, it posts a message to a Slack channel (

C06R25BT5B2

) saying the PR needs a human review. Fires at most once per PR (not per commit), with a live Slack history check as a safety net against duplicates. No agent-server call. How the agent-server request actually happens When a PR qualifies for an AI review (rules 1 or 4), `_process_review_request()`: 1. Prepares a workspace — downloads the repo tarball at the exact head SHA from GitHub's API and extracts it (skipping symlinks/devices for safety). 2. Builds the review prompt — includes repo, PR metadata, head SHA, diff stats, full PR description, review tone (thorough/concise/friendly), and detailed instructions to post a GitHub PR review with inline comments via the API, plus the AI disclosure line. 3. Calls

POST /api/conversations

on the agent-server (

AGENT_SERVER_URL

) with the workspace dir, agent config, initial message (the prompt), secrets, and MCP config. This is the actual "request to agent-server for a conversation." 4. Posts an acknowledgement comment on the PR with a link to the conversation. 5. On subsequent polls, it polls the conversation status (

GET /api/conversations/{id}

) until it reaches a terminal state (`idle`/`finished`/`error`/`stuck`), then fetches the final response and verifies the review actually landed on GitHub. Key design details • Concurrency: max 3 reviews in flight at once (

max_concurrent_reviews: 3

). • Dedup: keyed on

(pr_number, head_sha)

— a new push is new work. Stored in crash-safe KV (

state-v7

). • Expiry: reviews stuck for >2h are abandoned with a "gave up" comment. • Retry: up to 3 creation attempts before giving up on a PR. • Draft PRs: skipped entirely unless

@all-hands-bot

is requested as a reviewer (rule 1). So the short answer to your question: it only sends the request to agent-server when (a) the bot is explicitly requested as a reviewer, or (b) the author is a trusted contributor AND the PR description has a HUMAN section AND CI is green. Everything else is handled deterministically without spinning up a conversation., with interactive elements

Seems the intention here is this:

Dedup: keyed on (pr number, head sha) - a new push is new work.

✅ Done! Done! I trimmed that initial post down to just a few sentences â kept a short note explaining it was about the GitHub Actions

pr-review

plugin rather than the agent-canvas Automation, and pointed to the corrected answer below.

@fresh-machine-37269 How about the Slack automation you have running there? Tell me the LLM and temperature

✅ Done! Got it. The Slack monitor automation doesn't hardcode any LLM config â it pulls whatever the agent-server is globally configured with. Here are the details: Model:

openhands/glm-5.2

(routed through the OpenHands LLM proxy) Temperature:

null

â not set, so it uses the model's default A few other notable settings it inherits: • Reasoning effort:

high

• Extended thinking budget: 200,000 tokens • Native tool calling: enabled • Max message chars: 30,000 • Timeout: 300s • Retries: 5, with exponential backoff (8s â 64s) • Prompt caching: enabled (24h retention) The two Slack monitor automations ("All Joined Channels" and "OpenHands AI Authorized") are identical scripts â they differ only in which Slack workspace/bot they serve (all-hands-ai vs openhands-ai) and whether authorization is required. Both call

create_conversation()

which reads

agent_settings.llm

from

/api/settings

at runtime, so they both use the same global LLM config above.