Same AI Model. 40% Cheaper. Here’s How.

0:00 Unreal Labs reports up to 40% lower cost than Codex. Picture an illustrative bug fix. Your agent starts a test and gets back running. It asks the model whether to check again while a relevant source

0:11 file sits unread. That adds a model exchange without a test result. Could the software manage the weight while the agent inspects the file? They kept the same AI model and changed the software

0:20 around it. Why did the bill fall? Waiting for a test and asking a model what to do about that weight are different kinds of work. Our two timelines separate them.

0:30 In Unreal Labs Terminal Bench 4.0 table, Unreal Agent cost $1,428. Codex is leaderboard baseline cost $2,350. Both report a 57.9%

0:41 pass rate. That's a calculated 39.2% cost reduction, which explains the rounded up to 40% headline. These are Unreal Labs own results. The available evidence doesn't establish an

0:52 independent reproduction, and matching pass rates don't prove equal reliability. The comparison uses GPT-6 Astra at X High with Codex and Pi. Claude Code isn't included, and these

1:03 figures don't promise a cheaper Codex subscription. Holding the model setting constant gives us a useful engineering question. What was the model being asked to do between

1:12 useful decisions? Follow our bug fix through the software that passes requests and results between the model and its tools. Suppose we're fixing a formatting function. A test checks its

1:22 output, and the agent needs to read the function source. Reading that file doesn't depend on the test finishing. Checking whether a later fix works will need a fresh verification result. On the

1:31 upper timeline, our test starts and returns running. Suppose the agent makes another model request to decide whether to check again. Now that status is part of another exchange, even though the

1:41 test hasn't supplied a useful result yet. Notice the condition there, another model request. Software can wait or check a process without asking a language model to reason about it. Tool

1:51 runtime alone doesn't tell you how much model work happened. A spinning progress indicator isn't a token invoice. On the lower timeline, Unreal's described approach records that the test is

2:01 running and leaves the operation working in the background. Once it finishes, software adds the completed result to the history and calls the model with something new to consider. Meanwhile,

2:10 the source inspection can proceed because it's independent. By the next useful decision, there's more evidence available. Some operations still have to wait for others though. A model can't

2:20 approve a patch just because an unrelated operation has finished. Software now tracks the unfinished operation and brings information back when there's a reason to reconsider the

2:28 task. Unreal's developers attribute their savings partly to that pattern. Fewer model exchanges with more tool work happening between them. A completion event says something changed.

2:38 Here's the result. A running status says the result isn't ready. Sometimes that status matters, but repeatedly discussing it doesn't make the test finish. The test runner doesn't need a

2:48 motivational interview. That surrounding software is called the harness. Unreal Agent's runner accepts your request and reports events as the work progresses. Its provider and model settings are

2:58 separate, so you can choose which service and model it uses. A model can request a shell command, but application software executes it. Think of that request as a work order. Code around the

3:08 model checks it, starts the operation, stores what happened, and prepares the next input. Each job has a place in Unreal Agent. Follow that test request through Unreal Agent. The coordinator

3:19 records it and routes the work. Next, the tool translator checks the request and turns it into operations. It doesn't open files or run commands. That go as our test runs under the operation

3:30 manager, while the session store keeps the task's history. When the result arrives, the context builder prepares what the model will see next. It records anything left out, cut short, or

3:40 condensed. Finally, the model adapter sends that input to the provider. That's the event loop. Software tracks the work and brings evidence back to the model. Stored history can contain more than the

3:51 next model request. So, there's software managing both execution and context. How much did each change save? Unreal Labs also points to simpler prompts and smaller tool results, but its report

4:02 doesn't separate their contributions. We can't credit asynchronous execution alone with the whole reduction. Back at our formatting bug, the completed test brings failure details and the source

4:12 read brings the function's code. Now, the model can work out which change addresses the mismatch. There's a concrete decision to make with evidence that an unchanged progress status

4:21 couldn't provide. Once a patch is ready, verification needs to check that patched state. Independent reads can overlap, but an earlier test can't prove a later edit works. Otherwise, you've checked

4:32 the code you had before the change and left the actual fix unchecked. Beyond scheduling, the harness can change what comes back from a tool. Imagine our test output includes routine setup messages,

4:43 file listings, and the relevant failure. Sending that whole bundle gives the next model request more input to account for. In our illustration, the bundle gets smaller, but the failing assertion and

4:53 the details needed to understand it stay. Unreal Labs cites smaller tool results as part of its approach. Its available documentation doesn't establish the exact reduction algorithm

5:03 used in those runs or guarantee that every useful detail survives. For the next decision, our model needs the failure and nearby code. Routine setup messages may add little.

5:13 Keeping those messages in the history doesn't mean sending them every time. A test log doesn't need to submit its autobiography with every result. Smaller only helps if the request still supports

5:23 the task. Remove the clue that explains a failure and you could make the next decision worse. I judge output handling by the verified result it helps produce alongside the input it avoids sending.

5:34 So, how does this differ from Codex? Start with its documented interface. Codex is right_ stdin tool can interact with an existing execution session. An empty write can pull that session for

5:46 background output. You can configure how long it waits and limit the output it returns. With polling, the caller requests another update from an operation that's still running. Unreal's

5:56 description emphasizes a different handoff. Record the running state, add the completed result to the conversation when it arrives, then invoke the model. Compare how information gets delivered

