Paper deep dive
Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?
Zuodong Xiang, Yike Zhang, YueMing Zhang, Hailu Xu
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%
Last extracted: 7/28/2026, 3:38:25 AM
Summary
This study evaluates the effectiveness of cross-model LLM code review workflows using Claude Opus 4.7 and Codex GPT-5.5 on LiveCodeBench tasks. The results demonstrate an asymmetric benefit: Claude Opus 4.7 significantly improves the pass rate of Codex GPT-5.5 drafts (from 71.6% to 89.7%), whereas Codex GPT-5.5 reviewing Claude Opus 4.7 drafts degrades performance (from 91.4% to 82.8%). The authors conclude that using Claude to review Codex is a useful pairing, while the reverse is not.
Entities (5)
Relation Signals (4)
Codex GPT-5.5 → degrades → Claude Opus 4.7
confidence 95% · Codex GPT-5.5 reviewing Claude Opus 4.7 drafts drops the pass rate from 91.4% to 82.8%
Claude Opus 4.7 → improves → Codex GPT-5.5
confidence 95% · Claude Opus 4.7 review raises Codex GPT-5.5 drafts from 71.6% to 89.7%
LiveCodeBench → usedforevaluation → Code Review
confidence 90% · The experiments use LiveCodeBench... to approximate a software practitioner's workflow
Claude Opus 4.7 → outperforms → Codex GPT-5.5
confidence 85% · Claude Opus 4.7 is the strongest solo writer in the sample... Claude Opus 4.7 solo is already at 91.4%
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Developers increasingly use two coding agents together: one writes a draft, and the other reviews it. However, it is not clear whether the pairing is worth its cost and time, or whether the order of the pairing matters. We run a controlled experiment on 116 recent hard and medium lcb tasks with Claude and Codex across six conditions to approximate a software practitioner's workflow: both solo baselines, both cross-model orderings, and both same-model orderings. The reviewer sees the problem and the writer's draft but cannot execute tests, which approximates a code review step. Claude review raises Codex drafts from 71.6% to 89.7% ($p_{BH}=.001$); Codex self review raises them to 84.5% ($p_{BH}=.022$). The reverse direction does not pay off: Codex reviewing Claude drafts drops the pass rate from 91.4% to 82.8% ($p_{BH}=.046$), and Claude self review leaves the 91.4% baseline unchanged. Our evaluation indicates that the useful pairing is asymmetric: use Claude to review Codex, not the other way around.
Tags
Links
- Source: https://arxiv.org/abs/2607.21656v1
- Canonical: https://arxiv.org/abs/2607.21656v1
Trouble viewing inline? Open PDF directly →
Full Text
50,447 characters extracted from source content.
Expand or collapse full text
Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa? Zuodong Xiang University of California, Davis USA shawnzxiang@gmail.com Yike Zhang Johns Hopkins University USA zykk0330@gmail.com YueMing Zhang California State University, Long Beach USA Simon.Zhang01@student.csulb.edu Hailu Xu California State University, Long Beach USA hailu.xu@csulb.edu Abstract Developers increasingly use two coding agents together: one writes a draft, and the other reviews it. However, it is not clear whether the pairing is worth its cost and time, or whether the order of the pairing matters. We run a controlled experiment on 116 recent hard and medium LiveCodeBench tasks with Claude Opus 4.7 and Codex GPT-5.5 across six conditions to approximate a software practi- tioner’s workflow: both solo baselines, both cross-model orderings, and both same-model orderings. The reviewer sees the problem and the writer’s draft but cannot execute tests, which approximates a code review step. Claude Opus 4.7 review raises Codex GPT-5.5 drafts from 71.6% to 89.7% (푝 퐵퐻 = .001); Codex GPT-5.5 self review raises them to 84.5% (푝 퐵퐻 = .022). The reverse direction does not pay off: Codex GPT-5.5 reviewing Claude Opus 4.7 drafts drops the pass rate from 91.4% to 82.8% (푝 퐵퐻 = .046), and Claude Opus 4.7 self review leaves the 91.4% baseline unchanged. Our evaluation indicates that the useful pairing is asymmetric: use Claude Opus 4.7 to review Codex GPT-5.5, not the other way around. CCS Concepts • Computing methodologies→Intelligent agents;• Software and its engineering→ Software verification and validation. Keywords Agentic Coding, LiveCodeBench, Self Code Review, LLM, Claude, Codex ACM Reference Format: Zuodong Xiang, Yike Zhang, YueMing Zhang, and Hailu Xu. 2026. Cross- Model LLM Code Review: Should you use Claude to review Codex or vice versa?. In Proceedings of Agentic Software Engineering (SE 3.0): The Rise of AI Teammates (Agentic SE @ KDD ’26). ACM, New York, NY, USA, 9 pages. https://doi.org/10.1145/n.n This work is partially supported by US NSF Award #2436427. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. Agentic SE @ KDD ’26, Jeju, Korea © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-x-x-x-x/Y/M https://doi.org/10.1145/n.n 1 Introduction Many coding workflows now involve more than a single LLM call. A developer asks one agent to write a draft and a second agent to review it before the change lands, and the second pass starts to behave like a software engineer reviewing code. The two arrange- ments we see most often in practice are Claude Opus 4.7 [1] writing with Codex GPT-5.5 [28] reviewing, and the reverse, with Codex GPT-5.5 writing and Claude Opus 4.7 reviewing. Each pairing can change the workflow’s final result. A different model, commonly equipped with different knowledge and expertise, is now respon- sible for catching things that the first one missed. But it can also cause regressions, replace a working solution with a worse one, or simply add cost and latency without measurable benefit. Today’s code generation leaderboards rank single models in isolation. They do not address which of two available agents should write, which should review, whether the second pass is worth its cost, or which direction the pairing should run to yield the best correctness. Claude Opus 4.7 writing and Codex GPT-5.5 reviewing is not the same workflow as the reverse, even though the two models involved are identical. We study this as a role assignment problem between a writer and a reviewer. The setup approximates a software engineer’s workflow: a single review pass with no execution feedback, so the measured effect is the review intervention itself rather than tool use, iteration, or memory of earlier attempts. The reviewer reads the problem statement and the writer’s draft and writes a final program; it cannot run the code or query a test runner. This is also commonly referred to as static review: the pre-CI inspection step a developer or code review bot performs before any tests run. The experiments use LiveCodeBench, a continuously updated benchmark of self contained competitive programming problems sourced from recent online judges, designed to reduce the risk of contamination in code evaluation [15]. All problems we use were released after 2025, after the training cutoffs of Claude Opus 4.7 and Codex GPT-5.5, so neither model could have memorized their solutions during training. Each task is a single file Python problem with a problem statement, optional starter code, and a hidden test suite. Tasks carry difficulty labels (easy, medium, hard), and we use only the hard and medium difficulty tiers to approximate real life software engineering tasks worth using agents. We pool the two difficulty tiers and compare six conditions: Claude Opus 4.7 solo, Codex GPT-5.5 solo, Claude output reviewed by Codex, Codex arXiv:2607.21656v1 [cs.SE] 22 Jul 2026 Agentic SE @ KDD ’26, August 10, 2026, Jeju, KoreaZuodong Xiang, Yike Zhang, YueMing Zhang, and Hailu Xu output reviewed by Claude, Claude output reviewed by Claude, and Codex output reviewed by Codex. LiveCodeBench fits this question well because the same problem can be evaluated repeatedly under different writer and reviewer assignments against a common hidden test evaluator, which isolates the review pass without changing the task distribution. All writer and reviewer turns use the vendors’ high reasoning effort setting, which uses more tokens, cost, and latency than medium effort. We report pass rate together with reviewer fixes, regressions, latency, and cost. In this paper, we focus on the following questions: RQ1. Does a reviewer pass improve overall correctness? RQ2. Does the value of a reviewer pass depend on which model writes and which model reviews? RQ3. When does the reviewer step fix the draft, and when does it regress it? RQ4. Are correctness gains worth added cost and latency? Review effectiveness in our experiments turns out to be asym- metric. Claude Opus 4.7 is the strongest solo writer in the sample, Claude Opus 4.7 reviewing Codex GPT-5.5 drafts recovers most of the gap between Codex GPT-5.5 solo and Claude Opus 4.7 solo, and Codex GPT-5.5 reviewing Claude Opus 4.7 drafts makes the pipeline worse. We analyze this asymmetry through paired correct- ness tests, fix/regression counts, and cost-latency trade-offs, then derive a workflow recommendation: review is most useful when the initial draft comes from Codex GPT-5.5. 2 Background and Related Work 2.1 Code generation benchmarks Code generation evaluation has usually been organized around standalone model performance. HumanEval made functional cor- rectness a central measure for generated code [6], and MBPP ex- tended this style of evaluation to short Python programming tasks [2]. APPS moved the setting toward harder programming-challenge problems [12], and AlphaCode showed that large-scale generation and filtering can reach nontrivial competitive programming per- formance [19]. LiveCodeBench addresses benchmark saturation and contamination by collecting recent coding contest problems over time from LeetCode, AtCoder, and Codeforces, tagging each problem with its public release date [15]. The release date metadata lets evaluators score a model only on problems published after its training cutoff, which controls for the data leakage documented on older static benchmarks. LiveCodeBench also reports several evaluation scenarios beyond code generation, including self repair, code execution, and test output prediction. Prior work also argues that quality should be reported together with efficiency rather than in isolation [10,17,32,37]. This mat- ters even more for review workflows because a reviewer pass adds another model call, more tokens, and more latency. We therefore treat pass rate, cost, latency, fixes, and regressions as a set of mea- surements rather than a leaderboard number. 2.2 Iterative refinement and self debug Self-Refine and Reflexion study a single model that improves its own output through feedback turns [24,33]. Self-Debug teaches a model to repair its own code from execution traces [7]. Olausson et al. ask whether self-repair is a silver bullet for code generation and find that the gain depends on whether the repair model is meaningfully stronger than the draft model [27]. On HumanEval and APPS with Code Llama, GPT-3.5, and GPT-4, same model self repair produces only modest accuracy improvements because it is bottlenecked by the model’s ability to provide useful feedback on its own code; the largest gains appear when a stronger model repairs a weaker model’s drafts, and human level debugging substantially outperforms self generated feedback. Our same model conditions will reproduce this finding but with execution feedback removed. Recent work also shows that memory can change LLM agent behav- ior [23], and that LLM outputs exhibit non-trivial variance across repeated runs even under fixed conditions [11,40]. Our experiment isolates a related but distinct case: the reviewer is a different model, runs once, has no execution feedback, and has no memory of prior attempts. This removes iteration and tool use, so that the measured effect can be attributed to the cross-model review pass itself. 2.3 Multi agent and agentic coding CodeT and LEVER use generated tests or learned verification to improve code outputs [5,26]. Multi agent debate work shows that two language-model instances can improve factuality or divergent thinking by critiquing each other [9,21]; this is a natural framing of two models reviewing one another, although that line studies open-ended reasoning rather than executable programs. Multi-LLM combinations have also been used in domain forecasting tasks such as financial sentiment [39], robot tasks [36,38], and LLMs have been integrated with reinforcement learning for portfolio optimization [35]. ChatDev and MetaGPT assign software-development roles across multiple agents [13,30]. AgentCoder and CodeCoR study role-based coding workflows [14,29]. Other work studies capability composition across multi-agent pipelines from a safety angle [16]. In contrast, our workflow has one writer, one static reviewer, no generated tests, and no execution feedback for the reviewer. 2.4 Code review and LLM reviewers Modern code review supports defect detection, knowledge transfer, and shared code quality [3,31]. In human teams, review is not only a bug finding and for readability, it is also a coordination point where a second engineer decides whether to ship as is, lightly edit, or reject a proposed change. This role structure is similar to what multi agent coding workflows are beginning to imitate when one LLM drafts code and another LLM inspects it. Prior work studies review-comment generation and code re- finement [20,34]. Recent LLM-focused work finds that apparent success on code refinement often reflects memorization rather than comprehension [22], and that LLM reviewers can systematically overcorrect on requirement conformance [18]. These findings mo- tivate a stricter evaluation target for LLM review. It is not whether the reviewer produces plausible comments, but whether the final submitted program is more correct than the writer’s original draft. We measure the correctness of the final program after a review pass and separately count reviewer fixes and regressions. Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?Agentic SE @ KDD ’26, August 10, 2026, Jeju, Korea Listing 1: Writer prompt template You are an expert competitive programmer. Solve the following programming problem. PROBLEM: problem starter_code Your task: 1. Produce a complete, runnable Python solution 2. Handle edge cases; optimize first for correctness, then for performance 3. Output only the final solution inside <solution> tags <solution> # final python code here </solution> Listing 2: Reviewer prompt template You are an expert code reviewer. Review the following solution to a competitive programming problem. PROBLEM: problem starter_code SUBMITTED SOLUTION: writer_output Your task: 1. Identify any bugs, incorrect logic, missing edge cases, or inefficiencies 2. Produce a final corrected solution - either the original if it is correct, or an improved version 3. Do NOT run or test the code; reason purely from code inspection Output only the final solution inside <solution> tags. Do not include explanations outside the tags. <solution> # final python code here </solution> 3 Methodology 3.1 Task Setting and Prompts Each task is a hard or medium LiveCodeBench code generation problem. We did not include the easy category given they are trivial for LLMs and software practitioners to solve at this point. The writer receives the problem statement, any starter code, and is asked for a complete Python solution inside <solution> tags. In a solo baseline, a parsed writer draft is submitted directly to the LiveCodeBench evaluator. In a reviewed condition, the same writer artifact becomes the submitted solution shown to a reviewer model, which also receives the original problem and starter code. The reviewer is instructed to inspect the draft for bugs, missing edge cases, incorrect logic, and inefficiencies, then write a final program inside<solution>tags: either the original draft if it is correct or a corrected version if it is not. The reviewer cannot run the code, query a test runner, see hidden tests, or inspect execution traces. This is the static review setting introduced in Section 1. All final artifacts are parsed through the same tag-based extractor be- fore evaluation, so the measured difference between conditions is the added review pass rather than a change in evaluator or output Table 1: Experimental conditions. All turns use high reason- ing effort. IDWriterReviewerRole type AClaude Opus 4.7–Solo baseline OCodex GPT-5.5–Solo baseline AOClaude Opus 4.7Codex GPT-5.5Cross-model OACodex GPT-5.5Claude Opus 4.7Cross-model AAClaude Opus 4.7Claude Opus 4.7Same-model OOCodex GPT-5.5Codex GPT-5.5Same-model parser. The prompt templates are fixed across models and con- ditions. The artifact includes the exact prompt files and per task prompt hashes. Listings 1 and Listing 2 define the two role-specific prompt tem- plates used throughout the study. The writer prompt instructs the model to solve the competitive programming task from the pro- vided problem statement and starter code, prioritizing correctness, edge-case handling, and computational efficiency. To ensure a uni- form output artifact, the writer is required to return only a complete runnable Python solution enclosed within <solution> tags. The reviewer prompt receives the same task specification to- gether with the writer generated solution. Rather than providing feedback or commentary, the reviewer performs a static code re- view and must return a final executable program. Reviewers are explicitly instructed to reason solely from code inspection and are not allowed to execute or test the program. Both prompts enforce an identical output format consisting ex- clusively of a Python solution wrapped in<solution>tags. This design removes variation arising from the explanatory text and allows all experimental conditions to be evaluated using the same downstream extraction and scoring pipeline. Task-specific content is injected through placeholders corresponding to the problem state- ment, the starter code, and, when applicable, the draft produced by the writer. Holding the task specification and output format con- stant while varying only the role assignment and model identity isolates the effects of review and cross-model collaboration. 3.2 Conditions Table 1 lists the six conditions. Throughout the paper we use com- pact labels: "A" for Anthropic Claude Opus 4.7, "O" for OpenAI Codex GPT-5.5. Two-letter labels are in writer then reviewer order, so AO is Claude output reviewed by Codex, and OA is Codex output re- viewed by Claude. The solo baselines give us standalone perfor- mance. The two same-model conditions tell us whether a second pass helps at all when there is no model diversity. The two cross- model conditions answer the model role assignment question and let us see whether direction matters. 3.3 Execution and Cost Accounting The runs usedclaude-opus-4-7through Claude Code 2.1.50 and gpt-5.5through Codex CLI. Both runs setreasoning.effort = high. Each turn had a 3,000-second CLI timeout. A timed-out turn Agentic SE @ KDD ’26, August 10, 2026, Jeju, KoreaZuodong Xiang, Yike Zhang, YueMing Zhang, and Hailu Xu Table 2: Pooled complete case metrics across hard and medium LiveCodeBench tasks.SIDis the change in Pass Rate relative to the writer’s solo baseline; Reg. rate is the share of tasks where the writer-only baseline passed but the reviewed condition failed. ConditionPassPass Rate [95% CI]SIDCost/taskLatencyReg. rate Baselines A: Claude Opus 4.7 solo106.914 [.862,.957]–$.22686.2s– O: Codex GPT-5.5 solo83.716 [.629,.793]–$.19038.5s– Reviewed conditions AO: Claude Opus 4.7 reviewed by Codex GPT-5.596.828 [.759,.897] −.086$.382118.0s.112 OA: Codex GPT-5.5 reviewed by Claude Opus 4.7104.897 [.836,.948] +.181$.443112.4s.043 A: Claude Opus 4.7 reviewed by Claude Opus 4.7106.914 [.862,.957] +.000$.389135.8s.026 O: Codex GPT-5.5 reviewed by Codex GPT-5.598.845 [.776,.905] +.129$.31267.9s.052 was retried once with a doubled timeout. A task that still ended incomplete (CLI error, timeout, parse failure, or empty final artifact) was retried up to four attempts. The harness records raw outputs, final artifacts, prompt hashes (SHA-256), CLI versions, timestamps, parse metadata, retry metadata, token counts, costs, and evaluation results. API costs are computed from token counts and a pricing configuration pulled from the official websites. 3.4 Sample, Metrics, and Statistical Tests We combine the complete case portions of two LiveCodeBench runs: one hard slice and one medium slice. Complete case analysis restricts the data to tasks for which all six conditions produced a valid evaluated artifact: a non-null evaluation result with no CLI error, no timeout, no parse failure, no budget-exceeded flag, and a non- empty final program. The pooled complete case analysis contains 116 tasks, with task identifiers namespaced by difficulty before pooling. This is a bounded controlled sample, not a leaderboard- scale evaluation; the artifact retains the per task metadata for future audits. Let푦 푡푐 ∈ 0,1indicate whether task푡passed under condition 푐. The pass rate is 푃푅 푐 = 1 |푇 푐 | ∑︁ 푡∈푇 푐 푦 푡푐 .(1) For a two-pass condition푐with writer model푤, the improvement delta compares the condition to the corresponding solo writer base- line 푏(푤): SID 푐 = 푃푅 푐 − 푃푅 푏(푤) .(2) We also report average cost per task, latency, and reviewer-induced regressions. Regressions are tasks where the writer-only baseline passes but the reviewed condition fails. Reviewer fixes are tasks where the writer-only baseline fails but the reviewed condition passes. We report bootstrap 95% confidence intervals for complete case pass rate. The McNemar test [25] compares two binary outcomes on the same set of items by counting only the items where the two conditions disagree; it is the standard paired test for matched 0/1 outcomes such as task-level pass/fail across two conditions. For conditions 푎 and 푏, let 푛 10 = ∑︁ 푡 1푦 푡푎 = 1,푦 푡푏 = 0, 푛 01 = ∑︁ 푡 1푦 푡푎 = 0,푦 푡푏 = 1. (3) Under the null that the two conditions are equally likely to win on discordant tasks,푋 ∼ Binom(푛 10 +푛 01 ,1/2). We use the exact two-sided McNemar p-value, 푝= min 1, 2 min 푃푋 ≤ min(푛 10 ,푛 01 ), 푃푋 ≥ max(푛 10 ,푛 01 ) . (4) For paired correctness comparisons, we apply BH (Benjamini-Hochberg) correction [4] across all pairwise contrasts generated by the analy- sis script. If푝 (1) ≤·≤ 푝 (푚) are the sorted p-values, the adjusted value is 푞 (푖) = min 푗≥푖 1, 푚 푗 푝 (푗) ,(5) with monotone adjustment from largest to smallest p-value. Table 4 reports the contrasts most relevant to the role assignment argu- ment. To understand whether the apparent writer and reviewer interaction is statistically supported beyond the per writer effects, the artifact also reports a direct AO versus OA paired contrast and the underlying per task pass vectors. 4 Results Model inference ran on vendor hosted infrastructure through Claude Code and Codex CLI. The program is ran locally using a MacBook Air with Apple M4 chip and 16 GB RAMP (2025) that handled or- chestration, file I/O, logging, parsing, and wall-clock timing of the remote calls. The results section is organized around the four research ques- tions. Table 2 gives the complete assessment for every condition; Table 3 collapses those rows into the writer-by-reviewer view; Ta- ble 4 tests paired differences on the same 116 tasks; and Figures 1–2 separate correctness gains from the cost of obtaining them. Table 5 shows various inspected cases that contained fixes and regressions. 4.1 RQ1: Does a reviewer pass improve correctness? Table 3 summarizes the headline result and Table 2 gives the un- derlying numbers. The main takeaway is that the answer to RQ1 changes depending on who wrote the draft and reviewed the code. Codex GPT-5.5 solo lands at 71.6%; the same drafts run through Claude Opus 4.7 review jump to 89.7%, and through Codex GPT-5.5 review to 84.5%. Claude Opus 4.7 solo is already at 91.4%; Claude Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?Agentic SE @ KDD ’26, August 10, 2026, Jeju, Korea Table 3: Pass rate for each writer and reviewer pair, with the delta against the writer’s solo baseline. Rows: who wrote. Columns: who reviewed. Claude as reviewer is always helpful or neutral; Codex as reviewer is helpful only when the draft is its own. Reviewer WriterClaudeCodex Claude (solo 91.4%)91.4% (±0 p)82.8% (−8.6 p) Codex (solo 71.6%)89.7% (+18.1 p)84.5% (+12.9 p) Table 4: Selected complete case McNemar tests over the shared 116 tasks. Each row compares two conditions on the same set of tasks. “First only” is the number of tasks the first condition passed and the second failed; “Second only” is the reverse.푝 퐵퐻 is the BH adjusted p-value across all pairwise contrasts. ComparisonFirst onlySecond only푝 푝 퐵퐻 Per writer reviewer effects OA vs O265.0002.0010 O vs O216.0059.0222 AO vs A313.0213.0456 A vs A331.00001.0000 A vs AO122.0129.0323 Direct between-orderings contrast AO vs OA513.0963.1444 Opus 4.7 reviewing itself stays at 91.4%, and handing Claude Opus 4.7’s draft to Codex GPT-5.5 actually drops it to 82.8%. The size of the two positive review effects also shows that the reviewer’s contribution is bounded by its relative capability rather than guaranteed by simply adding a second pass. OA adds 21 net passes over Codex GPT-5.5 solo (104 versus 83 passing tasks), putting a workflow that begins with a Codex GPT-5.5 draft within two passing tasks of Claude Opus 4.7 solo. O adds 15 net passes over Codex GPT-5.5 solo while keeping cost and latency lower than OA. In contrast, AO loses 10 net passes relative to Claude Opus 4.7 solo and has the highest regression rate in Table 2. 4.2 RQ2: Writer–Reviewer Role Assignment Table 4 reports the corresponding paired McNemar tests. For Codex GPT-5.5 drafts, both reviewers help after BH correction: OA im- proves over O by 18.1 p (푝 퐵퐻 = .0010) and O by 12.9 p (푝 퐵퐻 = . 0222). For Claude Opus 4.7 drafts, same-model review is ineffective, while cross-model review by Codex GPT-5.5 is significantly worse than Claude Opus 4.7 solo (푝 퐵퐻 = .0456). A versus AO is also significant (푝 퐵퐻 = .0323), indicating that the choice of reviewer matters even when the writer is already the stronger of the two. The direct AO vs OA contrast does not survive BH correction (푝 퐵퐻 = .1444), so we do not claim that the two cross-model or- derings are statistically separable as standalone conditions on this sample. 4.3 RQ3: Fixes versus Regressions A pass rate hides two different reviewer behaviors: a reviewer can fix a failing draft, or break a passing one. Figure 1 unpacks them, grouping conditions by writer with explicit fix and regression counts on the right. The contrast that is hardest to miss is between the two cross-model orderings: OA fixes 26 of Codex GPT-5.5’s failures while regressing only 5 of its successes (net+21), and AO does the opposite, fixing only 3 of Claude Opus 4.7’s failures but breaking 13 of its successes (net−10). The two same-model conditions sit between these poles: O is broadly positive (21 fixes, 6 regressions), and A is at the noise floor (3 fixes, 3 regressions). In addition, we read through representative fixes and regressions by hand. The supporting evidence for these examples lives in the artifact records; each record stores the writer artifact, reviewer artifact, final artifact, prompt hashes, and pass or fail outcome. The pattern labels below are interpretive and might not be reproducible in repeated runs. Table 5 shows representative cases at the task level. Fixes in- clude Problem 3688, where O repairs its own segment-tree state, andabc394_f, where the O reviewer replaces a failing component count with a tree dynamic program. Regressions include Problem 3717 (AO replaces a passing sorted-list median window with a failing heap-based rewrite),arc191_a(A rewrites the boundary handling of an already passing solution), andabc389_f(O deletes a segment-tree range guard protecting an edge case). 4.4 RQ4: Cost and Latency Trade-Offs A review pass is not free, as it doubles the API call count and adds tens of seconds of wall-clock latency. The cost-per-token and la- tency overhead of additional LLM passes has motivated a broad line of work on efficient LLM deployment [8]. Figure 2 shows whether that extra spend buys anything. Each arrow starts at a writer’s solo point and ends at one of its reviewed conditions, so the slope of the arrow tells you whether the extra cost or latency on the horizontal axis bought accuracy on the vertical axis. For Codex GPT-5.5 as writer, both arrows go up and to the right. O buys 12.9 pass rate points for an extra $0.12 per task and 29 seconds of latency; OA buys 18.1 points for an extra $0.25 and 74 seconds. O is the cheap, fast option. For Claude Opus 4.7 as writer, neither arrow justifies the spend.퐴→퐴is flat-right: $0.16 and 50 seconds for zero accuracy gain.퐴→퐴푂points down-and-right: $0.16 and 32 seconds for an 8.6-point accuracy loss. Overall, Claude Opus 4.7 solo sits on the Pareto frontier and no reviewed condition matched or exceeded it in accuracy. A matches A’s pass rate while adding 72% to cost and 58% to latency; every other reviewed condition has lower accuracy than A. The cost versus accuracy decision worth thinking about is therefore confined to the Codex GPT-5.5 writer column. 5 Discussion 5.1 Claude self review versus Codex self review The O and A rows in Table 2 and Figure 1 apply the same operation, “review your own draft”, to the two writers, and yet produce opposite outcomes. The most plausible explanation is that the two models do different amounts of internal verification on the Agentic SE @ KDD ’26, August 10, 2026, Jeju, KoreaZuodong Xiang, Yike Zhang, YueMing Zhang, and Hailu Xu Table 5: Representative inspected cases from artifact records. These examples are not a coded taxonomy but illustrate the mechanisms behind the aggregate fix and regression counts. ProblemCond. Draft Final Reviewer actionInterpretation 3562OAfailpass Removed code fences around a dynamic-programming solution so the evaluator could parse the submitted program. The reviewer corrects a submission failure on parsing. abc394_fAOfailpass Replaced an incorrect component-counting solution with a tree dynamic program. This is a rare helpful AO case. The O reviewer found the missing structural invariant. 3688OOfailpass Restored deleted values in the segment-tree state and kept the rest of the writer’s interface. The same model O reviewer is helpful when it repairs one local invariant while preserving the draft’s architecture. 3717AOpassfailReplaced a passing sorted-list median-window solution with a heap-based rewrite. The reviewer discards a correct invariant and introduces a new one that fails hidden tests. arc191_aAApassfailChanged optional digit accounting in an already passing solution. The same model reviewer can regress when the second pass treats a delicate boundary case as a cleanup opportunity. abc389_fOOpassfail Removed a segment-tree range guard that protected an edge case. A small guard deletion can break a solution that otherwise had the right data structure. Claude writer Codex writer A AO OA O +3 /−3 +3 /−13 +26 /−5 +21 /−6 pass kept fix fail kept regression share of tasks (%), grouped by writer Figure 1: Per task outcomes (푛=116): stacked decomposition with conditions grouped by writer. Absolute fix and regres- sion counts are shown to the right of each bar. first pass. At high reasoning effort, Claude Opus 4.7 may already catch most errors that a static reviewer could find, leaving the second pass with little signal. Codex GPT-5.5 appears to leave more residual, catchable errors. The latency table supports this reading: Claude Opus 4.7 solo takes 86.2 s per task against Codex GPT-5.5’s 38.5 s, consistent with Claude Opus 4.7 spending more compute on first pass checks. If review value depends on the gap between what the writer already verified and what the reviewer can add, then A has little to add and O has a real margin to work with. 5.2 Claude reviewing Codex helps whereas Codex reviewing Claude hurts The same asymmetry shows up across the two cross-model condi- tions in Table 3: OA gains while AO loses on the same task set with the same prompts. There are two possible hypotheses on this. First, Claude Opus 4.7’s heavier first pass verification leaves less for any second pass to find, so a Codex GPT-5.5 reviewer staring at a Claude Opus 4.7 draft has few real catches available and tends to fall back on rewriting. Second, Claude Opus 4.7 starts from a higher pass rate baseline, so a Claude Opus 4.7 reviewer has room to lift Codex GPT-5.5, while a Codex GPT-5.5 reviewer can mostly only drop Claude Opus 4.7. Both are consistent with the Olausson et al. finding that the gain from a repair pass depends on whether the repairer is stronger than the drafter [27]: OA is the case where the reviewer is stronger than the drafter, and AO is the reverse. Because the two models differ in baseline pass rate, this design cannot fully separate the effect of review direction from the effect of that baseline gap, so we read the cross-model comparison as descriptive of role assignment rather than as a causal claim about ordering alone. 5.3 Helpful review edits whereas harmful review rewrites Across the cases in Section 4.3, the OA and AO reviewers differ less in how often they intervene than in how do they intervene. Codex GPT-5.5 as reviewer, when uncertain, tends to discard the writer’s data structure and start over (the 3717 heap rewrite and theabc389_fguard deletion are characteristic). Claude Opus 4.7 as reviewer tends to keep the writer’s interface and repair one local invariant, such as 3688 on a segment-tree fix. We did not measure rewrite frequency directly, so this is an interpretive pattern across the artifact rather than a quantitative claim. It suggests a concrete prompt direction for future work: instruct the reviewer to first decide whether to intervene at all, and to default to keeping the writer’s structure when in doubt. 5.4 When to add a reviewer, and when not to Cost and latency turn the discussion above into a practical guideline for this benchmark based on the sample data: • If the writer must be Codex GPT-5.5: use OA when accuracy dominates (89.7%,+18.1 p over Codex GPT-5.5 solo, low- est reviewed regression rate at 4.3%) and use O when the Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?Agentic SE @ KDD ’26, August 10, 2026, Jeju, Korea $0.20$0.30$0.40 65% 75% 85% 95% 100% pass rate A O AO OA A O cost/task (a) Cost 40s80s120s 65% 75% 85% 95% 100% pass rate A O AO OA A O latency/task (b) Latency Figure 2: Cost versus accuracy (left) and latency versus accuracy (right) trade-offs. Circles are solo baselines; diamonds are reviewed conditions; arrows show what each added reviewer buys. Red arrows leave the Codex solo point; blue arrows leave the Claude solo point. Up is more accurate; right is more expensive or slower. per task latency budget is under roughly 70 s and 84.5% is acceptable. •If the writer must be Claude Opus 4.7 : skip review. A matches A’s pass rate while adding cost and 49.6 s of latency; AO loses 8.6 p at higher cost than either solo baseline. • Cost per net fix: OA adds 21 net passes at an extra $0.25 per task across 116 tasks, or roughly $1.40 per net fix; O adds 15 net passes at an extra $0.12 per task, or roughly $0.95 per net fix. AO loses 10 net passes at higher cost than either solo baseline, so it has no useful cost per fix number. • If both ends are free: Claude Opus 4.7 solo is Pareto-optimal on this benchmark. No reviewed condition beats it on both axes, and A is strictly dominated by A. 5.5 Scope, Limitations, and Reproducibility This study is designed for exploratory understanding rather than breadth. At 116 paired tasks drawn from hard and medium Live- CodeBench code generation problems, the design is sufficient for a first diagnostic but not for settling stable rankings across future model releases. The natural follow-up is to repeat the design on larger LiveCodeBench dataset as later releases appear. Evaluating the same design on a larger task sample and on additional code benchmarks beyond LiveCodeBench would also help test whether these patterns generalize. The setting isolates algorithmic reasoning under contamination-aware evaluation using LiveCodeBench but does not generalize to repository-scale bug fixing, build systems, or multi-file review. The static reviewer cannot execute tests, which keeps the setting close to pre-CI code review but likely understates what a tool-using agent with a sandbox could achieve. Results are also sensitive to prompt wording and formatting instructions, and because coding agents change quickly we pin model identifiers, CLI versions, and execution dates, though future releases may shift the numbers in either direction. Cost figures are point-in-time estimates subject to pricing and caching changes. Our prompts are written manually, which can advantage or dis- advantage either model. Stronger or more conservative instructions might reduce harmful rewrites and further tool access could change both the fix rate and the regression rate. There can be further inves- tigation into how prompts can be worded differently and whether models can benefit from memory of past failures, such as prior suc- cess and failure review cases, test driven development, or feedback on draft results. A related limitation is structural: in our prompt the reviewer always emits a final program, so there is no separate “intervene?” decision. AO’s high regression rate (11.2%) is consistent with Codex GPT-5.5 over-using that rewrite affordance. A prompt that asks the reviewer to first decide whether to intervene, and only then to write a final program, is a natural follow-up. We used "high" reasoning effort in Codex GPT-5.5 and Claude Opus 4.7; "extra high" in Codex GPT-5.5 and, more recently, "Max" in Claude Opus 4.7 are now available. Given we were initially at- tempting to understand whether the review step helps and which model is the better reviewer, we did not focus on different reasoning parameters. In addition, new models are also released very often. It is likely that newer versions of Claude Opus 4.7 and Codex GPT-5.5 have improved results. Further experiments and analysis using the latest models and different reasoning efforts can provide more gran- ular recommendations for software practitioners. Our evidence also covers a single model pair, so whether the asymmetry generalizes beyond Claude Opus 4.7 and Codex GPT-5.5 to families such as Gemini, DeepSeek, Qwen, or Grok is untested, and repeating the design across more models, including within one family, is a direct way to check for consistent patterns. The benchmark tasks are self contained Python programs with hidden tests, not patches inside a live repository. This makes cor- rectness measurement precise, but it does not consider areas such as API compatibility, build integration, style consistency, security posture, and maintainability across files. Restricting to self con- tained functions is what isolates the writer and reviewer roles from repository context and multi file dependencies, which is why we Agentic SE @ KDD ’26, August 10, 2026, Jeju, KoreaZuodong Xiang, Yike Zhang, YueMing Zhang, and Hailu Xu treat it as a first controlled diagnostic before repository scale review. We therefore view the results as evidence about model role assign- ment under controlled static review, not as a universal ranking of either model as a software reviewer. We also score review only by the correctness of the final program. Code review in practice yields more than a pass or fail signal, including design feedback, readability comments, and security observations, and whether LLM reviewers add value along those dimensions is left to future work. Lastly, for reproducibility, the released artifact 1 includes the full experiment configuration, prompts, raw outputs, prompt hashes, CLI versions, timing and token fields, and analysis scripts. Repro- ducing all six writer-reviewer conditions across the 116 complete case tasks costs roughly $225 in API calls (or $1.94 per task across 6 conditions, see Table 2), with retries, models, and reasoning effort configurable. 6 Conclusion We started with a simple question: if you have two coding agents and let one write a draft while the other reviews it before the code is submitted, does the review pass help? Using Claude Opus 4.7 and Codex GPT-5.5, we ran every writer and reviewer combination on 116 hard and medium LiveCodeBench programming problems. The reviewer saw the problem and the draft but could not run the code or see test results. The answer depends on who wrote the draft. When Codex GPT- 5.5 writes, a review pass helps: Claude Opus 4.7 reviewing Codex GPT-5.5 raises the pass rate from 71.6% to 89.7% (a gain of 18.1 points), and Codex GPT-5.5 reviewing its own draft raises it to 84.5% (a gain of 12.9 points). When Claude Opus 4.7 writes, a review pass does not help. Claude Opus 4.7 reviewing itself leaves its 91.4% pass rate unchanged, and Codex GPT-5.5 reviewing Claude Opus 4.7 drops it to 82.8% (a loss of 8.6 points). Looking at individual tasks shows that a helpful review fixes a small flaw in an otherwise sound draft, while a harmful review throws away a working draft and rewrites it into one that fails. The implication in this paper is practical for software develop- ment. If Codex GPT-5.5 writes the draft, add a review pass, and use Claude Opus 4.7 as the reviewer for the best accuracy or Codex GPT-5.5 itself when cost and latency matter more. If Claude Opus 4.7 writes the draft, submit it as is, because no reviewer we tested beats Claude Opus 4.7 working alone. The exact numbers are spe- cific to these two model versions and to LiveCodeBench. Future research on areas such as modifying reviewer prompts, scaling up the task sample, evaluating on additional code benchmarks beyond LiveCodeBench, and testing a wider range of LLM models and con- figurations can provide us with a deeper understanding of review agents in the era of Agentic AI software development. References [1] Anthropic. 2025. Claude Opus 4 System Card. https://w.anthropic.com/ claude/opus. Model identifier: claude-opus-4. [2]Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al.2021. Program synthesis with large language models. arXiv preprint arXiv:2108.07732 (2021). 1 Code and data: https://github.com/shawnzxiang/cross-model-review-code [3]Alberto Bacchelli and Christian Bird. 2013. Expectations, outcomes, and chal- lenges of modern code review. In 2013 35th international conference on software engineering (ICSE). IEEE, 712–721. [4] Yoav Benjamini and Yosef Hochberg. 1995. Controlling the false discovery rate: a practical and powerful approach to multiple testing. Journal of the Royal Statistical Society: Series B (Methodological) 57, 1 (1995), 289–300. [5] Bei Chen, Fengji Zhang, Anh Nguyen, Daoguang Zan, Zeqi Lin, Jian-Guang Lou, and Weizhu Chen. 2022. CodeT: Code generation with generated tests. arXiv preprint arXiv:2207.10397 (2022). [6]Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al.2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374 (2021). [7]Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. 2024. Teaching large language models to self-debug. In International Conference on Learning Representations, Vol. 2024. 8746–8825. [8]Zhiyuan Cheng, Longying Lai, Yue Liu, and Yu Sun. 2026. Toward Sustainable On-Device Intelligence: A Survey on Energy-Efficient RAG Systems with Small Language Models. Available at SSRN 6698538 (2026). [9]Yilun Du, Shuang Li, Antonio Torralba, Joshua B Tenenbaum, and Igor Mordatch. 2024. Improving factuality and reasoning in language models through multiagent debate. In Forty-first international conference on machine learning. [10]Yaxin Gao, Yao Lu, Zongfei Zhang, Jiaqi Nie, Shanqing Yu, and Qi Xuan. 2026. DSPC: Dual-Stage Progressive Compression Framework for Efficient Long- Context Reasoning. In ICASSP 2026 - 2026 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP). 19387–19391. doi:10.1109/ ICASSP55912.2026.11460600 [11] Jiaming Guo, Zhichun Qi, Xiaokuan Zhao, Shuai Xu, and Hailu Xu. 2025. LightLLM-Enhanced Multi-Robot Collaboration with Human-in-the-Loop. In 2025 8th International Conference on Robotics, Control and Automation Engineering (RCAE). IEEE, 27–32. [12] Dan Hendrycks, Steven Basart, Saurav Kadavath, Mantas Mazeika, Akul Arora, Ethan Guo, Collin Burns, Samir Puranik, Horace He, Dawn Song, et al.2021. Mea- suring coding challenge competence with APPS. arXiv preprint arXiv:2105.09938 (2021). [13]Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Steven Yau, Zijuan Lin, Liyang Zhou, et al.2024. MetaGPT: Meta programming for a multi-agent collaborative framework. In International Conference on Learning Representations, Vol. 2024. 23247–23275. [14]Dong Huang, Jie M Zhang, Michael Luck, Qingwen Bu, Yuhao Qing, and Heming Cui. 2023. AgentCoder: Multi-agent-based code generation with iterative testing and optimization. arXiv preprint arXiv:2312.13010 (2023). [15]Naman Jain, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Armando Solar-Lezama, Koushik Sen, and Ion Stoica. 2025. LiveCodeBench: Holistic and contamination free evaluation of large language models for code. In International Conference on Learning Representations, Vol. 2025. 58791–58831. [16]Xiaochong Jiang, Shiqi Yang, Ziwei Li, Lifei Liu, Haoran Yu, and Yichen Liu. 2026. ChainCaps: Composition-Safe Tool-Using Agents via Monotonic Capability Attenuation. arXiv:2605.26542 [cs.CR] https://arxiv.org/abs/2605.26542 [17]Yuxuan Jiang, Dawei Li, and Francis Ferraro. 2026. DRP: Distilled Reasoning Pruning with Skill-aware Step Decomposition for Efficient Large Reasoning Models. arXiv:2505.13975 [cs.CL] https://arxiv.org/abs/2505.13975 [18]Haolin Jin and Huaming Chen. 2026. Are LLMs Reliable Code Reviewers? Sys- tematic Overcorrection in Requirement Conformance Judgement. arXiv preprint arXiv:2603.00539 (2026). [19] Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et al.2022. Competition-level code generation with AlphaCode. Science 378, 6624 (2022), 1092–1097. [20]Zhiyu Li, Shuai Lu, Daya Guo, Nan Duan, Shailesh Jannu, Grant Jenks, Deep Majumder, Jared Green, Alexey Svyatkovskiy, Shengyu Fu, et al.2022. Automating code review activities by large-scale pre-training. In Proceedings of the 30th ACM joint European software engineering conference and symposium on the foundations of software engineering. 1035–1047. [21]Tian Liang, Zhiwei He, Wenxiang Jiao, Xing Wang, Yan Wang, Rui Wang, Yujiu Yang, Shuming Shi, and Zhaopeng Tu. 2024. Encouraging divergent thinking in large language models through multi-agent debate. In Proceedings of the 2024 conference on empirical methods in natural language processing. 17889–17904. [22] Hong Yi Lin, Chunhua Liu, Haoyu Gao, Patanamon Thongtanunam, and Christoph Treude. 2025. CodeReviewQA: The code review comprehension assess- ment for large language models. In Findings of the Association for Computational Linguistics: ACL 2025. 9138–9166. [23] Jiayuan Liu, Tianqin Li, Shiyi Du, Xin Luo, Haoxuan Zeng, Emanuel Tewolde, Tai Sing Lee, Tonghan Wang, Carl Kingsford, and Vincent Conitzer. 2026. The Memory Curse: How Expanded Recall Erodes Cooperative Intent in LLM Agents. arXiv preprint arXiv:2605.08060 (2026). [24]Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?Agentic SE @ KDD ’26, August 10, 2026, Jeju, Korea 2023. Self-Refine: Iterative refinement with self-feedback. Advances in neural information processing systems 36 (2023), 46534–46594. [25]Quinn McNemar. 1947. Note on the sampling error of the difference between correlated proportions or percentages. Psychometrika 12, 2 (1947), 153–157. [26]Ansong Ni, Srini Iyer, Dragomir Radev, Veselin Stoyanov, Wen-tau Yih, Sida Wang, and Xi Victoria Lin. 2023. LEVER: Learning to verify language-to-code generation with execution. In International Conference on Machine Learning. PMLR, 26106–26128. [27] Theo X Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, and Armando Solar-Lezama. 2024. Is self-repair a silver bullet for code generation?. In International Conference on Learning Representations, Vol. 2024. 36545–36593. [28]OpenAI. 2025. Introducing GPT-5. https://openai.com/index/introducing-gpt-5/. Model identifier: gpt-5. [29]Ruwei Pan, Hongyu Zhang, and Chao Liu. 2025. CodeCoR: An LLM-based self-reflective multi-agent framework for code generation. arXiv preprint arXiv:2501.07811 (2025). [30]Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, et al.2024. ChatDev: Communicative agents for software development. In Proceedings of the 62nd annual meeting of the association for computational linguistics (volume 1: Long papers). 15174–15186. [31]Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko, and Alberto Bacchelli. 2018. Modern code review: a case study at google. In Proceedings of the 40th international conference on software engineering: Software engineering in practice. 181–190. [32]Binqi Shen, Lier Jin, Hanyu Cai, Lan Hu, and Yuting Xin. 2026. The Efficiency Frontier: A Unified Framework for Cost-Performance Optimization in LLM Con- text Management. arXiv preprint arXiv:2605.23071 (2026). doi:10.48550/arXiv. 2605.23071 [33]Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. Reflexion: Language agents with verbal reinforcement learning. Advances in neural information processing systems 36 (2023), 8634–8652. [34]Rosalia Tufano, Luca Pascarella, Michele Tufano, Denys Poshyvanyk, and Gabriele Bavota. 2021. Towards automating code review activities. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 163–174. [35]Yining Wang, Zhixiang Lu, Pin Qian, Jionglong Su, Mian Zhou, Chong Li, and Zhengyong Jiang. 2025. GEMs-LLM: Integrating Large Language Mod- els with Goal-Aware Exploration for RL-Based Portfolio Optimization. In Ad- vanced Intelligent Computing Technology and Applications (Communications in Computer and Information Science, Vol. 2566). Springer, Singapore, 516–527. doi:10.1007/978-981-96-9949-0_43 [36]Simon Zhang, Zhengxiong Li, Yaxuan Yin, Shuai Xu, Vipin Chaudhary, and Hailu Xu. 2025. A survey on multi-robot collaboration systems: Architectures, performances, and applications. (2025). [37]Yike Zhang, Zuodong Xiang, and Hailu Xu. 2026. Performance-Efficiency Trade- offs in Human Preference Prediction: A Comparative Study of Traditional Ma- chine Learning and Large Language Models. In Proceedings of the 31st IEEE Symposium on Computers and Communications (ISCC 2026). [38]YueMing Zhang, Shuai Xu, Zhengxiong Li, Fangtian Zhong, Xiaokun Yang, and Hailu Xu. 2026. SwiftBot: A Decentralized Platform for LLM-Powered Federated Robotic Task Execution. The 26th IEEE International Symposium on Cluster, Cloud, and Internet Computing (CCGrid) (2026). [39]Zijian Zhang, Rong Fu, Yangfan He, Xinze Shen, Yanlong Wang, Xiaojing Du, Haochen You, Keyan Jin, Jiazhao Shi, and Simon Fong. 2026. FinSentLLM: Multi- LLM and Structured Semantic Signals for Enhanced Financial Sentiment Fore- casting. In ICASSP 2026 - 2026 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP). IEEE, 17682–17686. [40] Yongxi Zhou, Lai Yun Choi, Jiaxi Wen, and Wenbo Ye. 2026. Accuracy, Stabil- ity, and Repeated-Run Reliability of Large Language Models on Deterministic Programming Tasks. arXiv:2606.00920 [cs.LG] https://arxiv.org/abs/2606.00920