Model providers · Warpway

Which models review your code, what they receive, and why your code is not used for training.

Warpway uses large language models to analyze changes, plan reviews, investigate them through lenses, check human answers and re-check those answers after new commits. This page explains which models, what they receive, what they never decide, and how your code is protected.

The default model

Every step of a review uses GPT-6 Sol (model id gpt-6-sol) from OpenAI, through OpenAI's Responses API with response storage turned off:

Step	What the model does
Change analysis	Summarizes the change, affected subsystems, risk areas and semantic categories. Categories that file paths reveal, such as migrations, are added by code even if the model misses them.
Review planning	Adds lenses, focus points and context files to the lenses your policy selects. It cannot drop a lens your policy selects or change which tools a lens may use.
Lenses	Investigate with read-only tools and report findings, questions and evidence.
Arbitration	Helps merge overlapping questions from different lenses into one, and code re-checks every merge. Findings are deduplicated and checked against their evidence by code alone.
Answer checking	Decides whether a human answer actually settles a question, and drafts follow-ups. Button choices and vague replies such as "sounds fine" are handled by rules before any model call.
Answer revalidation	After a new commit, checks whether an earlier answer still holds for the changed code. If the code an answer relied on is unchanged, the answer is reused without a model call.
Organization knowledge	Picks the approved organization rules that are relevant to a change, and drafts reusable rules from answers for an Admin to approve.

Warpway can assign a different model to a step and configure fallback models that are tried only when the primary model fails with a temporary error. Model choices are set by Warpway for the service, not per customer. Every review records which model actually served each call and which prompt version produced each result. Warpway's review engine also runs on Anthropic's Claude models; the hosted service uses OpenAI.

What the model never decides

Whether your policy is satisfied. Deterministic code evaluates the policy from stored results.
Whether a pull request may be auto-approved. Every eligibility condition is checked by code.
What a lens may access. Tool scope and allowlists come from your configuration, not from model output.
What runs in your CI. Only the runtime profiles you approve.

Lenses record an internal confidence that is used only for evaluation. Warpway never presents it as the probability that a change is safe, and never approves because of it.

What the model receives

Each step receives only what it needs for the pull request at hand:

the diff and the file excerpts a lens reads with its tools;
the pull request title, description, labels, comments and reviews, and its commit messages;
the history and blame of files a lens examines;
linked issues, CI results and runtime verification results;
your lens instructions, rules and relevant organization knowledge;
the people Warpway may ask, as GitHub usernames and teams from CODEOWNERS and the pull request, and the targets in your routing settings, so the plan can suggest who to ask;
human answers to the pull request's questions, including the follow-up conversation when an answer is checked.

All repository, pull request, ticket and Slack text is passed as clearly delimited untrusted data. See Security.

Training

Warpway does not train models on your code, your pull requests or your team's answers.
OpenAI does not train its models on data sent through its API unless the customer opts in, and Warpway has not. OpenAI's enterprise privacy page describes these commitments.

Retention at the model provider

Warpway sends every request with OpenAI's response storage turned off, so OpenAI does not keep responses for later retrieval; reasoning carried between the steps of one investigation travels encrypted with the request. OpenAI may keep API inputs and outputs for up to 30 days to monitor for abuse, then deletes them. OpenAI's enterprise privacy page has the current details. Zero data retention is available for eligible uses; if your organization requires it, contact us before installing.

What Warpway stores about model calls

For every model call Warpway stores the model, provider, prompt version, token counts, cost, duration and status, for observability and cost accounting. It does not store prompt text or raw model responses. The structured results of a review (lens results, findings, human tasks and evidence) are stored as review records; see Data handling.

When a model fails

Each model request has a time limit, 240 seconds by default. Temporary errors such as rate limits and overloaded servers are retried with backoff, then any configured fallback model is tried. Responses are validated against a strict schema; invalid output goes back to the model with the problems listed, up to twice. What happens next depends on the step:

A lens that still cannot produce a valid result is Incomplete, and the review does not pass. A provider outage never turns a lens Cleared.
If change analysis or planning fails, the review continues with a path-based analysis and the lenses your policy selects, and those lenses still fail closed.
If checking an answer fails, the task stays open and the check is retried. If re-checking an earlier answer fails, the question is asked again.

Changes to models and prompts

Prompts are versioned, and every model call records the prompt version it used. Warpway keeps an evaluation suite of realistic pull requests, including prompt-injection attempts and changes that must not be cleared; its central measure is how often a lens clears something it should not have.

Your own model key

Bring-your-own-key, which would let an organization route Warpway's model calls through its own provider account, is planned for the Enterprise plan.