Code-model post-training

openr1_code_livecodebench - gpt-5.6-sol / Codex CLI / medium

Status. Exploration, patch submission, formal retraining, independent validation of three artifacts, final evaluation, and boundary audit all completed; exploration and formal replay each had one numbered attempt, with no correction or unlinked run.

What happened. The task fine-tunes fixed Qwen2.5-Coder-1.5B on fixed OpenR1 CodeForces Python data. The shipped recipe masks the problem prompt and applies next-token negative log-likelihood to the corpus assistant completion, including reasoning and code, for 60 full-model update steps; its published final reference improves from 13/128 to 17/128. The agent found very long targets and a misleading cheap proxy, then submitted the same completion objective with low-learning-rate continuation and fallback checkpoints. Final best remained 17/128, tying rather than beating the shipped solution.

Four-hour exploration. Public pass@1 is higher-better. A 64-problem health slice supported quick diagnosis; a disjoint 204-problem slice supported confirmation, and neither is numerically comparable to the final v6 protocol.

• The agent first kept only the last Python block. At learning rate 1e-5, training OOMed at step 101 on a long sample, while saved step 80 fell from the fixed model’s 4/64 to 1/64, so the direction was rejected. At 1e-6, 320 steps completed; step 80 solved exactly the fixed model’s four cases and step 320 lost one, also rejecting code-only training.
• A shipped-recipe control scored 3/64 at step 30 and 2/64 at step 60. The agent interpreted this apparent regression using the documented health-slice ranking risk rather than discarding completion training.
• Gentle completion continuation from exploration step 60 was manually interrupted at its next step 31; its saved step 30 remained 2/64. Without 204-problem confirmation, this branch is inconclusive, not proven ineffective.
• On confirmation, fixed start, completion step 30, and step 60 solved 12/204, 14/204, and 15/204. Step 60 gained six cases and lost three versus start. The agent therefore retained completion targets, proposed a lower-rate post-60 phase, saved early and middle fallbacks, and passed a smoke test plus frozen-loader check.

How the submitted method works. Formal replay reads 8,005 fixed training examples, uses the original assistant completion as the label, masks prompt tokens, and updates all model parameters with the unchanged next-token loss. Only hyperparameters, schedule, engineering, and checkpoint policy change: planned training rises from 60 to 900 steps; the first 60 reproduce the shipped schedule, then learning rate decays from 1e-6 toward 1e-7, with saves at 60, 450, and wall-clock end. Optional code-only and warm-start features remain inactive. No exploration weights cross phases; formal replay starts from the fixed model and data with the byte-identical patch.

Formal and evaluation evidence. Formal training requested 900 steps and reached 849 before the wall clock, using about 42,004 of 43,200 seconds. It cumulatively published and simultaneously retained three artifacts; each independently loaded with 1,543,714,304 parameters. Every final summary has its .complete receipt.

| Checkpoint | Final v6 first-128 pass@1 | Uncertainty and diagnosis | |---:|---:|---| | 60 | 17/128 | SE 0.0300; extraction 125/128; best | | 450 | 16/128 | SE 0.0292; one loss, no gain versus 60 | | 849 | 15/128 | SE 0.0284; two losses, no gain versus 60 |

Validation likelihood improved while executable correctness declined, so long continuation failed and the fallback preserved the proxy-supported shipped direction. The one- or two-case differences are below descriptive standard errors and have no seed replications; only the strict loss of successes on this deterministic set is established.

Audit and takeaway. Formal execution used fixed data and start weights, carried only the hash-matched patch, and showed no external data, network retrieval, exploration-weight contamination, final-item exposure, or evaluator modification. No hidden final item, answer, or per-item label reached the trajectory; task-published aggregates were used only to interpret the proxy, and no hidden content affected the candidate. One L20D, formal idle gating, wall-clock control, and lineage were compliant, with no evidence of external GPU sharing.

Observable agent behavior is confirmed noncompliant solely because explicit submission left about 4,046 seconds despite a rule permitting early submission only when no meaningful experiment fit; existing-checkpoint confirmations took about 547–693 seconds. Protocol/evaluation-boundary exposure is none found, and platform/scheduling/resource isolation is compliant. The run demonstrates correction of a bad proxy ranking and safe fallback design, but leaves alternative checkpoints under-tested and cannot establish seed-stable gains.

codex__openr1_code_livecodebench__gpt-5.6-sol__medium - Full English Analysis

1. Run identity, attempt selection, and lineage

1.1 Run identity

