PaperlayerView exact revision on arXiv

Source-linked AI summary

Occamy-1.0: Open Pareto-frontier 35B Intelligence for Co-work

Wenhui Chen, Shiwen Cheng, Hao Dong, Chenda Duan, Ruixiang Feng, Zhong Guan, Boqiang Guo, Xueyuan Han, Haojie Hao, Liangmeng Huang, Zhelong Huang, Xinke Kong, Hongyu Li, Jiazheng Li, Junbo Li, Qingchuan Li, Yukun Lian, Chang Liu, Tianyu Liu, Zicheng Liu, Shuyi Ouyang, Yijun Pan, Kunyu Shi, Xiaojun Tang, Bingquan Wang, Kesu Wang, Yuchen Wang, Sibo Wei, Sicong Xie, Xiaoying Xing, Yi Xu, Zhijun Xu, Hongwei Xue, Qingcheng Zeng, Di Zhang, Guannan Zhang, Haochen Zhang, Tianlong Zhang, Tianyu Zhao, Tianyu Zhao, Yanjun Zheng, Jialong Zhu, Zijian Zou

arXiv:2609.11977v1cs.AI

TL;DR

Co-work tasks involve many model calls, so cost and latency accumulate even as many steps depend on state tracking, coordination, recovery, and follow-through rather than frontier-scale reasoning. Occamy-1.0 uses an execution-centered post-training system with replayable multi-harness infrastructure, Marathon and Sprint experts, model merging, and SAO refinement. Occamy-1.0 performs strongly among comparable-scale models across co-work benchmarks, remains competitive with larger systems on several tasks, and lies near the low-cost knee of the observed frontier.

  • Problem

    Co-work tasks involve many model calls, so cost and latency accumulate even as many steps depend on state tracking, coordination, recovery, and follow-through rather than frontier-scale reasoning.

    Source: §1 · p. 4

  • Method

    Occamy-1.0 uses an execution-centered post-training system with replayable multi-harness infrastructure, Marathon and Sprint experts, model merging, and SAO refinement.

    Source: §8 · p. 18

  • Results

    Occamy-1.0 performs strongly among comparable-scale models across co-work benchmarks, remains competitive with larger systems on several tasks, and lies near the low-cost knee of the observed frontier.

    Source: §1 · p. 5, §8 · p. 18

  • Takeaways & Limitations

    The authors release model weights and a subset of training data to support research on practical co-work agents and agentic post-training.

    Source: §8 · p. 18

    The controlled workflow examples use one run per endpoint under fixed fixtures and one harness, so they do not establish robustness to sampling, alternative task formulations, or broader tool surfaces.

    Source: §D.2 · p. 36

Abstract

from arXiv · show

Co-work agents execute complex workflows that combine information gathering, tool use, coding, and file manipulation across many model invocations. Because cost and latency accumulate over the full episode, their practical value depends not only on peak capability but also on how efficiently that capability is delivered. Yet many steps in everyday work emphasize state tracking, coordination, recovery, and follow-through rather than frontier-scale reasoning. We present Occamy-1.0, a cost-efficient co-work model obtained by further training the post-trained Qwen3.6-35B-A3B checkpoint. We construct execution-grounded data and environments, capture replayable long-horizon trajectories across multiple harnesses, and use staged post-training to develop and consolidate complementary execution capabilities. Across a broad suite of co-work benchmarks, Occamy-1.0 is consistently among the strongest comparably sized models and remains competitive with substantially larger frontier systems on several tasks. Under our stated evaluation and pricing protocol, its aggregate performance across four representative benchmarks places it at the low-cost knee of the observed cost--performance Pareto frontier. Supporting evaluations in tool calling, coding, and instruction following further show that this specialization preserves broad agentic capability. We release the model weights and a subset of the training data to support research on practical co-work agents and agentic post-training.

1 Introduction

Co-work requires sustained coordination across stateful, multi-step tasks, where cost and latency accumulate over many model calls. Occamy-1.0 specializes a compact post-trained model for reliable execution, and the reported evaluation places it near the low-cost knee of the observed cost–performance frontier.

