Occamy-1.0 Puts Co-work on a Smaller Bill

Most agent demos sell peak IQ. Occamy-1.0 sells something blunter: finish multi-step work without burning frontier-model money on every turn.

That is the useful hook. The paper is not claiming a new from-scratch foundation model or a tiny AGI box. It is claiming that a post-trained 35B model can become a better worker for long, messy digital tasks where tools, files, code, state, and recovery matter as much as raw reasoning.

Quick Take

• Fact: Accio Team posted arXiv:2609.11977, Occamy-1.0: Open Pareto-frontier 35B Intelligence for Co-work, dated 4 Sep 2026. The authors describe Occamy-1.0 as a cost-efficient co-work model built by further training the post-trained Qwen3.6-35B-A3B checkpoint.
• Why it matters: Agent products usually fail in the boring place first: unit economics. If every workflow needs the biggest hosted model for every step, margins get ugly and users wait longer. Even if the final answer is good, the product can still be too expensive, too slow, or too brittle.

  Occamy-1.0 is interesting because it attacks the worker tier. The useful question i

• Who cares: Builders running long internal agents should care first. If your workflows involve spreadsheets, code repos, dashboards, file systems, docs, tickets, or tool chains, your bottleneck may be finished episodes, not beautiful one-shot answers.
• Judgment: Fairly hyped as an open, cost-aware 35B co-work specialist with concrete author-reported efficiency gains; overhyped if sold as a general frontier replacement or proven production TCO outside the paper's protocol. Fa

What happened

Accio Team posted arXiv:2609.11977, Occamy-1.0: Open Pareto-frontier 35B Intelligence for Co-work, dated 4 Sep 2026. The authors describe Occamy-1.0 as a cost-efficient co-work model built by further training the post-trained Qwen3.6-35B-A3B checkpoint.

Co-work, in their framing, is not one clean chat answer. It is a user-directed episode in a changing digital environment: gather information, call tools, edit files, run code, handle failures, and keep state across many model invocations. That matters because one agent task can involve dozens or hundreds of calls. Cost, latency, timeouts, invalid tool calls, and recovery behavior all stack up before the user sees a finished result.

The paper's pitch is that many practical work steps do not always need frontier-scale reasoning. They need coordination, persistence, and fewer dumb stalls. Occamy-1.0 is trained toward that lane.

The authors describe three main ingredients:

1. Execution-grounded data: tasks come with runnable environments, state transitions, trajectories, graders, and verification before training. 2. Multi-harness capture: logs preserve token-level traces, environment replay, and cases where a harness rewrites history during an episode. 3. Staged post-training: a Marathon Expert for long runs, a Sprint Expert for shorter agent work, a merge of those experts, then more refinement on a broad co-work mix.

The result is presented as an open 35B worker model, with weights listed as Accio-Lab/Occamy-1.0, code in the Accio-Lab occamy repository, and Dressage cited as the opened agentic RL infrastructure.

Why it matters

Agent products usually fail in the boring place first: unit economics. If every workflow needs the biggest hosted model for every step, margins get ugly and users wait longer. Even if the final answer is good, the product can still be too expensive, too slow, or too brittle.

Occamy-1.0 is interesting because it attacks the worker tier. The useful question is not whether it beats every giant model everywhere. The useful question is whether a specialized mid-size model can complete more real work per dollar on long tool loops.

The authors report that Occamy-1.0 lands near the top of comparably sized models across co-work benchmarks including Claw-Eval, WildClawBench, CommerceAgentBench, Business Arena, AutomationBench, GDPval, and related suites. They also argue that the specialization did not collapse broader agentic ability, pointing to supporting tool, coding, and instruction-following evaluations.

On their combined Claw-Eval T/C protocol, they report large gains versus the Qwen3.6-35B-A3B starting point:

• Average score: 69.5 to 82.2
• Pass3: 54.8 to 71.4
• Execution success: 62.81% to 77.55%
• Tokens per trajectory: down 19.5%
• Tool calls: down 15.2%
• Trace wall time: down 46.4%
• Timeouts: 9.88% to 2.18%

That is the part builders should notice. The headline is not just score. It is fewer tokens, fewer tool calls, less wall time, and fewer timeouts on the authors' setup. If that pattern survives outside the paper, it is exactly what agent operators want from a worker model.

The paper also frames Occamy-1.0 as sitting at the low-cost knee of an observed cost-performance Pareto curve across four representative benchmarks. Important caveat: that curve depends on the authors' stated evaluation and pricing protocol, including how local compact models and hosted frontier systems are priced. It is not a guarantee about your cloud bill, hardware utilization, batch size, cache behavior, or orchestration overhead.

Who should care

Builders running long internal agents should care first. If your workflows involve spreadsheets, code repos, dashboards, file systems, docs, tickets, or tool chains, your bottleneck may be finished episodes, not beautiful one-shot answers.

Routing-layer teams should care too. Occamy-1.0 fits the shape of a cheap worker plus expensive reasoner stack: let the specialist grind through routine tool loops, then escalate when the task needs harder reasoning or higher assurance.

Open-weights labs should care because the recipe is concrete. The paper points toward executable contracts, replayable trajectories, multi-harness fidelity, long-run and short-run experts, and post-training aimed at whole-task outcomes.

Skeptics should care because this is the kind of agent claim that can be tested. Do not ask whether the demo looked cool. Ask whether it finishes your workflow more often, with fewer tokens, fewer tool calls, fewer timeouts, and lower cost per successful episode.

What to do this week

Read the abstract, the training setup, the evaluation protocol, and the limitations. Split fact from claim before changing your stack.

If you can self-host 30B to 40B models, A/B Occamy-1.0 against its Qwen3.6-35B-A3B base on one real workflow. Do not only compare final answer quality. Log pass rate, invalid tool calls, timeouts, wall time, token use, retries, and cost per completed episode.

If you only buy hosted APIs, test routing instead. Put a specialist worker model on routine loops and keep a stronger frontier model for planning, ambiguous reasoning, and final review. The goal is not to worship the smaller model. The goal is to stop spending premium tokens where premium reasoning is not moving the outcome.

Also keep the limitations in frame. The authors note gaps around knowledge-heavy docs, simulated-user work, timeout robustness, native browser and visual interaction, and multi-subagent learning. That is not fine print. That is your test plan.

Bottom line

Occamy-1.0 is not AGI in a 35B box. It is a serious open attempt to train co-work execution as the product.

If independent users reproduce a meaningful slice of the reported gains, mid-size agent workers just got a sharper baseline. If they do not, the paper still pushes the right measurement habit: judge agents by finished episodes, not just smart-looking turns.

Bandwagon Check

Fairly hyped as an open, cost-aware 35B co-work specialist with concrete author-reported efficiency gains; overhyped if sold as a general frontier replacement or proven production TCO outside the paper's protocol. Fa

Sources

• Occamy-1.0: Open Pareto-frontier 35B Intelligence for Co-work
• Occamy-1.0: Open Pareto-frontier 35B Intelligence for Co-work (arXiv:2609.11977)
• arXiv PDF
• Model weights: Accio-Lab/Occamy-1.0
• Occamy GitHub
• Dressage

By Sean Smith · AI Bandwagon