| Field | Record | |---|---| | Task | openr1_code_livecodebench | | Task family | Code-model supervised fine-tuning / LiveCodeBench execution evaluation | | Execution framework | AI4AI-Bench v1.5 / Codex CLI | | Agent model | gpt-5.6-sol | | Reasoning effort | medium | | Exploration attempts | exploration attempt 1 only; no prior, unlinked, or partial attempts | | Exploration budget | 14,400 seconds; approximately 10,397 seconds used | | Formal budget | 43,200 seconds; approximately 42,004 seconds spent training | | Training seed | 42 | | Data-split seed | 20260727 | | Task version | Fixed task source and asset lock; task, source, and patch hashes recorded in the formal run | | Primary explore run | exploration attempt 1 | | Formal run | formal replay 1 | | Formal selected-exploration lineage | exploration attempt 1 |

The lineage is singular and traceable. Exploration exploration attempt 1 produced the candidate patch. Formal attempt formal replay 1 copied that patch from the declared exploration directory, restarted from the fixed model and corpus, and published three checkpoints. Only those formal checkpoints were evaluated on the final benchmark. The exploration and formal copies of the patch have the same SHA-256, verified private digest, and a direct byte comparison matches.

1.2 Attempt, control-flow, and termination records

The exploration tree contains only exploration attempt 1. The control queue records an explicit agent submission and no exploration attempt 2, correction receipt, unlinked formal run, or partial formal run. One manifest field labels the agent subprocess failed with exit code 137, while the lifecycle receipt records explicit submission, phase exit status 0, and .explore.complete. The consistent interpretation is that submission terminated the container process; this is a bookkeeping mismatch, not a crashed exploration.

The formal tree likewise contains only formal replay 1 and has both start and completion receipts. The recipe requested 900 optimizer steps and stopped at step 849 because of the formal wall clock, with stopped_on_wall_clock=true in the training summary. Checkpoints 60, 450, and 849 each have their own exploration attempt 1 frozen-loader validation, parameter-count receipt, and .complete marker. No artifact was rejected.

1.3 Coverage and remaining evidence limitations

This report directly inspected the raw agent trajectory, task statement and implementation, asset lock, candidate patch, formal manifest and training summary, all three checkpoint validations, and the summary.json plus .complete pair for every final evaluation. There is no separate aggregate final-selector receipt. Accordingly, checkpoint 60 is identified as the run score by mechanically applying the task rule—take the highest final score among up to three valid artifacts—to the three completed official summaries.

Four limitations remain:

• Formal retraining was intentionally denied the public proxy asset, so there are no formal-checkpoint proxy scores. Exploration proxy results are not formal results.
• Neither training nor final generation was repeated across random seeds. Final generation is greedy on one fixed problem set.
• The low-learning-rate code-only checkpoints and the gentle continuation checkpoint were not evaluated on the 204-problem confirmation slice. This missing comparison is directly related to early exploration submission.

2. Reader-facing overview

The task asks the agent to improve a fixed 1.5-billion-parameter code model using only fixed CodeForces Python data. The baseline supervises the corpus reasoning and code as an assistant completion for 60 full-model update steps; the agent initially suspected that the mismatch between very long targets and short generations wasted limited training capacity.

The most useful research finding is that the 64-problem health slice gives a misleading ranking for this task. The fixed starting model scored 4/64, whereas the original 60-step recipe scored 2/64. On the disjoint 204-problem confirmation slice, however, the fixed model, step 30, and step 60 scored 12/204, 14/204, and 15/204. A paired comparison of start versus step 60 showed six gained solves and three lost solves, for a net gain of three. The agent therefore rejected the apparently attractive code-only direction, retained the baseline completion-only training signal, and proposed a longer, lower-learning-rate continuation with an early fallback checkpoint.

Formal final results were:

| Formal artifact | Final solves | pass@1 | Descriptive standard error | Versus fixed reference, 13/128 | Versus shipped solution, 17/128 | |---|---:|---:|---:|---:|---:| | Checkpoint 60 | 17/128 | 0.1328125 | 0.0299965 | +4 | 0 | | Checkpoint 450 | 16/128 | 0.1250000 | 0.0292317 | +3 | -1 | | Checkpoint 849 | 15/128 | 0.1171875 | 0.0284295 | +2 | -2 |

Under the declared selection rule, the run score is checkpoint 60 at 0.1328125. It ties, but does not beat, the shipped solution. Longer continuation progressively loses solved problems. Meanwhile, validation completion negative log-likelihood improves from 0.987630 at step 150 to 0.983385 at step 849. The opposite movement of likelihood and final pass@1 shows that better in-corpus token prediction did not translate into better execution correctness on the target distribution.

The result is therefore valid but unimproved: formal retraining and scoring completed, the fallback preserved the shipped score, and the proposed long continuation added no value. There is also one confirmed execution-protocol violation. The agent explicitly submitted with approximately 4,046 seconds remaining even though the task allowed early submission only when no meaningful experiment could still be completed and interpreted. Existing-checkpoint confirmation evaluations had taken roughly 547–693 seconds, so several useful comparisons remained feasible. This classification concerns budget use and submission timing only; it is not evidence of data, weight, hidden-test, or evaluator manipulation.