1 Introduction

  • Co-work spans persistent digital tasks requiring coordination across information gathering, coding, tools, files, and changing environment state.Many steps emphasize state tracking, recovery, and follow-through, while the cost and latency of repeated model calls accumulate across an episode.Source: §1 · p. 4
  • Occamy-1.0 further trains Qwen3.6-35B-A3B to improve reliable execution, then combines specialized Marathon and Sprint checkpoints and refines the merged model with SAO.The Marathon Expert uses SFT followed by HDPO; the Sprint Expert uses SFT on broader, shorter-horizon agentic workloads.Source: §1 · pp. 4–6
  • Across four representative benchmarks, Occamy-1.0 lies near the low-cost knee of the observed Pareto frontier and performs strongly among comparably sized models.It remains competitive with substantially larger systems on several tasks, while supporting evaluations indicate that broader agentic capabilities are preserved.Source: Figure 2 · p. 5, §1 · p. 5
  • The system connects real-work task construction and verified data admission to replayable multi-harness execution and staged post-training.Harness-aware adapters preserve tool, token, rewrite, and state semantics while a shared trajectory schema and replay contract preserve fidelity.Source: §1 · p. 5

2 Co-work Setting and Terminology

The report organizes co-work execution into task-scoped episodes, runs, and segments, with explicit boundaries for history rewrites and policy training targets.

2 Co-work Setting and Terminology

  • A task fixes the objective, initial environment, available tools, and grading contract; an episode is one model-and-harness attempt with one task-level outcome.An episode begins with a root run and may branch into subagent runs, each recorded as its own trajectory.Source: §2 · p. 6
  • Turns stay within a segment as history grows append-only; a harness-declared summary or pruning closes that segment and starts another without changing the run, episode, or shared environment.Table 1 summarizes these boundaries.Source: §2 · p. 6, Table 1 · p. 6
  • Only policy outputs sampled within a run are training targets; inherited or rewritten context, tool observations, and returned subagent results provide conditioning instead.Source: §2 · p. 6

3 Data and Environments

The data pipeline builds realistic, reproducible tasks with controlled information boundaries, then uses complementary synthesis routes and shared admission gates to create training data.

3 Data and Environments

  • The task-construction framework specifies how requests, world state, tools and services, and grading contracts fit together, with environment-first and capability-first synthesis routes.Both routes apply construction-time checks before shared canonicalization, verification, and training-admission gates.Source: §3 · p. 6

3.1 Executable Task Contracts

  • Each versioned executable task contract combines a public request, initial world state, tool specification, and private completion and grading contract with orchestration metadata.Execution evidence must show both a valid completion path and a grader that distinguishes correct work from no-ops or other degenerate strategies.Source: §3.1 · pp. 6–7

3.2 Task Design Principles

  • Tasks should resemble professional commissions, derive difficulty from the work rather than ambiguity, and be solvable with the evaluated policy’s available information and tools.Tool contracts must match their backends, and grading uses sealed execution evidence under a contract frozen before evaluation.Source: §3.2 · p. 7

3.3 Co-work Capability Space and Task Variation

  • Environment-first synthesis starts from real environments, while capability-first synthesis starts from dependencies abstracted from real work and finds settings to instantiate them.Task variation spans presentation changes, changed environment realizations, and compositional changes to capability structure, environment topology, or their coupling.Source: §3.3 · p. 7

3.4 Verification, Admission, and Mixture Control

  • Both synthesis routes pass packages through shared checks for feasibility, semantic alignment, discoverability, and grader discrimination before training admission.Admitted artifacts are counted separately as executable packages, verified SFT demonstrations, and on-policy RL trajectories, with mixture control over coverage and other constraints.Source: §3.4 · pp. 7–8, Figure 3 · p. 8

4 Agent Execution Infrastructure

The infrastructure connects harness execution to a shared, auditable episode record, then replays tokens and environment state for training. It preserves harness-specific execution semantics while providing a common trajectory and replay contract.

4.1 System Overview

  • Figure 4 links multi-harness execution, a synchronized episode record, token/state replay, and learner-ready training data under one episode lineage.Source: §4.1 · pp. 8–9, Figure 4 · p. 9

