InteractBench Benchmarking LLMs on Competitive Programming under Unrevealed Information

Jiaze Li1,2,3 Aocheng Shen1 Bing Liu1 Boyu Zhang1 Xiaoxuan Fan1 Qiankun Zhang1,2,3 Xianjun Deng1,3

  1. 1 School of Cyber Science and Engineering, Huazhong University of Science and Technology, Wuhan, China
  2. 2 Key Laboratory of Cyberspace Security, Ministry of Education, Zhengzhou, China
  3. 3 Hubei Key Laboratory of Distributed System Security, Wuhan, China
Huazhong University of Science and Technology ICML

Abstract

Competitive programming is increasingly being used to evaluate the algorithmic reasoning capabilities of large language models (LLMs). However, existing benchmarks primarily focus on full-information tasks where all problem inputs are provided upfront. This overlooks a critical dimension of algorithmic reasoning: the ability of generated programs to operate when key information is not revealed upfront. Interactive problems, a distinctive component of competitive programming, embody this challenge. These problems require programs to engage in multi-round interaction with an interactor (a judge program) under strict protocol constraints and limited query budgets, with new information revealed only in response to queries. To address this gap, we introduce InteractBench, a benchmark comprising 322 high-quality interactive problems curated from Codeforces, AtCoder, IOI, and ICPC. Each problem is packaged with executable local interactors, enabling fully offline evaluation. Unlike existing benchmarks, InteractBench assesses whether model-generated code can acquire information and track state dynamically. Our evaluation reveals a significant interaction gap: even the most advanced reasoning models achieve limited success on interactive problems. Beyond success rates, we propose a fine-grained failure taxonomy to diagnose the root causes of these deficiencies. Although algorithmic logic errors remain dominant, protocol violations and query-budget overruns are frequent.

Motivation

Why this problem matters

Most existing competitive-programming benchmarks primarily focus on batch-style tasks where all problem inputs are provided upfront. This overlooks a critical dimension of algorithmic reasoning: the ability of generated programs to operate when key information is not revealed upfront.

Interactive problems embody this challenge. These problems require programs to engage in multi-round interaction with an interactor under strict protocol constraints and limited query budgets, with new information revealed only in response to queries.

Interaction

What an interactive problem looks like

Find the smallest index x such that A[1..x] contains k zeros, with n = 8 and k = 3. In the batch setting the whole array is given upfront; in the interactive setting it is hidden, and the solver must recover the answer through range-sum queries under a fixed budget.

An illustration of the difference between batch-style and interactive problems.
Figure 1. An illustration of the difference between batch-style and interactive problems.
example run
query: Sum(A[1..4])
reply: 3
query: Sum(A[5..6])
reply: 1
query: Sum(A[7..7])
reply: 0
query: Answer: Index 7
Correct
Contributions

What this work provides

A benchmark of interactive problems

We curate 322 interactive problems from Codeforces, AtCoder, IOI, and ICPC. Each problem is annotated with consolidated categories and difficulty tiers.

A self-contained evaluation harness

Each problem is packaged with an executable local interactor, enabling fully offline evaluation without external judge submission.

Interaction-aware diagnostics

Beyond pass@k, our harness checks protocol compliance, enforces query budgets, and reports a failure taxonomy that separates algorithmic errors from interaction-specific failures.

Benchmark Comparison

Where interactive evaluation is missing

Existing benchmarks focus on batch-style problems. Some rely on external online judges, limiting fully offline evaluation. Even when interactive problems are included, they typically constitute a small subset.

Comparison of representative code and competitive programming benchmarks.
Table 1. Comparison of representative code and competitive programming benchmarks.
Construction Pipeline

How each problem is built and verified

An overview of the InteractBench construction pipeline.
Figure 2. An overview of the InteractBench construction pipeline.
01

Select

We select interactive tasks with multi-round protocols and explicit query budgets from Codeforces, AtCoder, IOI, and ICPC.

02

Propose-Validate-Adjudicate

Proposer models draft candidate generators and interactors. Candidates are validated against a per-task verification pool of submissions with known official verdicts.

03

Audit

As a supplementary sanity check, we conduct a one-time post-hoc online agreement audit.

Results

Interactive tasks expose a persistent gap

pass@1 and pass@5 stratified by difficulty on InteractBench.
Table 2. pass@1 and pass@5 (higher is better) stratified by difficulty on InteractBench.
  • Hard interactive tasks remain unsolved and strongly discriminative.
  • Gaps between pass@1 and pass@5 quantify the benefit of resampling.
  • Explicit reasoning improves pass rates, but does not remove the Hard barrier.
Failure Taxonomy

Separating algorithmic errors from interaction failures

Algorithmic logic

  • WA protocol-compliant but incorrect answer

Interaction-specific

  • PE protocol or format violations
  • QLE query-budget overrun
  • IDLE blocked I/O or deadlock terminated by the wall-clock cap

Execution

  • CE compile error
  • RE runtime error
  • TLE time limit exceeded
  • MLE memory limit exceeded
Failure Analysis

What goes wrong, and how often

Failure composition among unsuccessful executions.
Table 3. Failure composition among unsuccessful executions (higher means more common).
  • Algorithmic logic errors (WA) dominate, but interaction-specific failures occur at different stages.
  • Query efficiency limits frontier models as well.
  • Runtime and resource-limit failures are present but secondary.
Conclusion

Takeaways

  • 01

    A significant interaction gap: even the most advanced reasoning models achieve limited success, with consistent degradation as difficulty increases.

  • 02

    Failures are dominated by algorithmic logic errors, yet protocol violations and query-budget overruns remain frequent even for frontier reasoning models.

  • 03

    Looking forward, we plan to develop prompting and training strategies that directly target interactive querying, state maintenance, and protocol adherence.

FAQ

Frequently asked questions

An interactive benchmark evaluates a model in a setting where information must be acquired step by step instead of being given in full upfront. InteractBench applies this idea to code generation: model-written programs must query a judge program at runtime to uncover hidden inputs, then commit to an answer within a fixed query budget.
An interactive problem hides part of the input behind a judge program called an interactor. The submitted program must issue queries, read the interactor's responses, and produce an answer within a fixed query budget while following a strict I/O protocol. Codeforces, AtCoder, IOI, and ICPC all feature this problem type.
No. Several evaluation projects use similar names, and InteractBench is not affiliated with any of them. InteractBench refers specifically to the ICML 2026 benchmark on this page: 322 interactive competitive-programming problems from Codeforces, AtCoder, IOI, and ICPC, with executable local interactors and an interaction-aware failure taxonomy.
Batch benchmarks provide the complete input upfront and check the final output. InteractBench evaluates whether model-generated code can acquire unrevealed information at runtime: each task requires multi-round interaction with a local interactor under protocol constraints and query budgets, and failures are diagnosed with an interaction-aware taxonomy.
Yes. Every problem ships with an executable local interactor, so the full benchmark runs locally without submitting to an online judge. The dataset is on Hugging Face and the evaluation harness is on GitHub.
BibTeX

Cite this work

@inproceedings{li2026interactbench,
  title     = {InteractBench: Benchmarking {LLM}s on Competitive
               Programming under Unrevealed Information},
  author    = {Jiaze Li and Aocheng Shen and Bing Liu and
               Boyu Zhang and Xiaoxuan Fan and Qiankun Zhang and
               Xianjun Deng},
  booktitle = {Forty-third International Conference on
               Machine Learning},
  year      = {2026},
  url       = {https://openreview.net/forum?id=Y4T4w0Tj0l}
}