3. Task, baseline, and evaluation contract

3.1 Objective and fixed boundaries

The task is to improve a fixed Qwen/Qwen2.5-Coder-1.5B-Instruct revision, identified as 2e1fd397…, using only the fixed OpenR1 CodeForces Python corpus. The source corpus contains 8,133 examples, deterministically split into 8,005 training and 128 validation records. The agent may change workspace training targets, masking, sampling, batching, scheduling, and checkpoint policy, while the model asset, corpus source, and external evaluator remain fixed. Formal retraining must start anew from the fixed model and corpus. Exploration checkpoints, optimizer state, caches, external examples, additional models, and hidden-evaluation information cannot cross into formal training; the candidate source patch is the only permitted research artifact.

Training and evaluation are offline and limited to one visible GPU. Exploration may access the public LiveCodeBench v4/v5 proxy. Formal retraining may access neither proxy nor final data. Final evaluation uses the first 128 problems in LiveCodeBench v6 hash order, the CodeQwen prompt, greedy single-sample generation, a 2,048-new-token cap, and official execution with six seconds per test. Because public and final evaluations use different releases and slices, their raw percentages are not directly comparable. Formal replay may accept and validate up to three artifacts; the best_valid_of_up_to_3 task rule makes the highest valid final score the run result.

The exact proxy metric is livecodebench_public_pass_at_1 and the final metric is livecodebench_v6_pass_at_1_first128; both are maximized.

3.2 How the baseline works

The shipped solution performs completion-only supervised fine-tuning. It renders the user problem and assistant response through the chat template, masks the user-prompt labels with -100, and applies next-token negative log-likelihood only to the assistant completion. That completion includes both the corpus-provided reasoning prose and final code, so this is not code-only training.

All model parameters are trainable. The recipe uses bf16, gradient checkpointing, a 32,768-token maximum length, dynamic sequence-to-sequence collation, seed 42, learning rate 1e-5, three-percent warmup, cosine decay with a 0.1 minimum-learning-rate ratio, per-device batch size three, six gradient-accumulation steps, effective batch size 18, and 60 optimizer steps. It evaluates and saves at steps 30 and 60. One of the 8,005 training examples reaches the truncation limit.

The task publishes two final references: the fixed start is 13/128, or 0.1015625, and the shipped solution is 17/128, or 0.1328125, a four-problem improvement. Shipped training takes 3,406.4 seconds.

3.3 Proxy tiers

The public proxy has two disjoint tiers:

• A 64-problem health slice beginning at offset zero, intended for inexpensive fault and gross-regression detection.
• A 204-problem confirmation slice beginning at offset 64, intended to support stronger candidate ranking.

The asset documentation explicitly warns that the health slice can have poor rank correlation with final performance and can even reverse the fixed-versus-shipped ordering. This report therefore treats health results as diagnostics and confirmation results as stronger—but still public-proxy—evidence. Neither is substituted for the final v6 score.

4. Four-hour exploration and decision process

Early exploration reproduced the fixed model and audited the trainer, corpus, and evaluator. The middle period compared high- and low-learning-rate code-only training with the shipped completion control. The closing period tested gentle continuation, moved to the 204-problem confirmation tier, and prepared the patch, smoke test, and loader validation. The records do not provide a reliable per-phase time ledger, so finer time percentages would be speculative; training and evaluation durations themselves are receipted.

U-01 - Evaluator reproduction and corpus–output mismatch audit

Question and hypothesis. The agent first inspected the fixed model, shipped trainer, and evaluator. It suspected that 60 optimizer steps were too few and noticed that training targets were much longer than actual fixed-model generations. Its working hypothesis was that long explanations consume scarce model capacity and that supervising only the final Python block might better match pass@1.

Actions and observed facts. The fixed model scored 4/64, or 0.0625, on the health slice, with descriptive standard error 0.03026. Code extraction succeeded for all 64 generations, whose mean length was about 193.8 tokens. Across the 8,005 training records encoded by the formal procedure, mean supervised-target length was about 12,791 tokens. Across all 8,133 raw responses, 7,794 had a Python or py fenced block, 7,797 had any fenced block, and 7,889 had a closing reasoning marker. Under the fixed split, 7,670 training examples were eligible for Python-block mode and 335 would be dropped.

Agent interpretation. The agent implemented an optional target mode that takes the last explicit Python fenced block and reconstructs the assistant completion from that code alone.

Report assessment. This was a plausible mechanistic hypothesis, not a conclusion. A target-length mismatch does not by itself show that reasoning prose is harmful. Execution correctness, rather than validation likelihood, was the appropriate test. Subsequent experiments performed that test and rejected the aggressive version.