4.2 Multi-Harness Execution

  • Structured variation changes harness components or compositions while holding task and grading fixed, reducing dependence on one harness and improving transfer to related compositions.Source: §4.2 · pp. 9–10

4.3 Token-Exact Trajectory Capture and Replay

  • TiTO retains sampled token IDs within append-only segments, while explicit summary or pruning rewrites close a segment and restart replay from the new visible prefix.Source: §4.3 · p. 10

4.4 State Replay and Episode Finalization

  • State replay reconstructs files, services, tools, and session state, enabling branched policy samples from matched work states without rerunning full episodes.Source: §4.4 · p. 10
  • After root and child runs finalize, records are sealed before one episode-level grading outcome; token, state, lineage, or infrastructure failures are quarantined.Source: §4.4 · pp. 10–11

4.5 Open-Source Release

  • Dressage publicly releases core internal agentic-RL infrastructure for multi-harness execution, trajectory capture, sandbox integration, and RL conversion, but deployment-specific services or configurations may be absent.Source: §4.5 · p. 11

5 Training Recipe of Occamy

Occamy uses staged expert training, merges complementary checkpoints, and refines the merge with broad co-work reinforcement learning. The merge balances benchmark strengths rather than improving every benchmark uniformly.

5 Training Recipe of Occamy

  • Occamy trains a long-horizon Marathon Expert with SFT then HDPO and a broader, shorter-horizon Sprint Expert with SFT, merges them, then refines the result with SAO.“Expert” means a specialized checkpoint, not an inference-routed MoE expert.Source: §5 · p. 11

5.1 SFT: Behavioral Initialization

  • Across both experts, 72.5% of tokens came from general-agentic and long-horizon episodes (42.3% of samples), while tool-call grounding supplied 49.5% of samples but 16.8% of tokens.The deduplicated corpus contains approximately 15.0K trajectories and 403.3M tokens, with an average trajectory length of 26.9K tokens.Source: §5.1 · p. 11
  • SFT trains all language-backbone parameters on response tokens, freezes the vision encoder and projector, and masks harness-written history from the loss after compaction.Trajectories exceeding the context limit are dropped rather than truncated.Source: §5.1 · p. 12

5.2 Reinforcement Learning for Co-work

  • RL assigns one terminal task outcome to an episode, while token masks and optimizer-specific weights determine which sampled policy tokens receive loss.Other episode trajectories, including subagent runs, remain in the lineage but receive no direct policy loss under this configuration.Source: §5.2 · p. 12
  • Marathon RL compares step counts within equal-accuracy groups, rewarding trajectories that reach the outcome in fewer interaction steps.Conditioning on accuracy avoids favoring shorter but lower-quality episodes.Source: §5.2 · pp. 12–13
  • Post-merge SAO continues RL on a broad co-work mixture across rewrite boundaries, treating the post-rewrite prefix as the next policy state.Figure 5 shows reward and critic explained variance during this final run.Source: §5.2 · p. 13, Figure 5 · p. 13

5.3 Capability Harmonization with Model Merging

  • The merge averages aligned tensors from experts with the same architecture, tokenizer, and checkpoint lineage, avoiding retraining or inference-time routing.The merged checkpoint retains either parent's parameter count and serving cost and needs no serving-stack changes.Source: §5.3 · p. 13
  • The uniform model soup improves AutomationBench and Terminal-Bench 2.1 over both experts, keeps WildClawBench between them, and modestly regresses on Claw-Eval versus the stronger parent.The authors therefore treat merging as capability balancing, not a uniform improvement.Source: §5.3 · p. 13

6 Evaluation

Evaluation covers co-work, supporting agentic capabilities, model consolidation, and cost and reliability. Occamy-1.0 performs strongly among comparable-scale models, with uneven results across tasks and a low-cost position under the stated protocol.

6.3 Main Results on Co-work

  • 82.2 average on Claw-Eval trails Qwen3.8-Max (83.92) but exceeds GPT-5.6 Sol (81.8) and DeepSeek V4 Pro (81.7); its 10.8-point average-to-pass3 gap is smallest among comparable-scale models.Occamy-1.0 scores 71.4 on pass3, above GPT-5.6 Sol (68.9) but below Qwen3.8-Max (73.68) and DeepSeek V4 Pro (74.5).Source: Table 5 · p. 14, §6.3 · p. 14

