The strongest signal was how rough the first-run experience still is. Multiple people hit auth trouble, model safety refusals, rate limits, and long scans that burned meaningful quota before failing. One user spent about $13 on a scan that stopped after a minute of retrying a per-minute rate limit. Another ran for nearly an hour, used half a weekly Pro allotment, then failed because the repository
HEAD changed during the run. The maintainer did not dispute any of this. He said proper retries, resume support, and better handling of changing checkouts are missing today. That honesty made the release feel real, but it also made clear this is still early software.
A second thread was about what the actual product is. Several people dug into the repository and concluded that the model is only part of the value. The shipped “skills” are plain-English task definitions that tell the model how to inspect code, and the surrounding harness is what makes it useful for a security team. Budget caps, CI gating, historical tracking, and dedup across runs are the sticky parts. That matches how buyers already evaluate security tooling. The model may generate findings, but the product lives or dies on operational fit.
There was also immediate friction around trust and deployment constraints. The tool currently depends on OpenAI access and does not bypass cybersecurity guardrails, so it can refuse to explain a suspected bug unless the user has the right program access. People also asked whether code is uploaded to OpenAI, which makes it a non-starter for some corporate environments. An OpenAI maintainer said official support for local or OpenAI-compatible model endpoints is being worked on, and because the code is open source, motivated users can already swap models themselves. That kept the conversation from collapsing into pure vendor lock-in complaints, but the practical message was simple: if your organization cannot send code to an external model provider, this is not ready for you yet.
github.com