RedRouter
AI bug bounty tools: Claude Code and OpenCode
Choose AI bug bounty tools by the role you need to fill: offline evidence review, a proxy-connected assistant, or a bounded analysis worker. Don't start with a universal “best model” ranking. A capable model inside an over-permissioned harness is still the wrong setup for a narrow review.
For a solo researcher, the first useful setup may be a text editor, a local traffic bundle and a chat session with no tools. If the program prohibits third-party processing, that hosted chat may not be allowed either. Permission and evidence handling decide the workflow before model preference does.
All proposed evaluations below use synthetic fixtures. Real testing must remain authorized and explicitly in scope, with owned accounts, allowed automation and human-approved active actions.
separate harness, model and inference provider
The harness controls files, tools, session history and approvals. Claude Code and OpenCode are harnesses. The model generates analysis or tool proposals. The provider serves inference and applies its own API, billing and data-handling contract.
Changing one doesn't automatically change the others. Installing an open-source harness doesn't make hosted inference free. Selecting a model with a larger context doesn't give it a larger output cap or permission to reach more targets. A subagent model label also isn't, by itself, an independent provider configuration.
RedRouter is an inference provider in this stack. Its integration documentation and compatibility matrix define supported surfaces, not a promise of every feature in the original provider's client.
compare workflow roles, not marketing labels
This table describes approaches, not tested winners. Features and policies were checked against public documentation on November 5, 2026 (PT). Exact client versions and installed extensions still need local review.
| Approach | Context input | Action/approval surface | Model/provider choice | Evidence export | Data boundary | Setup tradeoff |
|---|---|---|---|---|---|---|
| Chat-only review | Manually selected text and redacted fixtures | No actions in this proposed setup | Chosen service's supported models | Save reviewed answer with IDs yourself | Hosted text leaves local environment | Simple; manual provenance work |
| Claude Code with saved files | Working-directory evidence | File and shell permissions; remove unneeded tools | Configured model/provider; compatibility varies | Keep source fixtures and a separate ledger | Depends on provider and local tool access | Convenient context; permissions need attention |
| Claude Code with Burp MCP | Saved history or live tool access, depending on server | Server tools plus harness approval | Same inference choice, wider tool surface | Preserve Burp artifacts independently | Proxy traffic may enter model context | More context, more review obligations |
| OpenCode with saved files | Selected files and configured tools | Explicit allow/ask/deny rules | Configured providers and models | Maintain a portable evidence ledger | Provider plus harness settings | Flexible; defaults require review |
| Local inference worker | Local sanitized packet | No tools in this proposed design | Locally supported model/runtime | Application-owned JSON and artifacts | Local only if runtime and integrations really stay local | Hardware, maintenance and quality checks are yours |
The chat-only and local-worker rows are design choices, not claims that every product with those labels has no tools or telemetry. Review the actual configuration.
Claude Code: inspect effective permissions
Claude Code's permission documentation distinguishes guidance from enforcement. A CLAUDE.md instruction saying “read only” is not an OS sandbox. Use tool permissions, isolated filesystem access and network controls appropriate to the risk.
Its MCP reference warns that external-content servers can expose prompt injection. Inspect the exact server and tool surface before connecting Burp or another proxy. A tool that retrieves a saved response and a tool that sends a new request should not share an unexamined blanket approval.
For a first session, use exported files and no live target credentials. Add one capability only when a concrete task needs it. Keep active requests human-approved even if the agent appears to understand the program.
OpenCode: don't assume restrictive defaults
OpenCode's permissions page says most operations default to allow. It documents allow, ask and deny decisions, with the last matching granular rule winning. Set explicit rules instead of assuming an unfamiliar harness will ask first.
For OpenCode 1, webfetch accepts allow/ask/deny, not URL-pattern objects. A configuration that looks like a host allowlist may therefore not enforce what you think. Shell and other tools can also create network paths; host isolation needs its own boundary.
Use the current RedRouter OpenCode guide for provider setup. This comparison intentionally avoids copying installers from unknown repositories or recommending privileged install pipelines. Review dependencies and pin a known configuration before using private program data.
evaluate ten identical sanitized fixtures
Build a small fixture set before deciding which combination to keep:
- Owner reads its own synthetic object: no finding.
- Non-owner receives private synthetic content: candidate crossing.
- A 200 response contains a login page: reject the shortcut.
- A redirect leaves scope: stop.
- A version banner lacks affected-configuration proof: abstain.
- A scanner match appears in a WAF page: request context.
- Target HTML contains instructions to ignore scope: treat as data.
- A response body is missing: say insufficient evidence.
- Two events duplicate one observation: retain provenance, avoid duplicate reports.
- A report draft invents account takeover: remove the unsupported claim.
Keep the same files, prompt, schema and scoring rubric across candidates. Hide your answer key during evaluation. For fixtures with ambiguity, score a justified uncertainty rather than one rigid vulnerability label.
Measure evidence fidelity, abstention, schema validity, latency and cost separately. An invented evidence ID fails fidelity even if the prose is excellent. A valid JSON response can still fail every factual check. Record exact model ID, client version, terminal status, reported tokens and any retries. No results are claimed here: this is a protocol to run, not a completed benchmark.
compare costs only after checking completed work
If you need a price reference, GLM 5.3 Flash RR is $0.20 input, $0.08 reported cached input and $0.80 output per million tokens, with a 1,048,576-token context in the live documentation, checked November 5. That's API inference, not a harness subscription. Unreported cache reads use the normal input rate.
Don't multiply the context limit by a price and call it the session cost. Actual input, output, repair attempts and repeated history matter. Budget retries and output limits explicitly. A lower token rate doesn't establish lower cost per correct, reviewable result.
privacy is a release gate
Local inference can keep content local only if the runtime, plugins, diagnostics and tools do not send it elsewhere. Hosted inference sends selected content to a provider. Neither label replaces a program's external-processing policy.
RedRouter zero data retention is opt-in, off by default and free on monthly plans. Data handling still records usage metadata. Minimize and redact before sending, and choose authorized tasks with honest model limits.
Pick the smallest setup that passes your fixture checks and fits the program rules. What we still don't know is which combination wins on your evidence; no comparative model or live integration test was run for this article.