Greptile Says GPT-6 Astra Runs Apps to Test Pull Requests, per OpenAI Customer Story
OpenAI's October 26 customer story quotes Greptile's CEO saying GPT-6 Astra's computer use lets agents run a pull request's app, resize a browser and simulate users. It also cites Daybreak security and a Codex knowledge-base link. The page gives no detection rate, cost or benchmark.
Greptile describes testing pull requests by running the app with GPT-6 Astra
On October 26, OpenAI published a customer story about Greptile, a company that builds AI agents to review and test code changes. The story says Greptile uses GPT-6 Astra to test user workflows, OpenAI's Daybreak for security, and Codex to reduce rework. Nearly every claim comes from Greptile's co-founder and chief executive, Daksh Gupta, and the page is OpenAI marketing. It contains no benchmark, error rate or cost figure. It is useful as a description of a design, not as evidence of results.
Testing behavior, not only reading code
The central idea is that reading a diff cannot reveal every defect. Gupta gives an example: a button that disappears when a site is viewed on an iPhone. According to the story, Greptile can start a development server for a pull request, resize the browser to a phone-sized viewport, and simulate a user moving through the application. The model's visual understanding lets it inspect the screen and notice the missing button. Gupta credits GPT-6 Astra's computer use, meaning the model's ability to operate software through the screen, and says a human QA firm testing every change is "impractically slow" at the pace models now allow. The story does not say how many defects this finds, how many alerts are false, or how long a run takes.
Security and the shared knowledge base
On security, Gupta says stronger models make it easier for attackers to exploit applications, so even companies that were not typical targets are at risk. He says Greptile uses Daybreak to give customers defenses more sophisticated than the attackers' offense, and that it does so "in a way that is very safe". No technical detail follows. The story then describes Greptile's Knowledge Base, which indexes a company's codebase and documents how it works in a form that people and agents can read. Greptile exposes this to Codex through a Model Context Protocol (MCP) server so that generated code follows existing patterns. Gupta says thousands of customers have connected Codex to the knowledge base. He says the team tracks how often AI-written code is reverted, and that fewer reverts happen when agents have context. No revert rates are given.
What to ask before relying on this
The story closes with Gupta's interest in "Ultrafast", which he sees as a way to speed up development. The page does not define what it is. Readers evaluating a similar tool might ask for measured detection and false-alarm rates on their own repositories. Another point matters for security: running a pull request's code in a development server and driving a browser against it means executing code that has not yet been reviewed. These are the reader's questions, not claims in the story. The sandbox, the data the model can see and the cost per run should be clear before such a system touches a private codebase.
Sources
FAQ
What does Greptile say it does with GPT-6 Astra?
Greptile's CEO says its agents can start a development server for a pull request, resize the browser to a phone-sized viewport, simulate a user and spot problems such as a button that disappears on an iPhone. The model's computer use and visual understanding make this possible, according to him.
Does the page prove it finds more bugs?
No. It is an OpenAI customer story with no benchmark, detection rate, false-alarm rate or cost. The claims about fewer reverts and thousands of customers connecting Codex come from Greptile's CEO and have no stated baseline. Treat the page as a vendor-approved description, not independent evidence.
What should teams ask before using such a tool?
These are editorial questions, not claims from the story: measured detection and false-alarm rates on their own repositories, what data the model sees, cost per run, and how the sandbox isolates code from an unreviewed pull request. Each should be answered with measurements before adoption.