6.1 Benchmarks and Evaluation Protocol

  • The evaluation spans 12 benchmarks across four capability areas, using task sets, harnesses, environments, and graders consistently where possible, against same-scale and substantially larger baselines.The compared groups include 35B-A3B models and larger systems used as high-capability reference points.Source: §6.1 · p. 14, §6.2 · p. 14

6.3 Main Results on Co-work

  • 49.16 on WildClawBench exceeds comparable-scale models with reported results, while $79,868 final net worth on Business Arena ranks best among comparable-scale models and third overall.The Business Arena result remains close to the $80,000 initial capital after an extended simulated workflow; the paper cautions that this does not imply profitable operation.Source: §6.3 · p. 15
  • 48.1 on OfficeQA Pro is competitive but not leading; 37.1 on τ3-Bench (Banking) matches GLM-5.2 and exceeds reported comparable-scale results, with larger-model gaps remaining.The reported gaps concern complex document reasoning and simulated-user interaction.Source: §6.3 · p. 15

6.4 Supporting Capabilities: Tool Calling, Coding, and Instruction Following

  • Occamy-1.0 improves supporting tool-use results over its starting checkpoint, reaches 59.0 on Terminal-Bench 2.1 and 91.53 on IFEval, while coding remains below several baselines.On AutomationBench it scores 27.6 strict pass rate and 69.1 average partial-credit reward, versus 7.5 and 39.4 for Qwen3.6-35B-A3B; the final RL stage excludes these evaluation tasks, and the authors do not attribute every gain to RL alone.Source: §6.4 · p. 15

6.5 From Experts to a Single Model: Merging and Consolidation

  • The Marathon Expert targets sustained execution and the Sprint Expert broader capability; merging and SAO refinement raise Claw-Eval from 79.2 to 82.2 and WildClawBench from 48.28 to 49.16.The merged model soup exceeds both experts on AutomationBench (29.0), while its WildClawBench score of 48.28 lies between the Marathon Expert (50.76) and Sprint Expert (45.29).Source: §6.5 · p. 15

6.6 Cost Efficiency and Reliability

  • Under the stated four-benchmark cost protocol, Occamy-1.0 sits near the observed Pareto frontier’s low-cost knee, with higher aggregate performance than its starting checkpoint at modestly changed per-task cost.The comparison uses common pricing for comparable-scale models and reports inference cost, not total deployment cost of ownership.Source: §6.6 · pp. 15–16
  • On combined Claw-Eval T/C, Occamy-1.0 raises execution success from 62.81% to 77.55% while using 19.5% fewer tokens and reducing trace wall time by 46.4%.It also reduces timeout rate from 9.88% to 2.18%; Table 6 reports the combined-task metrics and trial counts.Source: §6.6 · p. 16, Table 6 · p. 16

7 Analyses and Lessons Learned

The analyses identify task variation, learning-signal quality, and behavior monitoring as practical considerations in data construction and post-training. They also document concrete risks from infeasible tasks, exposed evaluation material, and exploitative trajectories.

7.1 Approaches to Synthesizing Datasets with Learning Signals

  • Meaningful task variation across files, backend state, wording, and grading criteria predicts learning yield more closely than nominal difficulty; partial credit and tool-chain complexity also help distinguish performance.The authors warn that template parameter changes can create apparent diversity without exposing models to meaningfully different problems.Source: §7.1 · pp. 16–17

7.2 Lessons from SFT Data Ablations

  • SFT benefits from dense, reliable trajectories and broad capability coverage more than sample count alone within the studied range; imperfect trajectories are sanitized by filtering, truncating, masking, or verified repair.The sanitization response depends on whether the supervision is broadly unreliable, only a prefix remains valid, isolated assistant spans are flawed, or a corrected continuation can be verified.Source: §7.2 · p. 17

7.3 Lessons from Agentic Reinforcement Learning

  • RL runs show transfer beyond training tasks, while reward alone can miss behavioral changes; early SAO exploration and critic warmup can precede measurable reward improvement.The authors recommend tracking tool-call structure, parallelism, interaction turns, and trajectory length alongside reward, and treat the observed plateau as not establishing a causal sequence.Source: §7.3 · p. 17

