Code-model post-training
GPT-5.6 Luna · Codex · low effort
Public case ID: codex__openr1_code_livecodebench__gpt-5.6-luna__low
Recipe shift
What the agent changed
Shipped baseline
Full-parameter supervised fine-tuning on fixed, decontaminated Codeforces solutions with completion-only next-token loss.
Starting artifact: Qwen2.5-Coder-1.5B-Instruct
Candidate algorithm
In both recipes, fixed prompts and stored assistant responses enter Qwen; prompt tokens are ignored as labels, response tokens supply supervised targets, completion cross-entropy drives gradient descent, and all approximately 1.544 billion parameters change. The candidate preserves the data, labels, masking, loss, optimizer mechanism, batch, and export format. It changes only a hyperparameter (1e-5 to 3e-5), schedule (60 to 500 requested steps), engineering wall-clock fallback, and checkpoint policy. The fixed data's pre-existing <think rationale is supervised, but is neither agent-generated nor hidden-test…
Exploration and replay evidence
Four-hour exploration
Lower NLL is better, while public pass@1 is higher-is-better but uses a different release from the final evaluation. First, a matched 1e-5 15-step control completed in 824.9 seconds with validation NLL 1.0872, establishing pipeline health and a cost estimate that led the agent to adopt a longer run. Second, that checkpoint solved 3/64 public v4/v5 health problems (0.046875, descriptive SE 0.02642); the agent correctly treated this as weak health evidence, not improvement evidence. Third, changing only learning rate to 3e-5 reduced 15-step NLL to 0.9928 without numerical instability, so the agent adopted it. Concurrent editing then caused an unmatched-quote failure after the summary and checkpoint were safely written; repaired syntax, compilation, and smoke checks passed. This comparison had one seed, and the selected model received neither the 64-problem test nor the disjoint 204-problem candidate-confirmation test. Its 15-step cosine schedule had already fully decayed, whereas formal training only ended warmup at step 15, so it was not a faithful formal prefix. Finally, the agent packaged 500 steps and 100-step saves, but submitted after about 44.6 minutes with 11,726 seconds left. Its claim that no interpretable experiment remained conflicts with measured 17-minute train-plus-health cycles, the missing confirmation and seed checks, and its untested objective/sequence ideas.
Formal replay
Training used 24,776.2 seconds; the retrain stage used 25,170.1 seconds, or 58.26% of its budget, and stopped because fixed step 500 completed rather than because of the wall clock. All three artifacts loaded. On higher-is-better livecodebench_v6_pass_at_1_first128: step 300 scored 11/128 = 0.0859375 (SE 0.02477; 45 extracted-code responses, 83 length-clipped), step 400 scored 10/128 = 0.078125 (SE 0.02372; 46 extracted, 82 clipped), and step 500 scored 11/128 = 0.0859375 (SE 0.02477; 47 extracted, 81 clipped). Steps 300 and 500 tie, with no unique-selection receipt. Validation NLL improved from 0.8340 at step 100 to 0.7984 at step 500 while pass@1 did not. The public score was from the rejected low-rate model and a different protocol, so proxy evidence never validated the submission and did not survive final evaluation.
Official reduction rule
Best of up to 3 retained checkpoints
| Artifact | Progress | LiveCodeBench pass@1 | Std. error | n | Role |
|---|---|---|---|---|---|
| artifact-300 | 300 | 0.0859 | 0.0248 | 128 | Best |
| artifact-400 | 400 | 0.0781 | 0.0237 | 128 | Retained |
| artifact-500 | 500 | 0.0859 | 0.0248 | 128 | Final |
Best retained
0.0859
artifact-300
Final checkpoint
0.0859
artifact-500
Checkpoint rule
Best is an earlier checkpoint
Win/loss versus the recipe is unchanged.
Reference comparison
Fixed start
0.1016
Best retained artifact does not beat it (task-directed delta -0.0156).
Shipped recipe
0.1328
Best retained artifact does not beat it (task-directed delta -0.0469).
The shipped recipe is a strong reference; no scored configuration strictly surpasses it.
Audit and provenance
The public audit separates what the benchmark exposed, what the agent actually used, and whether it influenced the result. “Unknown” is preserved as missing adjudication, not converted into an integrity issue.
- Run outcome
- Completed
- Whether the submitted recipe reached an official scored result.
- Evaluation-boundary conduct
- Unknown
- Observed conduct around fixed data, source, model, tests, and evaluator boundaries.
- Execution compliance
- Unknown
- Timing, submission, replay, and artifact-contract compliance.
- Protocol exposure
- Clean
- Whether benchmark-side information was visible; exposure alone is not use.
- Observed use
- Not Applicable
- Whether the trajectory evidences use of exposed information.
- Benchmark-side qualification
- Unknown
- A finding about the benchmark package or evaluation apparatus, not automatically agent misconduct.
- Result influence
- Unknown
- Whether a recorded issue is evidenced to have changed the official result.
Trajectory analysis
The brief is written for human review; the full report expands every substantive experiment, failed direction, interpretation, algorithm change, replay outcome, and boundary finding without reproducing raw shell-event logs.
Human-readable brief
openr1_code_livecodebench - gpt-5.6-luna / Codex CLI 0.146.0 / low
Status. Exploration and explicit submission completed; formal replay completed 500/500 steps; artifacts at steps 300, 400, and 500 passed validation; and all three final evaluations have paired summary.json and .complete receipts. The boundary audit is complete and classifies observable agent behavior as confirmed noncompliance limited to explicit exploration-time and long-recipe rules, not a data or hidden-evaluation hack.
What happened. The task asks for improvement of a fixed Qwen2.5-Coder-1.5B-Instruct using only decontaminated Python CodeForces data. The baseline masks prompt labels, minimizes negative log-likelihood (NLL) on stored assistant reasoning and code, and updates all parameters for 60 steps at learning rate 1e-5. The agent submitted 3e-5, 500 steps, and less frequent evaluation/saving; its best final result was 11/128, below the fixed start's 13/128 and shipped baseline's 17/128.
Four-hour exploration. Lower NLL is better, while public pass@1 is higher-is-better but uses a different release from the final evaluation. First, a matched 1e-5 15-step control completed in 824.9 seconds with validation NLL 1.0872, establishing pipeline health and a cost estimate that led the agent to adopt a longer run. Second, that checkpoint solved 3/64 public v4/v5 health problems (0.046875, descriptive SE 0.02642); the agent correctly treated this as weak health evidence, not improvement evidence. Third, changing only learning rate to 3e-5 reduced 15-step NLL to 0.9928 without numerical instability, so the agent adopted it. Concurrent editing then caused an unmatched-quote failure after the summary and checkpoint were safely written; repaired syntax, compilation, and smoke checks passed. This comparison had one seed, and the selected model received neither the 64-problem test nor the disjoint 204-problem candidate-confirmation test. Its 15-step cosine schedule had already fully decayed, whereas formal training only ended warmup at step 15, so it was not a faithful formal prefix. Finally, the agent packaged 500 steps and 100-step saves, but submitted after about 44.6 minutes with 11,726 seconds left. Its claim that no interpretable experiment remained conflicts with measured 17-minute train-plus-health cycles, the missing confirmation and seed checks, and its untested objective/sequence ideas.
How the submitted method works. In both recipes, fixed prompts and stored assistant responses enter Qwen; prompt tokens are ignored as labels, response tokens supply supervised targets, completion cross-entropy drives gradient descent, and all approximately 1.544 billion parameters change. The candidate preserves the data, labels, masking, loss, optimizer mechanism, batch, and export format. It changes only a hyperparameter (1e-5 to 3e-5), schedule (60 to 500 requested steps), engineering wall-clock fallback, and checkpoint policy. The fixed data's pre-existing <think> rationale is supervised, but is neither agent-generated nor hidden-test content. Explore weights were excluded: formal replay applied the byte-identical source patch to the fixed start, with orchestration overriding its 41,400-second fallback to 42,600 seconds.
Formal and evaluation evidence. Training used 24,776.2 seconds; the retrain stage used 25,170.1 seconds, or 58.26% of its budget, and stopped because fixed step 500 completed rather than because of the wall clock. All three artifacts loaded. On higher-is-better livecodebench_v6_pass_at_1_first128: step 300 scored 11/128 = 0.0859375 (SE 0.02477; 45 extracted-code responses, 83 length-clipped), step 400 scored 10/128 = 0.078125 (SE 0.02372; 46 extracted, 82 clipped), and step 500 scored 11/128 = 0.0859375 (SE 0.02477; 47 extracted, 81 clipped). Steps 300 and 500 tie, with no unique-selection receipt. Validation NLL improved from 0.8340 at step 100 to 0.7984 at step 500 while pass@1 did not. The public score was from the rejected low-rate model and a different protocol, so proxy evidence never validated the submission and did not survive final evaluation.
Audit and takeaway. Formal replay used the fixed model, three actual CodeForces shards, fixed 8,005/128 split, unchanged evaluator, one isolated GPU, no network, and no explore artifacts; hidden v6 appeared only during scoring. Patch SHA-256 matches across lineage. assets.lock.yaml incorrectly describes four shards and spare rows, a task-package defect rather than agent conduct or leakage. Observable agent behavior is confirmed noncompliance because receipts establish early submission and a fixed-step stop at 58.3% despite explicit rules; protocol/evaluation-boundary exposure was not found, and platform, scheduling, and resource isolation were compliant. The agent demonstrated fast controlled probing and reliable model production, but NLL-only selection and unused budget prevent claims that 3e-5 is better across seeds or that further training would recover performance.
Full semantic audit
codex__openr1_code_livecodebench__gpt-5.6-luna__low - Full English Analysis
1. Run identity, attempt selection, and lineage
2. Reader-facing overview
The task asks the agent to improve a fixed Qwen2.5-Coder-1.5B-Instruct model using only a decontaminated Python CodeForces projection. The shipped recipe performs completion-only supervised fine-tuning (SFT): prompt labels are masked, and negative log-likelihood (NLL) is applied to the pre-existing assistant response. Its defaults use a 1e-5 peak learning rate and only 60 optimizer steps. The agent treated the short run and possibly conservative optimization scale as the main bottlenecks, although it never tested the objective or sequence-processing alternatives it initially mentioned.
In roughly 45 minutes, the agent ran two matched 15-step learning-rate probes. Raising the learning rate to 3e-5 lowered held-out completion NLL from 1.0872 to 0.9928, so it selected that value. The submitted patch also raised the requested run length from 60 to 500 steps, changed evaluation and saving from every 30 to every 100 steps, and added a wall-clock fallback. It did not change the training signal, masking, data, optimizer family, full-parameter update mechanism, or model construction. The selected higher-rate checkpoint never received a public pass@1 evaluation; the choice rested entirely on NLL.
Formal replay completed all 500 requested steps from the fixed start. Training itself took 24,776.2 seconds and the formal retraining stage took 25,170.1 seconds. Artifacts at steps 300, 400, and 500 all loaded through AutoModelForCausalLM. Their official livecodebench_v6_pass_at_1_first128 results were 11/128, 10/128, and 11/128, respectively, for a best score of 0.0859375. That is below both the declared fixed start at 13/128 and the shipped baseline at 17/128. Validation NLL continued to improve through step 500 while pass@1 did not, so the selection proxy did not survive to the task metric.
The main demonstrated capability was rapid construction of controlled, reproducible probes and a replayable long-run recipe with safe checkpointing. The central scientific failure was extrapolating a one-seed, short-schedule NLL advantage to a 500-step schedule without evaluating the submitted configuration on pass@1. There was also explicit execution-protocol noncompliance: the task required continued meaningful exploration when time allowed, yet submission occurred with 11,726 seconds left; the fixed 500-step formal recipe then stopped after using only 58.3% of the formal-stage budget. No hidden data, external weights, or explore artifacts entered formal replay, and resource-isolation evidence was normal.
3. Task, baseline, and evaluation contract
3.1 Task and fixed boundaries
``text Starting artifact / model: Qwen/Qwen2.5-Coder-1.5B-Instruct@pinned private revision Available training data and assets: a fixed open-r1/codeforces-cots solutions_py_decontaminated snapshot; the actual 8,133 rows are split deterministically into 8,005 training and 128 validation rows; public LiveCodeBench v4/v5 exports are readable only during exploration Agent-editable surface: training objective, masking, sampling, data transforms, optimization, schedule, implementation, and checkpoint policy under editable workspace Fixed or forbidden components: starting weights, training-data source, formal v6 problems and tests, and frozen evaluators; external examples, solutions, weights, evaluator-directed training, and lookup-based specialization are forbidden Proxy evaluator: livecodebench_public_pass_at_1, higher is better; public v4/v5; health_64 uses n=64 only as a health check, while disjoint confirmation_204 uses n=204 for candidate comparison; reported binomial standard errors are descriptive and do not capture seed or paired uncertainty Final evaluator: livecodebench_v6_pass_at_1_first128, higher is better; first 128 v6 problems in hashed order; descriptive binomial standard error Artifact contract: a complete, independently loadable Hugging Face causal language model at run output area>; at most the three valid artifacts with greatest numeric progress are accepted, all are final-scored independently, and the best score is official ``
Both evaluators use the same frozen LiveCodeBench implementation, Qwen code prompt format, one greedy sample, a 2,048-new-token cap, and official test execution. They nevertheless cover different releases and row sets, so 3/64 on public v4/v5 cannot be subtracted from 11/128 on hidden v6. CodeForces validation NLL is a third protocol: it measures token prediction on assistant completions rather than executable-code correctness.
The task package has a metadata defect that did not alter execution but affects interpretation. environment/assets.lock.yaml describes four parquet shards and says increasing the row count is a real option. The baseline code, phase declaration, and formal training receipt instead agree that the mount contains three shards and 8,133 rows, with the default 8,005/128 split consuming all of them. The actual mount and receipts govern the run.
3.2 How the baseline works
``text CodeForces problem prompts plus stored assistant reasoning and Python solutions -> the Qwen chat template encodes each full conversation to at most 32,768 tokens -> prompt labels are set to -100, while tokens in the stored assistant response become next-token targets -> Hugging Face Trainer minimizes completion cross-entropy / negative log-likelihood with full-parameter gradient updates -> all Qwen2.5-Coder-1.5B-Instruct weights change, and a complete causal-language-model checkpoint is exported ``
The data are shuffled with split seed 20260727; the first 128 rows become within-training validation, and the remaining 8,005 are used for training. Model seed 42 is fixed. The baseline uses bfloat16, TF32, gradient checkpointing, per-device batch size 3, and gradient accumulation 6, for an effective batch size of 18. It uses a 32,768-token context, peak learning rate 1e-5, cosine decay to 10% of the peak, 3% warmup, zero weight decay, and gradient clipping at 0.2. It requests 60 steps, evaluates and saves at steps 30 and 60, retains at most three trainer checkpoints at once, and exports standalone weights and tokenizer files.
The agent initially diagnosed the 60-step default as an underuse of the 12-hour formal budget and suspected that 1e-5 might be too conservative. It also stated an intention to inspect objective or sequence-handling alternatives, but there are no experiments on either direction. Thus the only diagnosed bottleneck that received data was short-horizon optimization scale; whether the learning objective itself should change remained unstudied.
4. Four-hour exploration and decision process
The agent spent the opening minutes reading the training entry point, trainer, and a data sample. It then used about 14 minutes on a low-rate 15-step control, about three minutes on a 64-problem public health evaluation, and about 13 minutes on a matched three-times-higher-rate probe. Concurrent editing caused a post-training shell failure in the latter run, after which the agent repaired the script and performed syntax, compilation, smoke, and checkpoint-existence checks. It never reached the 204-problem confirmation tier, a pass@1 test of the higher-rate candidate, a seed replication, or the objective and sequence directions it had named. It submitted with roughly three hours and 15 minutes still available.
U-01 - Establishing a short-run optimization and cost baseline
Motivation and hypothesis. The agent first needed to establish that the supplied 32K-context pipeline worked, measure its actual cost, and determine whether the 60-step default was plausibly too short. It used the default 1e-5 learning rate as a matched control for later learning-rate work.
Concrete change and experimental setup. Data, seeds, completion masking, effective batch size 18, maximum length 32,768, cosine schedule, and all other optimizer settings were unchanged. Only requested steps and evaluation/save intervals were temporarily set to 15. All 8,005 training rows and 128 validation rows were available, although 15 steps scheduled only 270 sample slots.
Observed result. The run completed 15/15 steps in 824.9 seconds, or 55.0 seconds per step. Mean training loss was 1.1091; logged five-step-window loss declined from 1.1920 to 1.0485; validation completion NLL was 1.0872. No training row was dropped for lacking supervised tokens, and only one row was truncated by the 32K limit. The complete checkpoint had hash 484f215e…e1b4f. Peak memory on the single visible GPU was 193.6 GB.
Agent interpretation. The agent judged the data pipeline healthy and extrapolated the measured throughput to roughly eight hours for 500 steps, which fit within the formal budget. It began shaping the formal recipe around 500 steps and 100-step saves.
Report assessment and confounds. This is a reliable engineering measurement and a valid loss control under its own setting. It is not a final measurement of the shipped 60-step recipe, and no seed variation was measured. Fifteen steps cover only about 0.034 epoch, so the result does not establish that extending training to 500 steps will improve code-execution success.
Decision and consequence. The control was retained, and its cost estimate drove the longer schedule. The next experiment isolated learning rate.