Brian Bartoldson @bartoldson

I'll be presenting 3 papers at ICML 2026🫡 h1 (Spotlight) trains models to reason over longer horizons using curriculum RL over composed short-horizon data. This allows models to generalize to harder tasks and improves performance even at high pass@k. LongCoT isolates and benchmarks long-horizon CoT capabilities, pushing models to reason over tens and hundreds of thousands of tokens in an output. Rubric Curriculum RL uses the generation-verification gap in non-verifiable domains to allow models to self-improve on tasks like creative writing and planning. More about this project to come soon! Very grateful for amazing collaborators @CharlieLondon02 @bartoldson @DanielNichols10 @AmyPrb @hammh0a @jackcai1206 @bkailkhu @casdewitt @sytelus @riashatislam @philiptorr, and especially co-leads Alesia and Tejas! If you're interested in these topics, my DMs are open :)

@cthorrez @dylanmatt Agree that it's not their raison d'etre, but perhaps a side quest? Showing how things could go wrong in order to inform policymakers was an explicitly stated motivation for lesswrong.com/posts/ChDH335c…

The robustness/accuracy you get from scaling is predicted to peak at 90%. However, it seems like 90% robustness/accuracy on this particular task may be equivalent to 100% reliability. This discrepancy arises because of a weakness in the CIFAR-10 l_inf norm threat model our field has been studying: for a small subset of images, there exist small l_inf norm perturbations that, surprisingly, change the appropriate label. In particular, we found that 10% of attacked data doesn't fit the definition of a "jailbreak". On this 10% subset, the attacker's change to the input image -- while successfully causing NNs to change their prediction, in line with the attacker's goal -- actually makes the original label for the image a worse description of the post-attack changed image than the new label that NNs assigned to the post-attack changed image (according to a human study we did). I.e., on that 10% subset, the NNs are apparently operating reliably by changing their label, and the attack is not really tricking them. In sum, the evidence suggests that hitting 90% robustness/accuracy could correspond to 100% reliability. Supporting this, we found that humans appear to have a 90% limit on this benchmark too, for the same reason (use of label-changing attacks). Note that, under a more careful threat model -- where attacker perturbations never change the appropriate label/response -- 100% reliability would imply 100% robustness/accuracy. The field has been using the less careful threat model with the aforementioned issue because it's computationally efficient to compute an l_inf norm bounded perturbation, and much more difficult to compute a label-preserving perturbation (you need a human labeler in the loop for this).

We trained language models that compress massive contexts into tiny latent representations. Latent Context Language Models (LCLMs) outperform existing KV cache compression methods on the latency/accuracy frontier. 🧵1/10

Recordings and the full recap from the Assurance and Verification of AI Development (AViD) Workshop are live. We co-hosted with @ai_risks on May 17, colocated with IEEE S&P. The question: how do you generate trustworthy evidence about an AI system without unrestricted access to weights or infrastructure? 1/6

@saprmarks Very interesting, thanks for sharing these! It seems like a lot of recent robustness/alignment works are leveraging pretraining interventions -- another one: our ICLR 2026 paper finds that specs can stop white box attacks if the right training set is used x.com/i/status/20374…

Brian Bartoldson @bartoldson

3 months ago

Give an LLM a spec: more reasoning ➡️ better spec satisfaction. Even on adversarially attacked data. But reasoning benefits fade if attacks are stronger (e.g. white-box or multimodal). Our hypothesis suggests reasoning can stop such attacks. Toy example in the video. 🧵

1 6 31 8K 20

@amolk @sumeetrm Depending on your definition of harness, I think this is close to (if not exactly) what we have. Our "restricted harness" setting allows RLMs to perform operations on the context variable, make sub-LLM calls, etc., but disallows directly coding a solution.

@amolk @sumeetrm I like this suggestion. A potential issue: an LLM can code up a domain-specific symbolic algorithm using only general purpose tools in a REPL. For example, I applied an RLM to a LongCoT chess problem, and it coded then ran a chessboard simulator. x.com/i/status/20452…

Brian Bartoldson @bartoldson

3 months ago

To illustrate setting (1): when I ran DSPy RLMs on a chess problem from LongCoT-mini, I noticed the sub-LLM tool (`llm_query`) wasn't called -- Python ended up doing the search directly as follows. ``` board = ChessBoard() for i, move in enumerate(moves):

1 1 6 1K 1

LongCoT is adding two new leaderboards! Due to the interest in agents (particularly RLMs), we’re adding a “Restricted Harness” and an “Open Harness” leaderboard. GPT 5.2 RLM from our paper is SOTA on “Open Harness” at 25.12%. We expect tool-use SOTA to exceed this very soon! On “Open Harness”, we allow all tool-use and code execution. On “Restricted Harness”, models may manage context, call subagents, etc, but may not write specific solver code (e.g. writing a BlocksWorld or Sudoku solver). We’re particularly excited about this leaderboard, as it allows agents to do their own context management, while sticking to LongCoT’s goal of testing models’ intrinsic reasoning capabilities.

Sumeet Motwani @sumeetrm

3 months ago

We’re releasing LongCoT, an incredibly hard benchmark to measure long-horizon reasoning capabilities over tens to hundreds of thousands of tokens. LongCoT consists of 2.5K questions across chemistry, math, chess, logic, and computer science. Frontier models score less than 10%🧵

19 70 403 142K 271

@raw_works Important context x.com/bartoldson/sta…