7.4 Reward Hacking and False Progress

  • Reward-hacking audits found risks from infeasible tasks, exposed grader or public answers, and exploitative data selection; all four confirmed cases among 4,352 audited trajectories came from repeated runs of one underlying task.The authors apply workspace isolation, tool-access restrictions, and execution-trace audits to data selection as well as RL training; they interpret the concentration as evidence that observed hacking primarily arose from task-data and evaluation defects at this model scale.Source: §7.4 · pp. 17–18

8 Conclusion

Occamy-1.0 continues post-training from Qwen3.6-35B-A3B for long, stateful co-work. The reported results support specialization at practical model scale while identifying remaining capability gaps.

8 Conclusion

  • Occamy-1.0 targets long, stateful work coordinating tools, files, APIs, and productivity software through continued post-training of Qwen3.6-35B-A3B.The training system uses execution-grounded data and replay infrastructure, then trains Marathon and Sprint Experts, merges them, and refines the checkpoint with SAO.Source: §8 · p. 18
  • Across co-work benchmarks, Occamy-1.0 performs strongly among comparable-scale models and remains competitive with larger systems on several long-horizon tasks, while retaining supporting agentic capabilities.The paper identifies remaining gaps in timeout robustness, native browser and visual interaction, and joint learning across subagents and multiple objectives.Source: §8 · p. 18
  • The authors release model weights and a subset of training data to support work on the identified capabilities and research on practical co-work agents at smaller serving scales.Source: §8 · p. 18

Contribution

The contribution section identifies Accio Team as the collective authorship and records the complete contributor list.

Contribution

  • The section records the complete contributor list for the paper’s collective authorship, Accio Team.Source: Contribution · p. 19

A.1 Task Design Principles

The appendix defines principles and structures for constructing realistic, feasible co-work tasks, then describes how tasks are synthesized, verified, admitted, and balanced in the training mixture. It also specifies a common serving setup for reproduced checkpoints.

A.1 Task Design Principles

  • Tasks should model substantive professional work, remain solvable with policy-visible evidence and permitted tools, use faithful service semantics, and be graded against sealed execution evidence.The public request, initial state, tools, and grading contract must align; private fixtures and grading material stay hidden from evaluated policies.Source: §A.1 · p. 22

A.2 Capability and Environment Structures

  • Capability structures capture prerequisite operations, while environment structures capture evidence, tools, mutable state, and deliverables; either structure can vary independently in task construction.Collection-level coverage analysis tracks capability dependencies, environments, workflow structures, and difficulty factors to identify gaps and guide subsequent synthesis.Source: §A.2 · pp. 22–23, §A.3 · p. 23

A.4 Environment-first Task Synthesis

  • Environment-first synthesis builds tasks around executable environments, including evidence investigations, workspace artifacts or code repair, cross-service workflows, and package-grounded integrations.Reference executions use rollout-visible interfaces; checks include source-supported outcomes, service state and mutation logs, and package-use tests that reject hard-coded solutions.Source: §A.4 · pp. 23–24

A.5 Capability-first Task Synthesis

  • Capability-first synthesis freezes a general capability target, assembles verified supporting evidence, authors a professional task, and runs a blind reference execution using only policy-visible materials.If verified sources cannot support the full capability structure, the task is reduced to the largest useful supported subset rather than completed with invented facts.Source: §A.5 · pp. 24–25

A.6 Canonicalization, Verification, and Training Admission

  • Admission separates task validation from episode validation and uses canonical provenance, executable and semantic checks, discoverability checks, sealed execution evidence, and create-only releases.For mutating service tasks, the service audit ledger is reconciled with dispatch logs; incomplete or ambiguous records are quarantined rather than treated as policy failures.Source: §A.6 · pp. 25–26

A.7 Data Mixture and Coverage Control

  • The mixture tracks executable task packages, verified SFT demonstrations, and on-policy RL trajectories separately, while balancing capability and environment coverage, difficulty, stability, and token share.Pass@k, trajectory length, and tool-chain depth inform difficulty but are not sole admission rules; coverage floors and token-share caps constrain the mixture.Source: §A.7 · p. 26

