Benchmarking frontier AI models on private, real-world, enterprise codebases.
Today we are releasing Real-SWE, a benchmark that evaluates frontier AI models on private, real-world, enterprise codebases. Each task comes from a private production codebase that we licensed from a real-world company. These are problems their engineers work on, with all the context and complexity that comes with an existing product.
Can a coding agent actually do the work of a software engineer in the real world?
Expert-generated or synthetic tasks can be well designed, but they aren’t the verbatim, actual tasks that engineers in real companies need to do. Our tasks differ on two axes: the underlying coding artifact and specificity of the instruction. Both add complexities that challenge today’s frontier models.
We use native harnesses to reflect how enterprise engineers work in practice, evaluating model-and-harness combinations rather than models in isolation.
Fix invoice billing so each business charges the right tax and exempt customers aren't taxed.
Billing reopens on Monday and every invoice this service issues is coming out untaxed. Each business on the platform settles its tax a different way: some maintain a rate themselves, some want each invoice priced against the buyer's destination by our tax authority provider, and some collect nothing at all, while a customer we hold an exemption for is charged nothing whichever way its business is configured. Pricing a destination means going to the authority with both addresses, the priced lines and the product category that business sells under, on the sandbox or the production authority according to the account the business is on; an address the authority refuses must be reported without stopping the invoice. The rate, the tax and the gross belong on the issued invoice, and once an invoice is settled the sale is filed back to the authority under that invoice's number so the returns reconcile. Invoices between European parties show both sides' VAT registrations. The authority and ledger are available at TAX_JAR_URL , PROD_TAX_JAR_URL and INFLUX_URL .
Tools and services across Real-SWE task environments. Each task exposes only the services its workflow needs.
We selected codebases through a rigorous screening process, focusing on real companies with substantial usage, strong engineering teams, and demanding production workloads. The sample tasks analyzed below come from these codebases, including:
We prioritize code written to meet an actual user or business need over code written solely to create a benchmark task. Production engineering requires understanding existing architecture, preserving behavior that users rely on, and making changes within real operational constraints.
Our tasks describe the change needed, leaving agents to discover implementation details in the codebase and surrounding tools. Any behavior required by the verifier must be stated or reasonably discoverable. This leads to our prompts being slightly underspecified, about par with DeepSWE and Terminal Bench, but specific enough to not omit instructions.
The work is cross-functional and complex: a single change can span multiple parts of the application. Agents must understand existing business logic and company coding patterns while keeping the surrounding system working.
A typical Real-SWE instruction is 1,742 characters.
11 files in Real-SWE, compared with 6 in FrontierCode and DeepSWE.
71.4 % of rollouts under 10 minutes failed, compared with 73.4 % of longer rollouts.
Triaging multiple systems and understanding requirements in codebases riddled with existing business logic and coding patterns is difficult.
Every task is inspired or lifted verbatim from a private, real-world codebase. We find these types of tasks super interesting for three reasons:
Here's an analysis of a small sample of tasks from our benchmark. If you're interested in the sample, request access here：/benchmarks/real-swe/request-access.
Select a task to view model results. Percentages show the overall resolution rate.
Failures are grouped by observed submission behavior using the same taxonomy across models, following DeepSWE：https://arxiv.org/html/2607.07946v1#A3.
One square per rollout: each row is a task, each column a trial, eight trials per task for every model.
Percentages are out of each model's failed runs, not all runs.
Builds on a guess about the system instead of checking it in the workspace.
Leaves out behavior the instruction requires.
Right idea, wired into the surrounding system incorrectly.
Breaks existing behavior while making the change.
Delivers the change somewhere the running application never calls, such as a one-off script.
Each agent was run in an isolated sandbox. All tasks are in Harbor format, and verifiers are injected at grading time. The verifiers are inspired by existing test suites in the codebase or use those tests verbatim.
Scan to open this article