Commit History
-
Wave 3: integration architecture + spike-005 trainer skeleton (16 tests pass)
baladithyabUser asked: can RLVR + Composer-SDPO + N-teacher-replay all integrate complementarily with the PyTorch agentic-RL stack (Monarch / TorchForge / OpenEnv / VeRL / TRL)? Answer (verified, not extrapolated): YES, with concrete extension points: 1. Verified ground-truth integration surfaces via DeepWiki audits: - TRL: subclass GRPOTrainer, override _compute_loss(model, inputs); plug OpenEnv via environment_factory= kwarg. - VeRL: register a new advantage estimator via @register_adv_est(name); attach extra fields to DataProto.batch / non_tensor_batch (precedent exists — distillation already uses 'teacher_log_probs' the same way). - OPSD: generalized_jsd_loss is a self-contained static method, MIT, directly liftable. FlashAttention-2 compatible, standard PyTorch. 2. NEW docs/INTEGRATION_ARCHITECTURE.md (30KB): - Per-framework integration matrix (TRL / VeRL / TorchForge / Monarch / OpenEnv) × per-channel (RLVR / SDPO / N-teacher-replay). - Sequence di…fd77f74 -
Integrate Cursor blog directly + audit research note + add SDPO/OPSD link
baladithyabUser flagged a real gap: I had dispatched a subagent to research Composer 2.5 but never personally read the Cursor blog. Audit findings: 1. The targeted-textual-feedback method = published SDPO (Hubotter et al., arXiv:2601.20802, ICLR 2026 Workshop) + OPSD (Zhao et al., arXiv:2601.18734, code at github.com/siyan-zhao/OPSD, MIT). Cursor cites these directly in footnote 1 of the blog. The subagent's research note never mentioned them. This is huge: there's published, MIT-licensed code for Composer's secret sauce. 2. Several claims in research/01-composer-2.5.md are NOT in the Cursor blog and were extrapolated from secondary sources ("85% post-training compute", "Anyrun" environment name, specific benchmark scores, "PPO or GRPO variant"). Likely correct via community consensus but not blog-verified. 3. Composer hint-distill (single model, hint-conditioned context) and trace-replay-distill (N external teachers) are TWO genuinely different mechanisms, not compe…1cede23 -
Spike v0.0 laydown + spike 001 VALIDATED
Decompose v0.0 into 4 risk-ordered sub-spikes: - 001 teacher-replay-cost (kill-switch, ✅ EXECUTED + VALIDATED in this commit) - 002a trace-collection-trl (planned) - 002b trace-collection-prime-rl (comparison-spike) - 003 dpo-pairs-from-disagreement (planned) - 004 ab-train-grpo-vs-trace-replay-dpo (terminal experiment) Spike 001 result (real, not scaffolding): - 150 teacher API calls (Opus 4.7 + GPT-5 + DeepSeek V4 Pro via OpenRouter) - 50 synthesized agentic-coding states as fixture - 0 errors, total spend $0.98 - Mean per-trace cost: $0.98 (target: <$5) ✅ — 5x headroom - p95 step latency: 20.5s (target: <30s) ✅ - p99 step latency: 23.2s (target: <60s) ✅ - Cost composition: Opus dominates ($0.81 of $0.98); DeepSeek + GPT-5 essentially free This validates the framework's central economic claim. Even ungated (no VOI, no tiered teachers), cost is ~$1/trace not $64/trace. With VOI gating in v0.1 we project ~$0.30/trace. Trace-replay-distillation is economically viable. Files: - spikes…35581fd -
Initial commit: Composer 2.5 Replication Framework — research synthesis
Methodology repo (model type) for an open replication of Cursor's Composer 2.5 (post-trained Kimi K2.5) on any HuggingFace base model. Contents: - README.md (HF model card with frontmatter) - framework/composer-replication-framework.md (master synthesis, 18KB) - research/ (5 deep-dives by 5 different LLM families, ~107KB total) - 01-composer-2.5.md (Gemini 3.1 Pro) - 02-diloco-family.md (DeepSeek V4 Pro) - 03-monarch-torchforge-openenv.md (GPT-5) - 04-verl-trl.md (Sonnet 4.6) - 05-trace-replay-distillation.md (Kimi K2-Thinking) - docs/METHODOLOGY.md (how the synthesis was produced) - docs/HF_REPO_LAYOUT.md (planned multi-repo split) - LICENSE (MIT) Status: pre-spike. No code, no weights, no datasets yet. Trained variants and trace datasets will live in separate repos linked via HF Collection.7165832