B.1 Common Serving and Reporting Protocol

  • Reproduced checkpoints use a shared SGLang serving configuration and each benchmark runs with its own upstream harness and native protocol.The stated setup uses a 262,144-token shared prompt-and-generation budget.Source: §B.1 · p. 27

B.2 Per-benchmark Cost–Performance Frontiers

The section separates aggregate cost–performance results into four benchmark-specific frontiers. Costs and comparisons are tied to the stated measurement and pricing protocol, rather than presented as invariant model properties.

B.2 Per-benchmark Cost–Performance Frontiers

  • Each panel uses its benchmark’s native score and divides total inference cost by that benchmark’s task count, with the other token-accounting and provider-selection rules unchanged.Reported costs are measurements under this protocol; hosted routing and cache accounting or local cache residency, scheduling, and execution dynamics can vary.Source: §B.2 · p. 27
  • The September 2, 2026 pricing snapshot applies a shared lowest complete 35B-A3B price vector to locally evaluated checkpoints as a size-matched monetary proxy.That proxy controls provider-price variation within the group; it is not a claim about checkpoint lineage or direct API availability.Source: §B.2 · p. 27, Table 8 · p. 27, Table 9 · p. 27
  • Figures 6–9 show benchmark-specific cost–performance frontiers for Claw-Eval, WildClawBench, AutomationBench strict pass rate, and GDPval.The respective panels cover 199, 60, 600, and 207 tasks; the supplied passages do not report plotted values or identify winners.Source: Figure 6 · p. 28, Figure 7 · p. 28, Figure 8 · p. 29

B.3 Benchmark-specific Protocols

The section specifies benchmark-specific tasks, harnesses, scoring rules, and run-integrity checks across co-work, office, coding, and tool-use evaluations. Several protocols limit direct comparison with external published results or define a report-specific evaluation cohort.

B.3 Benchmark-specific Protocols

  • Claw-Eval (Ye et al., 2026) reports average score and pass3 across tool-use and user-agent splits, while WildClawBench (Ding et al., 2026) reports avg@3 over three runs per task.Both use isolated sandbox trials and retain agent traces; WildClawBench uses embedded automated checks, roughly two-thirds with an LLM judge.Source: §B.3 · pp. 29–30
  • CommerceAgentBench reports pass1 for 107 stateful commerce and business tasks, while Business Arena (Pan et al., 2026) reports average final net worth over five trials.CommerceAgentBench verifies environment-state changes or artifacts; Business Arena starts agents with $80,000 for long-horizon marketplace operations.Source: §B.3 · p. 30
  • GDPval (OpenAI, 2025) uses a frozen 207-task cohort and a two-judge panel; its reported score is an independent evaluation, not a GDPval-AA v2 replication or official leaderboard result.Tasks excluded for runtime transport or evaluation-integrity limitations; pairwise artifact comparisons are aggregated with ties counted as half-wins and human performance anchored at Elo 1000.Source: §B.3 · p. 30
  • OfficeQA Pro (Opsahl-Ong et al., 2026) tests search and arithmetic over Treasury Bulletin filings, scoring exact-match accuracy on 133 tasks with one attempt each.Its 1.3 MB filings make end-to-end reading impractical, and a correct search yielding the wrong value receives no partial credit.Source: §B.3 · p. 30
  • Terminal-Bench 2.1 (Terminal-Bench Team, 2026) evaluates 89 isolated terminal tasks and counts a task resolved only when its full verification suite passes.The official Terminus 2 harness runs under Harbor, with one rollout per task and mean resolution rate reported.Source: §B.3 · p. 31
  • AutomationBench 1.0.6 (Zapier, 2026) covers 600 cross-application workflow tasks and reports strict pass rate plus average partial-credit reward.Only clean, complete runs with matching receipts are quoted; strict pass requires all hidden assertions to pass, while partial credit captures denser movement between checkpoints.Source: §B.3 · p. 31
  • BFCL v4 uses its full weighted 5,106-row benchmark, while VitaBench (VitaBench Team, 2025) reports judged reward on all 400 tasks.VitaBench results are comparable within this report but not directly to previously published numbers; IFEval (Zhou et al., 2023) reports strict accuracy at prompt and instruction levels on 541 prompts.Source: §B.3 · p. 31