6:07 between decisions. Codex also supports parallel tool calls. Our upper timeline doesn't show that Codex always does one thing at a time. Polling and concurrent work can exist in the same system.

6:18 Knowing both are available doesn't tell us how a particular benchmark run used them. Public code shows an available interface, not how often the benchmark version pulled or what those checks

6:27 cost. Today's repository may also differ from the tested revision. Our diagrams explain the possible interactions, they aren't recordings of those benchmark

6:36 runs. OpenAI's API also supports asynchronous tool calls. An application can execute a tool while the model continues independent work, then return the result using the original call ID.

6:47 Async execution isn't exclusive to Unreal Agent. That API capability doesn't establish which configuration the benchmarked Codex used. I describe Unreal's approach as a package,

6:58 scheduling, context preparation, and tool result handling working together. According to its report, that package costs less in these comparisons. Picking one interface feature doesn't explain

7:08 the full difference between the products. Now, separate the clock from the bill. Our test can take time while the model generates nothing new. Model exchanges involve input processing and

7:18 generated output. Infrastructure can have its own charges, too. One task can involve all three, but they need separate accounting. Finishing sooner and costing less are separate

7:28 claims. Overlapping independent operations changes the schedule. Avoiding unnecessary exchanges or reducing input can change model work. These reported

7:37 costs don't tell us how long our illustrative bug fix would take. Prompt caching changes the invoice, too. Successive requests can begin with the same chunk of input called a shared

7:46 prefix. OpenAI documents reusing that chunk at a reduced input rate, so repeated context doesn't necessarily cost the same as new input. Break the model bill into three categories: cached

7:57 input, new input, and generated output. A total input token count combines two categories with different prices. A large context bundle may contain substantial reused input, so its size

8:08 alone won't tell you the dollar amount. Caching doesn't make another exchange free. Reused input gets a reduced rate. New input and generated output still need accounting. The discount has

8:19 boundaries. Fewer turns and fewer input tokens can help explain a lower bill, but they don't add up to a complete invoice by themselves. You also need to know the rates in which input received

8:30 cached pricing. Those details connect the model's work to dollars. Across the other published Codex comparisons, the calculated reductions vary. 28.2% for Sweet Atlas, 16.3% for Deep Sweet, and

8:43 25.7% for ALECL up to points to the largest reported reduction. You shouldn't expect that same discount on whatever task you hand it. Correctness belongs beside those prices. Both

8:55 terminal bench entries report a 57.9% pass rate. Useful context, but your repository brings its own tests and failure cases. Matching benchmark percentages won't tell you whether the

9:05 cheaper setup will handle your particular work equally well. On Sweet Atlas, there's an unresolved difference in the dollar figures. Unreal Labs article lists Codex at $1,303.

9:16 Its linked Harbor overview displays $1,356.18. The available evidence doesn't reconcile those two amounts. Codex's overview shows 372 finished

9:26 trials, 354 completed, and 18 errors. Its average reward is 0.60. You can see how the run is recorded, but those fields don't explain why the displayed inference cost differs from

9:38 the article's total. Unreal Agents overview also shows 372 finished trials, 356 completed, and 16 errors with average reward 0.63. It reports a 90% cash hit rate. Those

9:51 are useful run details, but cash hit rate itself isn't a dollar total. Unreal's overview supplies no per trial inference cost. Together, these pages support the existence of the published

10:01 runs, but they don't independently verify the article's Unreal dollar total. Being able to inspect a run and being able to reconcile its bill are different levels of evidence. Trial

10:11 filtering, errors, pricing, or aggregation could affect a cost comparison. Nothing on the available pages establishes which, if any, explains this difference. I'd leave the

10:21 discrepancy visible instead of picking a tidy explanation that the records don't support. For your budget, that means comparing cost and correctness together. Unreal's architecture gives us a

10:30 concrete explanation to examine. Its reported percentages give us something to compare against, while the accounting gaps are a reason to measure your own cost before budgeting around

10:40 them. Unreal Agents repository has an MIT license attributed to Unreal Labs. You can inspect and adapt a harness under that license. Model inference and

10:49 hosting remain separate costs. The license file won't pick up the inference tab. I'd start with representative tasks whose results you can check keeping the model setting consistent across

10:58 harnesses. Change both the model and the software around it at once and you've made any difference harder to explain. Give each setup work to finish. Record whether each task reaches an acceptable

11:09 result, what errors occur, and what inference cost under the same accounting rules. Keep elapsed time separate. A cheaper attempt that leaves the bug unresolved hasn't delivered the same

11:19 thing as a checked fix. Keep cached input, new input, and generated output visible in that accounting, too. Separating them helps explain dollar differences that raw token totals can

11:29 hide. If you include infrastructure charges, include them consistently for both setups, so you're comparing the same kinds of costs. Then inspect what happens between useful

11:39 decisions. Watch for unchanged statuses reaching the model, independent operations that could overlap, and missing evidence in the next request. Each gives you somewhere specific to

11:49 investigate without assuming one favorite feature explains the headline saving. If you pay for coding agent inference, unreal agent is worth evaluating on

11:57 tasks you can verify. Compare the checked results and count costs the same way for both setups. Your model can stay the same while the machinery around it changes the

12:06 requests, the context, and the bill. That's why the harness deserves scrutiny. On my tasks, how much am I spending to reach a verified result?