Brian Bartoldson @bartoldson

3 months ago

The attention on LongCoT is great! It's far from solved (GPT 5.2 w/out tools gets 9.8%). Out-of-the-box, a GPT 5.2 RLM gets 25% (see Figure 7). Better prompting/training should push RLMs past this. Comparing RLMs to no-tool baselines? See our 🧵of tips x.com/sumeetrm/statu…

2 7 51 13K 38

Finally, we note that LongCoT has two splits: LongCoT-mini (for fast open source research) and LongCoT (for frontier models). While some problems are naturally solvable by symbolic programs (e.g. some chess problems) and require many CoT reasoning steps, others are great tests for decomposition and maintaining important variables across steps (like mathematics and chemistry, which have composed, interdependent sub-problems). We suspect RLMs may be highly effective for all problem types.

So, if you want to compare RLMs to no-tools baselines, we suggest ensuring that RLMs are performing this sort of reasoning assistance, rather than just writing a Python code (to symbolically solve some problems) that makes it unnecessary for LLMs to reason through the steps of a problem. Concrete tips: - Look at performance across domains. If chess performance is 80% and chemistry performance is near 0%, the RLM might be writing Python code to simulate chess moves rather than reasoning through the game states as a no-tools baseline does. Such simulations may be harder to code for LongCoT chemistry and mathematics questions. - Given an LLM, when you see its RLM version boost performance, check the code executed by the RLM. Was the RLM decomposing the problem into simpler ones then providing these to the sub-LLM (this is okay!), or did it write code or import a library that solves the problem directly (LLMs w/out tools can’t do this so it won’t be a fair comparison)?

However, beyond just writing code, RLMs can decompose hard problems into simpler ones, and have the LLM perform intermediate reasoning steps. And this behavior is aligned with what we set out to test with LongCoT. Indeed, in the LongCoT paper, we show a second setting where we verbally ask an RLM (by modifying its system prompt) to avoid solving the problem primarily symbolically, saying it must instead only use code for problem decomposition. As Figure 7 shows, this restriction led to a drop from the 25.1% performance observed with a default RLM. There are likely better strategies than our prompt approach for keeping RLMs comparable to no-tools baselines, and we welcome innovation from the community here.

Accordingly, tomorrow, we will begin tracking tool-enabled performance on a separate leaderboard at longcot.ai. Note that we expect this to be saturated much faster than the base leaderboard that doesn’t allow tools.

The attention on LongCoT is great! It's far from solved (GPT 5.2 w/out tools gets 9.8%). Out-of-the-box, a GPT 5.2 RLM gets 25% (see Figure 7). Better prompting/training should push RLMs past this. Comparing RLMs to no-tool baselines? See our 🧵of tips x.com/sumeetrm/statu…

Sumeet Motwani @sumeetrm

3 months ago

We’re releasing LongCoT, an incredibly hard benchmark to measure long-horizon reasoning capabilities over tens to hundreds of thousands of tokens. LongCoT consists of 2.5K questions across chemistry, math, chess, logic, and computer science. Frontier models score less than 10%🧵

19 70 403 142K 271

RLMs can aid this LLM-based simulation (very well in theory), but (due to REPL access) they can also just write Python code that solves certain problems symbolically (without any LLM ever seeing intermediate reasoning steps). x.com/bartoldson/sta…

Brian Bartoldson @bartoldson

3 months ago

To illustrate setting (1): when I ran DSPy RLMs on a chess problem from LongCoT-mini, I noticed the sub-LLM tool (`llm_query`) wasn't called -- Python ended up doing the search directly as follows. ``` board = ChessBoard() for i, move in enumerate(moves):

1 1 6 1K 1

First, some background: The LongCoT paper outlines that, in our primary evaluations, tool use is not allowed. Our main goal is to test whether models can reason through complex problems directly in their chain of thought. If a problem requires simulating the evolution of a chessboard state (e.g.), the LLM must do that in its CoT.

@GabLesperance @dosco We want to avoid a particular kind of offloading. LongCoT evaluates models w/out Python use, but RLMs require Python. For a fair comparison, we prompt the RLM to not just code a solution. Otherwise, RLMs "offload" reasoning to code. E.g., see below x.com/bartoldson/sta…

Brian Bartoldson @bartoldson

3 months ago

To illustrate setting (1): when I ran DSPy RLMs on a chess problem from LongCoT-mini, I noticed the sub-LLM tool (`llm_query`) wasn't called -- Python ended up doing the search directly as follows. ``` board = ChessBoard() for i, move in enumerate(moves):

1 1 6 1K 1

Exactly -- we evaluated untrained RLMs on LongCoT and think training to decompose tasks would boost performance. Two eval settings to consider: (1) Python may be used to avoid reasoning (dotted bars) (2) LLM/RLM does all the reasoning (solid bars) x.com/a1zhang/status…

alex zhang @a1zhang

3 months ago

3 11 162 31K 73

@ccui9 @raw_works I'm also interested in seeing the successful traces. Here's a summary of a trace for a chess problem: x.com/i/status/20452…

Brian Bartoldson @bartoldson

3 months ago

To illustrate setting (1): when I ran DSPy RLMs on a chess problem from LongCoT-mini, I noticed the sub-LLM tool (`llm_query`) wasn't called -- Python ended up doing the search directly as follows. ``` board = ChessBoard() for i, move in enumerate(moves):

1 1 6 1K 1