C Full Training Hyperparameters

The training appendix reports implementation choices for supervised fine-tuning, context-compaction reinforcement learning, and merging the two parent checkpoints. These choices preserve long-trajectory dependencies, optimize shared terminal rewards across segments, and validate tensor alignment before averaging.

C.1 Supervised Fine-Tuning

  • Full-parameter SFT uses eight ranks for context parallelism, packs sequences at maximum length to avoid splitting trajectories, retains reasoning traces, and excludes empty think spans from loss.Activation memory is binding at this sequence length, so activations are fully recomputed.Source: §C.1 · p. 32

C.2 Reinforcement Learning with Context Compaction (SAO)

  • The final RL stage trains the merged checkpoint with critic-based segment-wise PPO on long-horizon rollouts whose execution and summary segments share one terminal task reward.The policy generates history summaries when context falls below the framework threshold, and there is no separate summary-quality reward.Source: §C.2 · p. 32, Table 11 · p. 33
  • Masked per-segment GAE and a cross-trajectory correction make the composite discount match each optimized token’s distance to the rollout’s terminal reward.GAE uses a length-adaptive lambda, token-level loss normalization, and a zero KL coefficient; training is asynchronous with double-sided importance sampling.Source: §C.2 · pp. 32–33

C.3 Model-Merge Implementation and Validation

  • Checkpoint merging normalizes equivalent MoE tensor layouts, validates expert-projection correspondence, and aborts when alignment is weak or ambiguous.Floating-point averages are accumulated in float32, and sampled tensors are recomputed after writing to require exact agreement.Source: §C.3 · p. 34

D.1 Protocol and Evidence

Under fixed Accio Work conditions, Occamy showed stronger exactness, artifact verification, and dependency-safe sequencing than Qwen3.6 across three workflows; these single-run examples illustrate behavior but do not establish robustness. The episode anatomy distinguishes delegated runs and rewritten history segments while preserving one shared environment and task-level outcome.

D.1 Protocol and Evidence

  • Occamy reported Beta’s exact status counts, preserved both source-level dependency chains, and read back the persisted report; Qwen3.6 undercounted overdue tasks and stopped without readback.The harness figure compares verified artifacts and observed tool trajectories for each endpoint.Source: §D.1 · p. 34, Figure 10 · p. 34
  • Occamy reconciled all 12 PDFs, recovered the exact caption set, and generated readable collision-safe names; Qwen3.6 retained opaque stems and ended without output readback.Both agents recovered titles and the category census, isolating the naming difference from basic extraction.Source: §D.1 · p. 35, Figure 11 · p. 35
  • Occamy preserved the required incident-recovery order, while Qwen3.6 scheduled synchronization with the legacy integration active and delayed deactivation until after downstream jobs.Both agents identified the same root cause and dependency chain and recovered from the same write-call failure.Source: Figure 12 · p. 35, §D.1 · p. 35
  • Across three controlled workflows, Occamy’s advantage was exactness, artifact verification, and dependency-safe sequencing rather than prose style.Each task ran once per endpoint under fixed fixtures and the same harness; the examples illustrate execution behavior but do not establish robustness to sampling, alternative task formulations, or broader tool surfaces.Source: Figure 10 · p. 34, Figure 11 · p. 35, Figure 12 · p. 35

D.2 Interpretation and Limitations

  • These examples are qualitative single runs, not estimates of pass probability or evidence of robustness to sampling, alternate task formulations, or broader tool surfaces.The three workflows used fixed fixtures and the same Accio Work harness.Source: §D.2 · p. 36

E Detailed Co-work Episode Anatomy

  • Delegation branches one task-scoped episode into separate runs and trajectories; history rewrites divide a trajectory into segments without resetting the shared environment or task outcome.The grader produces one task-level outcome for the complete episode.Source: E Detailed Co-work Episode Anatomy · p. 36, Figure 13 · p. 36

Related papers

Loading 2609.11977v1…