FAQ
How can I tune the finding levels applied by the agents?
You can tune this either directly in the agent instructions or use the shared prompt fragment to make specific callouts for the levels.
The default level behavior is:
<apply_finding_levels_appropriately>
- CRITICAL: Provable, blocking for correctness, security, or data-loss issue
- MAJOR: Provable, serious, high-risk issue that should be fixed before merge (never speculatively; never a "maybe" or "potentially")
- MINOR: Low risk edge cases, maintainability, testing gaps/weakness, duplication, lower priority corrections
- SUGGESTION: Code improvements for: structure, clarity, readability, maintainability, performance, etc.
- COMMENT: Weak signal feedback; avoid_speculation even if it is a potential issue
- Prioritize and focus on: CRITICAL, MAJOR, and MINOR findings
- Be mindful of developer "NOTE" (and other comments from developer) explaining decisions, tradeoffs, and deferred work; these supersede your own speculation and should be respected when assessing the risk of a finding
</apply_finding_levels_appropriately>
Use this as a baseline for any changes in behavior that suit your team.
Where's the pricing info?
There is no pricing info yet! But we are seeking early pilot partners to try it out, risk-free, side-by-side with your existing solutions for discounted pricing.
Are you SOC2 compliant?
Unfortunately, Zeeq is too early for that! We are happy to work with your team to run pilot workloads and provide a pathway to SOC2 compliance in the future.
If you like Zeeq and you want to use it, self hosted is the way to go!
What models should I use for code reviews?
In general, the best option is to use either GPT 5.4 Mini or GPT 5.6 Luna.
These two models are extremely fast and fast cycle times on code reviews are generally more useful than extra depth.
As a rule of thumb: your local model should be the more capable; the review model is only looking at the PR contents and using tools to look up knowledge. It is a highly focused prompt and will perform well with small, fast models.
How many reviewers should I use?
The purpose of separating reviewers into facets or "mixture of experts" (MoE) is to allow each agent prompt to focus tightly on specific aspects of the code review.
This can allow the performance of smaller, faster models to be more effective.
Additionally, it helps classify findings in the output.
Reviewer facets are also scopes for configuring filter rules. Therefore, another reason to consider multiple reviewers is to have only certain reviewers activate on specific files (e.g. an "SDET" reviewer only on test files).
That said, a single reviewer is perfectly effective! Start there and determine if it makes sense for your team to use multiple review facets.
Does using multiple reviewers increase the review time?
No. All reviews run in parallel and thus the wall clock time of the review is that of the longest review.
Does using multiple reviewers increase the review cost?
Yes. Each agent is a separate prompt and API call. That said, the prompt structure has been optimized for caching and prompts with small models will cost hundredths of a cent per run.
Can I self host on Azure or AWS?
Maybe. Technically, Zeeq can run on only Postgres, but a few components of a production deployment are better off not on Postgres like messaging.
While Postgres can be configured for messaging, it is best to use an actual messaging layer like Google Cloud Pub/Sub.
AWS SNS/SQS and Azure Service Bus are currently not supported (though the underlying messaging layer supports it) and there is no configuration/deployment scripts for AWS ECS and Azure Container Apps at the moment.
If you are interested in this, please reach out.
Are you SOC3 compliant?
No. If your organization requires SOC2, consider self-hosting. Alternatively, run a pilot first and reach out if you would prefer the hosted option and SOC2 compliance.
Why wouldn't I just build this myself?
Yes! You definitely can! If you'd like to build this yourself, there are many lessons learned that you can find in this codebase and feel free to reach out to bounce your ideas and jump start your internal effort.
How do I reuse document libraries across repos?
This is especially useful if you have a micro-servers or many-repo architecture.
Zeeq makes it easy via AGENTS.md or CLAUDE.md:
<!-- Example AGENTS.md once the harness is connect to the MCP -->
Use the following libraries from Zeeq when working in this codebase:
|Library|Purpose|
|--|--|
|`zeeq-app`|(Primary) Canonical coding style, technical best practices, implementation patterns|
|`zeeq-docs`|(Secondary) Architecture, product design, features, user guide|
|`zeeq-ui`|Use when working on `*.vue` files|
Give it the library name and map out when to use which library; let the agent choose when building.