Looped Language Models Improve Compositional Tool Calling

# Looped Language Models Improve Compositional Tool Calling
Source: [https://arxiv.org/html/2608.18171](https://arxiv.org/html/2608.18171)
Andrei Cristian PopescuHaitz Sáez de Ocáriz BordePietro Liòacp96@cam\.ac\.ukhs788@cam\.ac\.ukpl219@cam\.ac\.uk Department of Computer Science and Technology University of Cambridge, United Kingdom

###### Abstract

Looped language models have shown promising results on reasoning benchmarks, yet their potential for agentic tool use remains largely unexplored\. We study this question in compositional tool\-calling settings, where models must coordinate multiple API calls, maintain intermediate state, and preserve dependencies across tool interactions\. We evaluate native and retrofitted looped language models on API\-Bank, BFCL, and NESTful, comparing looped and non\-looped models trained under matched supervised fine\-tuning recipes and varying recurrent depth at inference time\. In controlled experiments, recurrent computation generally benefits compositional and dependency\-aware tool use, while providing smaller and more model\-dependent gains on isolated API invocation\. Accuracy on multi\-step tool use generally increases with recurrent depth; adaptive inference, however, achieves a more favorable compute\-performance trade\-off by allocating additional computation only when needed\. Our results suggest that looped language models are a promising architecture for agentic systems that require reliable planning, coordination, and execution of compositional tool use workflows\.

\(a\) Native looped and baseline models\.

\(b\) Retrofitted and native backbones\.

Figure 1:Looped computation primarily improves compositional tool use\.\(a\)Under matched supervised fine\-tuning conditions, Ouro models show their largest relative advantages on multi\-call BFCL categories, while differences on the predominantly single\-call API\-Bank benchmark are less consistent\.\(b\)Retrofitting recurrence into Llama\-3\.2\-1B and OLMo\-2\-1B likewise improves several compositional categories relative to their non\-recurrent counterparts\. Category labels are color\-coded: compositional tasks are shown inorange, while non\-compositional tasks are shown in black\.
## 1Introduction

Pretrained language models are increasingly used as decision\-making components in agentic systems, selecting and invoking external tools to complete user\-directed tasks\([12](https://arxiv.org/html/2608.18171#bib.bib20);[28](https://arxiv.org/html/2608.18171#bib.bib18);[24](https://arxiv.org/html/2608.18171#bib.bib19);[25](https://arxiv.org/html/2608.18171#bib.bib21)\)\. Tool use provides a controlled setting for studying how pretrained representations are translated into actions: while simple requests may require only a single function call, more complex tasks require models to compose multiple calls, maintain intermediate state, and coordinate sequential or parallel dependencies\. Reliable tool use therefore requires more than producing an individually plausible invocation; models must construct and preserve structured action sequences across multiple decisions\.

Looped language models provide a natural mechanism for strengthening this form of structured decision making\. Instead of relying on a single forward pass, they repeatedly refine latent representations before generating each token, increasing test\-time computation without increasing parameter count\. Although this iterative computation has shown promising results on reasoning benchmarks, its benefits for agentic behavior remain underexplored\.

Our main contributions are:

1. 1\.We assess whether iterative latent computation improves compositional tool use in a controlled setting requiring structured, multi\-step decision making\.
2. 2\.Our evaluation covers native and retrofitted looped models on API\-Bank, BFCL, and NESTful, with matched fine\-tuning comparisons and shared\-backbone Llama and OLMo retrofits\.
3. 3\.The largest benefits appear on multi\-call and dependency\-aware tasks, suggesting that recurrent computation is particularly useful when action selection must preserve structure across multiple decisions\.
4. 4\.Increasing recurrent depth generally improves compositional tool use, while adaptive inference achieves a better compute\-performance trade\-off by allocating fewer iterations when additional refinement is unnecessary\.

## 2Related Work

We review two lines of work most closely related to our study: recurrent\-depth architectures for latent computation, and methods for planning and composition in tool\-using language models\.

#### Recurrent Depth and Latent Computation

Looped Transformers increase effective model depth by repeatedly applying a shared Transformer block, decoupling test\-time computation from parameter count\. Early recurrent and parameter\-sharing architectures include the Universal Transformer\([5](https://arxiv.org/html/2608.18171#bib.bib2)\), Deep Equilibrium Models\([2](https://arxiv.org/html/2608.18171#bib.bib6)\), and ALBERT\([15](https://arxiv.org/html/2608.18171#bib.bib5)\)\. More recent work introduced looped Transformers as a method for latent reasoning, where recurrent iterations refine hidden representations rather than extending the context with explicit reasoning tokens\([23](https://arxiv.org/html/2608.18171#bib.bib8);[6](https://arxiv.org/html/2608.18171#bib.bib4);[30](https://arxiv.org/html/2608.18171#bib.bib3);[11](https://arxiv.org/html/2608.18171#bib.bib9);[8](https://arxiv.org/html/2608.18171#bib.bib10);[29](https://arxiv.org/html/2608.18171#bib.bib11);[9](https://arxiv.org/html/2608.18171#bib.bib12)\)\. Looped models have demonstrated strong performance on algorithmic reasoning, length generalization, adaptive computation, and latent test\-time scaling\([7](https://arxiv.org/html/2608.18171#bib.bib7);[1](https://arxiv.org/html/2608.18171#bib.bib13);[27](https://arxiv.org/html/2608.18171#bib.bib14);[14](https://arxiv.org/html/2608.18171#bib.bib15);[21](https://arxiv.org/html/2608.18171#bib.bib16)\)\. We test whether these capabilities transfer to tool\-use settings\.

#### Planning and Composition in Tool\-Using Models

Tool\-augmented language models extend autoregressive generation by invoking external functions for retrieval, computation, and interaction with software environments\. Early work demonstrated that language models can interleave reasoning with tool execution\([28](https://arxiv.org/html/2608.18171#bib.bib18)\), learn API usage from self\-supervised annotations\([24](https://arxiv.org/html/2608.18171#bib.bib19)\), or route requests to specialized neural and symbolic modules\([12](https://arxiv.org/html/2608.18171#bib.bib20)\)\. More recent approaches improve compositional tool use through explicit planning, including decomposing tasks into executable workflows\([25](https://arxiv.org/html/2608.18171#bib.bib21);[17](https://arxiv.org/html/2608.18171#bib.bib22)\), retrieving relevant APIs from large tool collections\([22](https://arxiv.org/html/2608.18171#bib.bib23);[20](https://arxiv.org/html/2608.18171#bib.bib24)\), and constructing dependency\-aware execution graphs that schedule sequential and parallel function calls\([13](https://arxiv.org/html/2608.18171#bib.bib25)\)\. Unlike these approaches, which primarily enhance tool use through external planning, retrieval, or execution strategies, our work investigates whether additional latent iterative computation in looped Transformers benefits compositional tool calling\. Benchmarks such as API\-Bank\([16](https://arxiv.org/html/2608.18171#bib.bib26)\), BFCL\([19](https://arxiv.org/html/2608.18171#bib.bib27)\), and NESTful\([4](https://arxiv.org/html/2608.18171#bib.bib28)\)are used to evaluate increasingly complex tool\-use capabilities, ranging from single\-function invocation to parallel, sequential, and nested API compositions\.

## 3Background

We first introduce the recurrent computation used by looped Transformers, and then formalize compositional tool calling as structured prediction over sets of tool invocations and their dependencies\.

#### Looped Transformers

In contrast to classical Transformers that stack distinct Transformer layers, looped Transformers repeatedly apply a shared block of Transformer layers over multiple recurrent iterations\. Each iteration refines the latent representation, increasing inference\-time computation while keeping the parameter count fixed\. Leth\(0\)h^\{\(0\)\}denote the initial hidden representation of an input sequence\. At recurrent iterationtt, the shared Transformer block updates the latent state according toh\(t\)=Fθ​\(h\(t−1\)\),h^\{\(t\)\}=F\_\{\\theta\}\\\!\\left\(h^\{\(t\-1\)\}\\right\),whereFθF\_\{\\theta\}denotes the shared recurrent block\. A shared output head then produces a prediction after every recurrent iteration,πθ\(t\)​\(y∣x\)=gθ​\(h\(t\)\),\\pi\_\{\\theta\}^\{\(t\)\}\(y\\mid x\)=g\_\{\\theta\}\\\!\\left\(h^\{\(t\)\}\\right\),producing a sequence of refined predictions\{πθ\(1\),…,πθ\(T\)\}\\\{\\pi\_\{\\theta\}^\{\(1\)\},\\ldots,\\pi\_\{\\theta\}^\{\(T\)\}\\\}, whereTTis the maximum number of recurrent iterations\. Looped Transformers naturally enable adaptive computation\. Rather than executing a fixed number of recurrent iterations for every token, looped Transformers can dynamically allocate computation by selecting an exit iteration using either a learned halting policy or post\-hoc criteria\([3](https://arxiv.org/html/2608.18171#bib.bib1);[30](https://arxiv.org/html/2608.18171#bib.bib3);[21](https://arxiv.org/html/2608.18171#bib.bib16)\)\. During inference, easier predictions can terminate after fewer recurrent iterations, improving the cost–accuracy trade\-off\.

#### Compositional Tool Use Formalism

Let𝒯=\{τ1,…,τN\}\\mathcal\{T\}=\\\{\\tau\_\{1\},\\ldots,\\tau\_\{N\}\\\}denote the tools available to a language model, where each toolτi\\tau\_\{i\}is specified by a function name, a natural\-language description, and an argument schema\. Given a user requestxx, the language model predicts a distribution over structured tool callspθ​\(ck∣x\),p\_\{\\theta\}\(c\_\{k\}\\mid x\),whereck=\(fk,ak\),c\_\{k\}=\(f\_\{k\},a\_\{k\}\),fk∈𝒯f\_\{k\}\\in\\mathcal\{T\}is the selected function andaka\_\{k\}denotes its instantiated arguments\. Executingckc\_\{k\}returns an observationoko\_\{k\}, which may be incorporated into subsequent model predictions\. A tool use solution can be represented as a directed acyclic graphGx=\(Cx,Ex\),G\_\{x\}=\(C\_\{x\},E\_\{x\}\),whereCx=\{c1,…,cK\}C\_\{x\}=\\\{c\_\{1\},\\ldots,c\_\{K\}\\\}is the set of tool calls and\(ci,cj\)∈Ex\(c\_\{i\},c\_\{j\}\)\\in E\_\{x\}indicates that callcjc\_\{j\}depends on the result of callcic\_\{i\}\. A single\-call task has\|Cx\|=1\|C\_\{x\}\|=1\. Independent calls have no dependencies and may be executed in parallel, whereas sequential calls are constrained by an ordering\. In a dependent or nested sequence, the observation returned by an earlier call is used to instantiate an argument of a later call, such thataj=ϕj​\(x,oi1,…,oim\),a\_\{j\}=\\phi\_\{j\}\(x,o\_\{i\_\{1\}\},\\ldots,o\_\{i\_\{m\}\}\),for predecessor calls\{ci1,…,cim\}\\\{c\_\{i\_\{1\}\},\\ldots,c\_\{i\_\{m\}\}\\\}\. More complex workflows may combine parallel branches with sequential dependencies\. We refer to the construction of multi\-call solutions as compositional tool calling\. Under this representation, independent calls haveEx=∅E\_\{x\}=\\varnothingand dependent workflows haveEx≠∅E\_\{x\}\\neq\\varnothing\. Thus,CxC\_\{x\}specifies the required tool calls, whileExE\_\{x\}specifies the output\-to\-input dependencies between them\. Using this formulation, existing benchmarks emphasize different components of the tool\-calling process\. API\-Bank primarily evaluates individual tool callsck=\(fk,ak\)c\_\{k\}=\(f\_\{k\},a\_\{k\}\), focusing on correct tool selection, argument grounding, and API invocation\. BFCL evaluates both single\-call function selection and independent multi\-call generation\. Its Simple and Multiple categories require\|Cx\|=1\|C\_\{x\}\|=1, whereas its Parallel and Parallel\-Multiple categories require\|Cx\|\>1\|C\_\{x\}\|\>1, withEx=∅E\_\{x\}=\\varnothingthroughout\. Finally, NESTful emphasizes the dependency structureExE\_\{x\}, where outputs returned by earlier calls are consumed as arguments of later calls, forming hierarchical execution chains\. These benchmarks evaluate node\-level call prediction, structured multi\-call composition, and dependency\-aware execution\.

## 4Experimental Setup

This section describes the models, training procedure, evaluation benchmarks, and inference protocols used in our experiments\. We compare looped and non\-looped models under matched supervised fine\-tuning recipes, and evaluate both fixed\-depth and adaptive looped inference to study the role of further computation during tool use\.

### 4\.1Model Families and Variants

We evaluate looped language models in two complementary settings\. First, we compare the looped Ouro\-1\.4B and Ouro\-2\.6B models against standard Transformer baselines from the Qwen3 and Llama families at similar parameter scales\. We fine\-tune the corresponding base checkpoints using the same dataset and optimization settings, and separately evaluate released instruction\-tuned Qwen and Llama checkpoints up to 8B parameters as stronger public reference systems\. The larger instruction\-tuned checkpoints also provide reference points whose single\-pass inference cost is closer to that of multiple loop iterations\. Second, we evaluate retrofitted looped models based on OLMo\-2\-1B and Llama\-3\.2\-1B\. For each model, we compare the looped checkpoint against its corresponding non\-looped parent after supervised fine\-tuning with the same data and optimization recipe\. These comparisons more directly isolate the effect of introducing looped computation while preserving the underlying pretraining family\. Architectural details for Ouro and the retrofitted models are provided in Appendix[A](https://arxiv.org/html/2608.18171#A1)\.

#### Supervised Fine\-Tuning

All controlled models are supervised fine\-tuned on the Hermes function calling dataset\. Training examples are formatted using ChatML with the Hermes JSON tool\-calling protocol\. More details about the dataset can be found in Appendix[B](https://arxiv.org/html/2608.18171#A2)\. All experiments use a maximum sequence length of 4,096 tokens, a 90/10 train\-validation split, two training epochs, AdamW with learning rate2×10−52\\times 10^\{\-5\}, cosine learning\-rate decay with 3% warmup, gradient accumulation of 2, per\-device batch size of 2, LoRA rank 32, and bf16 precision\. The experiments were run on an NVIDIA A100 80GB GPU\. The Ouro models are fine\-tuned using the original training objective,

ℒ\(θ,ϕ\)=∑t=1Tpϕ\(t∣x\)ℒθ\(t\)\(x\)\+βKL\(pϕ\(⋅∣x\)∥π\(⋅\)\),\\mathcal\{L\}\(\\theta,\\phi\)=\\sum\_\{t=1\}^\{T\}p\_\{\\phi\}\(t\\mid x\)\\,\\mathcal\{L\}\_\{\\theta\}^\{\(t\)\}\(x\)\+\\beta\\,\\mathrm\{KL\}\\\!\\left\(p\_\{\\phi\}\(\\cdot\\mid x\)\\,\\\|\\,\\pi\(\\cdot\)\\right\),whereβ=0\.1\\beta=0\.1,ℒθ\(t\)\\mathcal\{L\}\_\{\\theta\}^\{\(t\)\}denotes the next\-token cross\-entropy at loop iterationtt,pϕ​\(t∣x\)p\_\{\\phi\}\(t\\mid x\)is the learned distribution over loop iterations, andπ\\piis the uniform prior over loop depths\. The retrofitted looped models do not learn an exit distribution\. Instead, the number of loopsrris sampled independently for each training batch using the Poisson\-lognormal depth distribution proposed in the original paper[18](https://arxiv.org/html/2608.18171#bib.bib17)\. The model is supervised at the final readout after the sampled number of iterations:

ℒ\(θ\)=𝔼x𝔼r∼𝒟PLN\[∑ℓ=1M−1\(−logpθ\(r\)\(xℓ\+1∣x1:ℓ\)\+βKL\(pθ0\(⋅∣x1:ℓ\)∥pθ\(r\)\(⋅∣x1:ℓ\)\)\)\]\.\\mathcal\{L\}\(\\theta\)=\\mathbb\{E\}\_\{x\}\\mathbb\{E\}\_\{r\\sim\\mathcal\{D\}\_\{\\mathrm\{PLN\}\}\}\\Bigg\[\\sum\_\{\\ell=1\}^\{M\-1\}\\Bigg\(\-\\log p\_\{\\theta\}^\{\(r\)\}\\\!\\left\(x\_\{\\ell\+1\}\\mid x\_\{1:\\ell\}\\right\)\+\\beta\\,\\mathrm\{KL\}\\\!\\left\(p\_\{\\theta\_\{0\}\}\(\\cdot\\mid x\_\{1:\\ell\}\)\\,\\middle\\\|\\,p\_\{\\theta\}^\{\(r\)\}\(\\cdot\\mid x\_\{1:\\ell\}\)\\right\)\\Bigg\)\\Bigg\]\.Here,β=0\.1\\beta=0\.1,pθ\(r\)p\_\{\\theta\}^\{\(r\)\}is the next\-token distribution of the adapted model afterrrloop iterations andpθ0p\_\{\\theta\_\{0\}\}is the corresponding distribution of the frozen pre\-adaptation model\. Unlike Ouro, which learns a per\-token distribution over loop iterations, the retrofitted model is trained using randomly sampled recurrence depths and always computes the supervised loss from the final recurrent readout\.

### 4\.2Evaluation Benchmarks

We evaluate tool use performance using three benchmarks covering different aspects of function calling: BFCL v3, NESTful, and API\-Bank\. These benchmarks aim to assess isolated API invocation, compositional multi\-tool reasoning, and hierarchical tool execution\. Additional details and representative examples for all three benchmarks are provided in Appendix[D](https://arxiv.org/html/2608.18171#A4)\.

#### BFCL v3\.

BFCL v3\([19](https://arxiv.org/html/2608.18171#bib.bib27)\)is our primary evaluation benchmark\. We evaluate using the official BFCL v3 single\-turn protocol and report AST accuracy on the non\-live benchmark split\. Following the benchmark protocol, we report results separately for the Simple, Multiple, Parallel, and Parallel\-Multiple categories\. Simple tasks require one tool call\. Multiple tasks also require a single call, but the model must select the correct function from several candidate tool definitions\. Parallel tasks require multiple independent invocations of a single function\. Parallel\-Multiple tasks combine function selection with multiple independent invocations across several candidate functions\. Thus, in BFCL, Multiple refers to the number of candidate tools rather than the number of generated calls\. Only the Parallel and Parallel\-Multiple categories require multiple calls\. The evaluator standardizes tool calls before comparison, making the evaluation robust to formatting differences while requiring semantic equivalence of the predicted calls\. We report the official AST accuracy, which scores a prediction as correct if its standardized abstract syntax tree matches the reference tool call\. Representative examples for each category are provided in Appendix[D\.1](https://arxiv.org/html/2608.18171#A4.SS1)\.

#### NESTful\.

NESTful\([4](https://arxiv.org/html/2608.18171#bib.bib28)\)evaluates hierarchical tool use through nested API workflows, where later calls depend on outputs produced by earlier ones\. Unlike BFCL, the benchmark emphasizes long\-range dependencies and multi\-step execution rather than isolated function prediction\. Following the benchmark protocol, we report Win Rate as the primary execution\-based metric, together with function, parameter, partial\-sequence, and full\-sequence scores\. A representative nested execution example is provided in Appendix[D\.2](https://arxiv.org/html/2608.18171#A4.SS2)\.

#### API\-Bank\.

API\-Bank\([16](https://arxiv.org/html/2608.18171#bib.bib26)\)evaluates tool use across a diverse collection of real\-world APIs spanning multiple domains\. In contrast to BFCL and NESTful, most tasks involve a single API invocation, putting more emphasis on selecting the appropriate API and generating correct arguments than on coordinating multiple interacting tool calls\. Hence, it complements the compositional reasoning benchmarks by measuring API grounding and invocation accuracy\. We report three complementary metrics\. Call Correctness applies the released API\-specific functional checks, Exact requires an exact match of the API name and complete argument dictionary after parsing and conservative normalization, and Parse is the fraction of outputs that can be parsed as valid API calls\. A representative API\-Bank instance is provided in Appendix[D\.3](https://arxiv.org/html/2608.18171#A4.SS3)\.

### 4\.3Analyzing the Effect of Iterative Computation

We evaluate the effect of successive recurrent iterations using both fixed\-depth and adaptive inference protocols\. These experiments are performed on the BFCL v3 evaluation split described above and a 500\-example subset of NESTful\. The NESTful subset is selected by taking examples evenly across the benchmark’s official ordering before any experiments are run, and is held constant across all models and inference settings\.

#### Fixed\-Depth Inference\.

To evaluate the effect of additional looped computation, we perform fixed\-depth inference by executing a predetermined number of loop iterations for every generated token\. For the Ouro models, we evaluate depths 1 to 4, corresponding to the model’s maximum recurrent depth\. For the retrofitted recurrent Llama\-3\.2\-1B and OLMo\-2\-1B models, we evaluate 1, 2, 4, and 8 loop iterations\. Modifying only the inference depth while keeping model parameters fixed isolates the contribution of recurrence independently of training\.

#### Adaptive Inference\.

In addition to fixed\-depth inference, we evaluate adaptive looped computation using Ouro’s pretrained exit gate\. During generation, each token exits the inference loop once the cumulative exit probability exceeds a confidence thresholdqq\. We evaluate thresholdsq∈\{0\.1,0\.3,0\.5,0\.7,0\.8\}q\\in\\\{0\.1,0\.3,0\.5,0\.7,0\.8\\\}and report both task performance and the average selected loop depth, computed as the mean number of loop iterations used across all generated tokens\.

## 5Results

In this section, we start by evaluating whether looped models improve tool use over non\-looped baselines\. We then investigate whether these improvements arise from iterative computation itself through controlled inference\-time depth ablations and whether recurrent computation can be allocated adaptively to improve the compute–performance trade\-off\.

Table 1:BFCL semantic AST correctness \(%; higher is better\)\. Overall is the aggregate score across all task categories\. The lower block compares looped and non\-looped variants of each backbone, fine\-tuned using identical data and optimization settings; looped variants use a fixed inference depth of 8 loop iterations\. Base checkpoints omitted from the lower block score near zero throughout\.#### Looped language models improve tool use\.

Tables[1](https://arxiv.org/html/2608.18171#S5.T1),[2](https://arxiv.org/html/2608.18171#S5.T2), and[3](https://arxiv.org/html/2608.18171#S5.T3)report results on BFCL, NESTful, and API\-Bank\. The controlled comparisons use identical datasets, optimization schedules, and LoRA configurations for looped and non\-looped models\. We evaluate both native Ouro models against similarly sized Transformer baselines and retrofitted recurrent variants of Llama\-3\.2\-1B and OLMo\-2\-1B against their non\-recurrent parents\. Publicly released instruction\-tuned Qwen and Llama checkpoints are included as reference systems\.

Table 2:NESTful official evaluation \(higher is better\)\. Win Rate is the primary metric\.Table 3:API\-Bank evaluation\(%; higher is better\)\.\(a\)Controlled comparison between looped and non\-looped models trained using identical supervised fine\-tuning recipes\. The lower block pairs each retrofitted backbone with its non\-looped counterpart; looped variants are evaluated at a fixed inference depth of 8 loop iterations\.\(b\)Comparison against publicly released instruction\-tuned checkpoints\. Call Correctness measures functional API\-call correctness, Exact requires an exact API\-name\-and\-argument match, and Parse reports valid call generation\.\(a\) Controlled modelsBaseSFTModelCallExactParseCallExactParseOuro\-1\.4B73\.067\.695\.175\.170\.297\.2Ouro\-2\.6B79\.276\.999\.279\.977\.199\.7Qwen3\-1\.7B5\.15\.113\.961\.457\.893\.6Qwen3\-4B71\.271\.299\.276\.673\.899\.7Llama\-3\.2\-1B1\.71\.310\.816\.314\.155\.3Llama\-3\.2\-3B0\.30\.30\.368\.564\.599\.7OLMo\-2\-1B1\.90\.535\.737\.133\.299\.5OLMo\-2\-1B \(Loop\)0\.10\.01\.534\.030\.390\.7Llama\-3\.2\-1B1\.71\.310\.816\.314\.155\.3Llama\-3\.2\-1B \(Loop\)0\.10\.01\.517\.916\.243\.4
\(b\) Released instruct checkpointsModelCallExactParseOuro\-1\.4B \(SFT\)75\.170\.297\.2Ouro\-2\.6B \(SFT\)79\.977\.199\.7Qwen3\-1\.7B79\.474\.0100\.0Qwen3\-4B78\.775\.3100\.0Qwen3\-8B79\.976\.6100\.0Llama\-3\.2\-1B5\.15\.113\.9Llama\-3\.2\-3B74\.670\.798\.5Llama\-3\.1\-8B78\.874\.8100\.0

In both experimental settings, looped models perform better on compositional tool\-calling tasks, whereas gains on isolated API invocation are smaller and model\-dependent\. On BFCL, the smallest differences occur on Simple tasks, where both looped and non\-looped SFT models already perform strongly\. Larger gains appear on the compositional categories, particularly Parallel and Parallel\-Multiple\. NESTful shows a similar pattern, where the Ouro models improve on the full evaluation, while the fixed\-depth subset indicates that additional recurrence can also benefit the retrofitted models on hierarchical workflows\. API\-Bank shows much smaller differences, consistent with its greater emphasis on individual API selection and argument generation\. Despite their relatively small parameter counts, the Ouro models remain competitive with several released Qwen and Llama instruction checkpoints\.

#### Tool\-use performance increases with recurrent depth\.

The results in the previous section demonstrate that looped language models outperform their non\-looped counterparts, but they do not distinguish improvements arising from the loops themselves from those due to training\. To isolate the contribution of looped computation, we vary the number of inference loop iterations while keeping the model fixed\. Figure[2](https://arxiv.org/html/2608.18171#S5.F2)shows that BFCL accuracy generally rises with recurrent depth, with the largest gains on compositional categories\. For Ouro\-1\.4B and the retrofitted Llama model, Simple tasks saturate earlier, whereas the tool\-selection\-heavy Multiple category and the multi\-call Parallel and Parallel\-Multiple categories continue to benefit from further computation before plateauing\. OLMo\-2\-1B shows a similar pattern on multi\-call tasks\. Ouro\-2\.6B instead reaches near\-saturation after three iterations in all categories, suggesting that the larger model requires fewer refinement steps\.

Figure 2:BFCL semantic AST accuracy by task category as fixed recurrent depth increases\. Each curve reports accuracy on Simple, Multiple, Parallel, and Parallel\-Multiple tasks\.\(a\)Native recurrent Ouro models\.\(b\)Retrofitted recurrent Llama model\.
Figure 3:NESTful Win Rate as fixed recurrent depth increases\. Native recurrent Ouro models benefit from additional recurrent computation, whereas the retrofitted recurrent Llama baseline remains substantially weaker\.NESTful exhibits the same depth effect: Win Rate increases as the number of recurrent iterations grows \(Figure[3](https://arxiv.org/html/2608.18171#S5.F3)\)\. Since later function calls explicitly depend on outputs from previous calls, the improvement with depth indicates that recurrence benefits dependent tool interactions\. Across both Ouro models and the retrofitted Llama model, the effect persists when only inference depth is varied, separating it from differences introduced during training\.

\(a\)Ouro\-1\.4B\.\(b\)Ouro\-2\.6B\.
Figure 4:Adaptive recurrent computation on BFCL and NESTful\. The x\-axis reports the mean recurrent depth per generated token\. Adaptive stopping improves the compute\-performance frontier by allocating additional recurrent iterations only when beneficial\. On BFCL, adaptive stopping matches or slightly exceeds the best fixed\-depth operating point while executing fewer recurrent iterations on average\. On NESTful, Ouro\-2\.6B reaches the same Win Rate as fixed depth 4 while using fewer recurrent iterations per generated token\.
#### Adaptive looped computation increases tool\-calling efficiency\.

The previous subsection shows that additional inference loop iterations improve tool use performance but eventually saturate, with the saturation point varying across models and tasks\. This suggests that a fixed inference depth is suboptimal\. A key advantage of looped language models is that they naturally support adaptive computation, allowing the model to dynamically determine how much iterative refinement each prediction requires\. Next, we evaluate adaptive looped computation, where the model exits the inference loop on a per\-token basis using the Ouro adaptive exit gate\.

Figure[4](https://arxiv.org/html/2608.18171#S5.F4)compares adaptive and fixed\-depth inference on BFCL and NESTful\. Adaptive inference yields a better performance–compute trade\-off for both Ouro models\. It recovers most of the gains from deeper recurrence while using fewer loop iterations per generated token, and in several settings matches or exceeds the best fixed\-depth configuration at lower average cost\. Allocating recurrent computation by token difficulty thus yields a better compute–performance trade\-off than applying a uniform depth\.

#### Iterative computation refines tool invocations\.

Figure[5](https://arxiv.org/html/2608.18171#S5.F5)shows a representative NESTful example\. At shallow recurrent depths, the model omits the dependent call or produces invalid function and variable references\. By depth 3, it recovers the complete tool sequence and the correct output\-to\-input dependency, after which the prediction remains unchanged\. This example suggests that recurrence can correct semantic errors in call structure and dependency binding, rather than merely output formatting\. Additional examples appear in Appendix[C](https://arxiv.org/html/2608.18171#A3)\.

![Refer to caption](https://arxiv.org/html/2608.18171v1/images/qualitative_example.png)Figure 5:Iterative refinement across recurrent depths\.Ouro\-1\.4B on a two\-step NESTful composition task\. Calls are shown asfunction\(argument=value\) \-\> answer\. At depth 1 the model emits a single call to a function absent from the tool catalogue and omits the dependent call; at depth 2 it recovers the two\-call structure but the first function is again absent from the catalogue and the variable reference is invalid\. Depths 3 and 4 match the gold sequence, including the output\-to\-input reference$var1\.output\_0$\.

## 6Conclusion

Our empirical evaluation shows that looped computation is particularly beneficial when tool calling requires composition, dependency tracking, or coordination across multiple calls\. On BFCL and NESTful, native Ouro models and retrofitted Llama and OLMo models generally outperform comparable non\-looped baselines on structured tool use tasks\. Notably, although post\-hoc recurrence improves several compositional tasks, retrofitted models remain substantially weaker than natively recurrent models on deeply nested workflows, suggesting that the effectiveness of recurrent refinement may depend on how representations are shaped during pretraining\. By contrast, gains are smaller and more model\-dependent on API\-Bank, where most examples involve isolated API invocation\. Fixed\-depth experiments further show that multi\-step tool use performance generally increases with recurrent depth, and qualitative analysis indicates that successive iterations can incrementally refine function selection, call structure, and intermediate dependencies\. Adaptive stopping recovers most of the gains from deeper recurrent inference using fewer loop iterations on average, yielding a better compute\-performance trade\-off\. The results presented in this paper suggest that looped language models are a promising foundation for agentic systems that must dynamically allocate computation while planning, coordinating, and executing compositional tool use workflows\.

## 7Limitations

Our conclusions are drawn from a deliberately controlled setting\. For the Ouro models in particular, no non\-looped counterpart trained under identical pretraining conditions is publicly available, so we approximate a matched comparison by evaluating against both the Qwen3 and Llama families under the same fine\-tuning recipe\. The retrofit experiments, which share a backbone with their non\-recurrent parents, isolate the architectural change more directly\. Because additional recurrent iterations increase per\-token compute, we also include larger instruction\-tuned checkpoints as reference points, with inference costs that approximately upper\-bound those of the looped models\. Finally, all three benchmarks are static, single\-turn evaluations\. Extending this analysis to live, multi\-turn settings such as the BFCL live and multi\-turn categories, where the model must recover from failed executions across an episode, is left to future work\.

## References

- C\. Anil, Y\. Wu, A\. Andreassen, A\. Lewkowycz, V\. Misra, V\. Ramasesh, A\. Slone, G\. Gur\-Ari, E\. Dyer, and B\. NeyshaburExploring length generalization in large language models\.External Links:2207\.04901,[Link](https://arxiv.org/abs/2207.04901)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Baiet al\.\(2019\)S\. Bai, J\. Z\. Kolter, and V\. KoltunDeep equilibrium models\.External Links:1909\.01377,[Link](https://arxiv.org/abs/1909.01377)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Baninoet al\.\(2021\)A\. Banino, J\. Balaguer, and C\. BlundellPonderNet: learning to ponder\.External Links:2107\.05407,[Link](https://arxiv.org/abs/2107.05407)Cited by:[§3](https://arxiv.org/html/2608.18171#S3.SS0.SSS0.Px1.p1.1)\.
- Basuet al\.\(2025\)K\. Basu, I\. Abdelaziz, K\. Kate, M\. Agarwal, M\. Crouse, Y\. Rizk, K\. Bradford, A\. Munawar, S\. Kumaravel, S\. Goyal, X\. Wang, L\. A\. Lastras, and P\. KapanipathiNESTFUL: a benchmark for evaluating llms on nested sequences of api calls\.External Links:2409\.03797,[Link](https://arxiv.org/abs/2409.03797)Cited by:[§D\.2](https://arxiv.org/html/2608.18171#A4.SS2.p1.1),[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1),[§4\.2](https://arxiv.org/html/2608.18171#S4.SS2.SSS0.Px2.p1.1)\.
- Dehghaniet al\.\(2019\)M\. Dehghani, S\. Gouws, O\. Vinyals, J\. Uszkoreit, and Ł\. KaiserUniversal transformers\.External Links:1807\.03819,[Link](https://arxiv.org/abs/1807.03819)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Geipinget al\.\(2025\)J\. Geiping, S\. McLeish, N\. Jain, J\. Kirchenbauer, S\. Singh, B\. R\. Bartoldson, B\. Kailkhura, A\. Bhatele, and T\. GoldsteinScaling up test\-time compute with latent reasoning: a recurrent depth approach\.External Links:2502\.05171,[Link](https://arxiv.org/abs/2502.05171)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Giannouet al\.\(2023\)A\. Giannou, S\. Rajput, J\. Sohn, K\. Lee, J\. D\. Lee, and D\. PapailiopoulosLooped transformers as programmable computers\.External Links:2301\.13196,[Link](https://arxiv.org/abs/2301.13196)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Haoet al\.\(2025\)S\. Hao, S\. Sukhbaatar, D\. Su, X\. Li, Z\. Hu, J\. Weston, and Y\. TianTraining large language models to reason in a continuous latent space\.External Links:2412\.06769,[Link](https://arxiv.org/abs/2412.06769)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Huanget al\.\(2025\)W\. Huang, Y\. Xiong, X\. Ye, Z\. Deng, H\. Chen, Z\. Lin, and G\. DingFast quiet\-star: thinking without thought tokens\.External Links:2505\.17746,[Link](https://arxiv.org/abs/2505.17746)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- interstellarninja and Teknium \(2026\)interstellarninja and TekniumHermes\-function\-calling\-dataset\-v1\.External Links:[Link](https://huggingface.co/NousResearch/hermes-function-calling-v1)Cited by:[Appendix B](https://arxiv.org/html/2608.18171#A2.p1.1)\.
- Jeddiet al\.\(2026\)A\. Jeddi, M\. Ciccone, and B\. TaatiLoopFormer: elastic\-depth looped transformers for latent reasoning via shortcut modulation\.External Links:2602\.11451,[Link](https://arxiv.org/abs/2602.11451)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Karpaset al\.\(2022\)E\. Karpas, O\. Abend, Y\. Belinkov, B\. Lenz, O\. Lieber, N\. Ratner, Y\. Shoham, H\. Bata, Y\. Levine, K\. Leyton\-Brown, D\. Muhlgay, N\. Rozen, E\. Schwartz, G\. Shachaf, S\. Shalev\-Shwartz, A\. Shashua, and M\. TenenholtzMRKL systems: a modular, neuro\-symbolic architecture that combines large language models, external knowledge sources and discrete reasoning\.External Links:2205\.00445,[Link](https://arxiv.org/abs/2205.00445)Cited by:[§1](https://arxiv.org/html/2608.18171#S1.p1.1),[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1)\.
- Kimet al\.\(2024\)S\. Kim, S\. Moon, R\. Tabrizi, N\. Lee, M\. W\. Mahoney, K\. Keutzer, and A\. GholamiAn llm compiler for parallel function calling\.External Links:2312\.04511,[Link](https://arxiv.org/abs/2312.04511)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1)\.
- Kohliet al\.\(2026\)H\. Kohli, S\. Parthasarathy, H\. Sun, and Y\. YaoLoop, think, & generalize: implicit reasoning in recurrent\-depth transformers\.External Links:2604\.07822,[Link](https://arxiv.org/abs/2604.07822)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Lanet al\.\(2020\)Z\. Lan, M\. Chen, S\. Goodman, K\. Gimpel, P\. Sharma, and R\. SoricutALBERT: a lite bert for self\-supervised learning of language representations\.External Links:1909\.11942,[Link](https://arxiv.org/abs/1909.11942)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Liet al\.\(2023\)M\. Li, Y\. Zhao, B\. Yu, F\. Song, H\. Li, H\. Yu, Z\. Li, F\. Huang, and Y\. LiAPI\-bank: a comprehensive benchmark for tool\-augmented llms\.External Links:2304\.08244,[Link](https://arxiv.org/abs/2304.08244)Cited by:[§D\.3](https://arxiv.org/html/2608.18171#A4.SS3.p1.1),[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1),[§4\.2](https://arxiv.org/html/2608.18171#S4.SS2.SSS0.Px3.p1.1)\.
- Luet al\.\(2023\)P\. Lu, B\. Peng, H\. Cheng, M\. Galley, K\. Chang, Y\. N\. Wu, S\. Zhu, and J\. GaoChameleon: plug\-and\-play compositional reasoning with large language models\.External Links:2304\.09842,[Link](https://arxiv.org/abs/2304.09842)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1)\.
- McLeishet al\.\(2025\)S\. McLeish, A\. Li, J\. Kirchenbauer, D\. S\. Kalra, B\. R\. Bartoldson, B\. Kailkhura, A\. Schwarzschild, J\. Geiping, T\. Goldstein, and M\. GoldblumTeaching pretrained language models to think deeper with retrofitted recurrence\.External Links:2511\.07384,[Link](https://arxiv.org/abs/2511.07384)Cited by:[§A\.2](https://arxiv.org/html/2608.18171#A1.SS2.p1.1),[§4\.1](https://arxiv.org/html/2608.18171#S4.SS1.SSS0.Px1.p1.2)\.
- Patilet al\.\(2025\)S\. G\. Patil, H\. Mao, F\. Yan, C\. C\. Ji, V\. Suresh, I\. Stoica, and J\. E\. GonzalezThe berkeley function calling leaderboard \(BFCL\): from tool use to agentic evaluation of large language models\.InProceedings of the 42nd International Conference on Machine Learning,A\. Singh, M\. Fazel, D\. Hsu, S\. Lacoste\-Julien, F\. Berkenkamp, T\. Maharaj, K\. Wagstaff, and J\. Zhu \(Eds\.\),Proceedings of Machine Learning Research, Vol\.267,pp\. 48371–48392\.External Links:[Link](https://proceedings.mlr.press/v267/patil25a.html)Cited by:[§D\.1](https://arxiv.org/html/2608.18171#A4.SS1.p1.1),[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1),[§4\.2](https://arxiv.org/html/2608.18171#S4.SS2.SSS0.Px1.p1.1)\.
- Patilet al\.\(2023\)S\. G\. Patil, T\. Zhang, X\. Wang, and J\. E\. GonzalezGorilla: large language model connected with massive apis\.External Links:2305\.15334,[Link](https://arxiv.org/abs/2305.15334)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1)\.
- Popescuet al\.\(2026\)A\. C\. Popescu, H\. S\. de Ocáriz Borde, and P\. LiòAdaptive depth in looped transformers: diagnosing learned halting gates and trajectory readouts\.External Links:2607\.20519,[Link](https://arxiv.org/abs/2607.20519)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1),[§3](https://arxiv.org/html/2608.18171#S3.SS0.SSS0.Px1.p1.1)\.
- Qinet al\.\(2023\)Y\. Qin, S\. Liang, Y\. Ye, K\. Zhu, L\. Yan, Y\. Lu, Y\. Lin, X\. Cong, X\. Tang, B\. Qian, S\. Zhao, L\. Hong, R\. Tian, R\. Xie, J\. Zhou, M\. Gerstein, D\. Li, Z\. Liu, and M\. SunToolLLM: facilitating large language models to master 16000\+ real\-world apis\.External Links:2307\.16789,[Link](https://arxiv.org/abs/2307.16789)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1)\.
- Saunshiet al\.\(2025\)N\. Saunshi, N\. Dikkala, Z\. Li, S\. Kumar, and S\. J\. ReddiReasoning with latent thoughts: on the power of looped transformers\.External Links:2502\.17416,[Link](https://arxiv.org/abs/2502.17416)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Schicket al\.\(2023\)T\. Schick, J\. Dwivedi\-Yu, R\. Dessì, R\. Raileanu, M\. Lomeli, L\. Zettlemoyer, N\. Cancedda, and T\. ScialomToolformer: language models can teach themselves to use tools\.External Links:2302\.04761,[Link](https://arxiv.org/abs/2302.04761)Cited by:[§1](https://arxiv.org/html/2608.18171#S1.p1.1),[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1)\.
- Shenet al\.\(2023\)Y\. Shen, K\. Song, X\. Tan, D\. Li, W\. Lu, and Y\. ZhuangHuggingGPT: solving ai tasks with chatgpt and its friends in hugging face\.External Links:2303\.17580,[Link](https://arxiv.org/abs/2303.17580)Cited by:[§1](https://arxiv.org/html/2608.18171#S1.p1.1),[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1)\.
- Tekniumet al\.\(2024\)R\. Teknium, J\. Quesnelle, and C\. GuangHermes 3 technical report\.External Links:2408\.11857,[Link](https://arxiv.org/abs/2408.11857)Cited by:[Appendix B](https://arxiv.org/html/2608.18171#A2.p1.1)\.
- Yanget al\.\(2024\)L\. Yang, K\. Lee, R\. Nowak, and D\. PapailiopoulosLooped transformers are better at learning learning algorithms\.External Links:2311\.12424,[Link](https://arxiv.org/abs/2311.12424)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Yaoet al\.\(2023\)S\. Yao, J\. Zhao, D\. Yu, N\. Du, I\. Shafran, K\. Narasimhan, and Y\. CaoReAct: synergizing reasoning and acting in language models\.External Links:2210\.03629,[Link](https://arxiv.org/abs/2210.03629)Cited by:[§1](https://arxiv.org/html/2608.18171#S1.p1.1),[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px2.p1.1)\.
- Zelikmanet al\.\(2024\)E\. Zelikman, G\. Harik, Y\. Shao, V\. Jayasiri, N\. Haber, and N\. D\. GoodmanQuiet\-star: language models can teach themselves to think before speaking\.External Links:2403\.09629,[Link](https://arxiv.org/abs/2403.09629)Cited by:[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1)\.
- Zhuet al\.\(2025\)R\. Zhu, Z\. Wang, K\. Hua, T\. Zhang, Z\. Li, H\. Que, B\. Wei, Z\. Wen, F\. Yin, H\. Xing, L\. Li, J\. Shi, K\. Ma, S\. Li, T\. Kergan, A\. Smith, X\. Qu, M\. Hui, B\. Wu, Q\. Min, H\. Huang, X\. Zhou, W\. Ye, J\. Liu, J\. Yang, Y\. Shi, C\. Lin, E\. Zhao, T\. Cai, G\. Zhang, W\. Huang, Y\. Bengio, and J\. EshraghianScaling latent reasoning via looped language models\.External Links:2510\.25741,[Link](https://arxiv.org/abs/2510.25741)Cited by:[§A\.1](https://arxiv.org/html/2608.18171#A1.SS1.p1.1),[§2](https://arxiv.org/html/2608.18171#S2.SS0.SSS0.Px1.p1.1),[§3](https://arxiv.org/html/2608.18171#S3.SS0.SSS0.Px1.p1.1)\.

## Appendix ALooped Models Architectural Details

This section summarizes the architectures and training procedures of the looped language models evaluated throughout this work\. We first describe the native recurrent Ouro models and then the retrofitted recurrent models, focusing on the architectural and training differences relevant to our evaluation\.

### A\.1Ouro

Ouro\[[30](https://arxiv.org/html/2608.18171#bib.bib3)\]is a family of pretrained looped language models that performs iterative latent computation by repeatedly applying a shared stack ofLLdecoder\-only Transformer layers\. The recurrent block consists of standard Transformer layers with multi\-head self\-attention, Rotary Position Embeddings \(RoPE\), SwiGLU feed\-forward networks, and sandwich RMSNorm\. Rather than stacking independently parameterized layers, the same recurrent block is applied for up toTmax=4T\_\{\\max\}=4recurrent iterations, allowing additional test\-time computation without increasing the number of model parameters\. The released checkpoints are Ouro\-1\.4B, containing a 24\-layer recurrent stack, and Ouro\-2\.6B, obtained by doubling the recurrent stack to 48 layers and continuing pretraining\. Both models use a hidden size of 2048 and are pretrained on approximately 7\.7T tokens\.

At each recurrent iterationtt, Ouro predicts both the next\-token distribution and a conditional halting probabilityλ\(t\)​\(x\)=σ⁡\(Linearϕ​\(h\(t\)\)\),\\lambda^\{\(t\)\}\(x\)=\\sigma\\\!\\left\(\\mathrm\{Linear\}\_\{\\phi\}\(h^\{\(t\)\}\)\\right\),which induces an exit distribution over recurrent depthspϕ​\(t∣x\)=λ\(t\)​\(x\)​∏j<t\(1−λ\(j\)​\(x\)\),p\_\{\\phi\}\(t\\mid x\)=\\lambda^\{\(t\)\}\(x\)\\prod\_\{j<t\}\\left\(1\-\\lambda^\{\(j\)\}\(x\)\\right\),with the remaining probability mass assigned to the final recurrent iteration\. This exit distribution is used both during training to weight the prediction losses across recurrent depths and during inference to determine the adaptive computation depth\.

Training proceeds in two stages\. Stage I jointly optimizes the language model and halting gate using

ℒ=∑t=1Tmaxpϕ\(t∣x\)ℒ\(t\)−βH\(pϕ\(⋅∣x\)\),\\mathcal\{L\}=\\sum\_\{t=1\}^\{T\_\{\\max\}\}p\_\{\\phi\}\(t\\mid x\)\\,\\mathcal\{L\}^\{\(t\)\}\-\\beta H\\\!\\left\(p\_\{\\phi\}\(\\cdot\\mid x\)\\right\),whereℒ\(t\)\\mathcal\{L\}^\{\(t\)\}is the language\-model loss after recurrent iterationtt\. The entropy regularization term is equivalent to a KL penalty towards a uniform prior over exit depths, encouraging the model to utilize multiple recurrent iterations before specializing the halting policy\.

In Stage II, the language\-model backbone is frozen and only the halting gate is optimized\. Rather than supervising language\-model predictions, the gate is trained from the marginal utility of executing one additional recurrent iteration\. Given the detached improvement in prediction lossIi\(t\)=max⁡\(0,ℒi,stop\(t−1\)−ℒi,stop\(t\)\),I\_\{i\}^\{\(t\)\}=\\max\\\!\\left\(0,\\mathcal\{L\}^\{\(t\-1\)\}\_\{i,\\mathrm\{stop\}\}\-\\mathcal\{L\}^\{\(t\)\}\_\{i,\\mathrm\{stop\}\}\\right\),the improvement score is converted into a soft exit targetyi\(t\)y\_\{i\}^\{\(t\)\}, and the gate is optimized using the binary cross\-entropy objective

ℒgate=−∑t=1Tmax\[y\(t\)logλ\(t\)\+\(1−y\(t\)\)log\(1−λ\(t\)\)\]\.\\mathcal\{L\}\_\{\\mathrm\{gate\}\}=\-\\sum\_\{t=1\}^\{T\_\{\\max\}\}\\Big\[y^\{\(t\)\}\\log\\lambda^\{\(t\)\}\+\(1\-y^\{\(t\)\}\)\\log\\\!\\left\(1\-\\lambda^\{\(t\)\}\\right\)\\Big\]\.This second stage improves the calibration of the adaptive exit policy while leaving the pretrained recurrent representations unchanged\.

Throughout this work, we evaluate the released Ouro\-1\.4B and Ouro\-2\.6B checkpoints\. We consider both fixed\-depth inference, where every token executes a predetermined number of recurrent iterations, and adaptive inference using the pretrained halting gate\.

### A\.2Retrofitted Recurrent Models

In addition to the native recurrent Ouro architecture, we evaluate the retrofitted recurrent language models of[18](https://arxiv.org/html/2608.18171#bib.bib17), which convert pretrained decoder\-only Transformers into looped models while largely preserving their pretrained parameters\. The original Transformer is partitioned into three components: a non\-recurrent prelude, a shared recurrent block, and a non\-recurrent coda\. The recurrent block consists of a contiguous subset of Transformer layers whose parameters are shared across recurrent iterations\. During inference, the prelude is executed once, the recurrent block is repeatedly applied for a configurable number of iterations, and the coda is executed once before producing the next\-token prediction\. This retrofit increases inference\-time computation through repeated latent refinement while maintaining the initialization and capabilities of the original pretrained model\.

In contrast to Ouro, the retrofitted model does not learn an adaptive halting policy\. Instead, the number of recurrent iterationsrris sampled independently for each training batch from a Poisson\-lognormal depth distribution,λ∼LogNormal⁡\(μ,σ2\)​,​r∼Poisson⁡\(λ\),\\lambda\\sim\\mathrm\{LogNormal\}\(\\mu,\\sigma^\{2\}\)\\text\{, \}r\\sim\\mathrm\{Poisson\}\(\\lambda\),whereμ\\muandσ\\sigmacontrol the expected recurrence depth\. The model is then supervised only after the sampled number of recurrent iterations using the objective

ℒ\(θ\)=𝔼x𝔼r∼DPLN\[∑ℓ=1M−1−logpθ\(r\)\(xℓ\+1∣x1:ℓ\)\+βDKL\(pθ0\(⋅∣x1:ℓ\)∥pθ\(r\)\(⋅∣x1:ℓ\)\)\],\\mathcal\{L\}\(\\theta\)=\\mathbb\{E\}\_\{x\}\\mathbb\{E\}\_\{r\\sim D\_\{\\mathrm\{PLN\}\}\}\\left\[\\sum\_\{\\ell=1\}^\{M\-1\}\-\\log p\_\{\\theta\}^\{\(r\)\}\(x\_\{\\ell\+1\}\\mid x\_\{1:\\ell\}\)\+\\beta D\_\{\\mathrm\{KL\}\}\\\!\\left\(p\_\{\\theta\_\{0\}\}\(\\cdot\\mid x\_\{1:\\ell\}\)\\;\\\|\\;p\_\{\\theta\}^\{\(r\)\}\(\\cdot\\mid x\_\{1:\\ell\}\)\\right\)\\right\],wherepθ\(r\)p\_\{\\theta\}^\{\(r\)\}denotes the next\-token distribution afterrrrecurrent iterations andpθ0p\_\{\\theta\_\{0\}\}is the corresponding distribution of the frozen pre\-adaptation model\. The KL regularization preserves the behavior of the original pretrained model while adapting it to recurrent computation\. Unlike Ouro, which jointly optimizes predictions across all recurrent iterations using a learned exit distribution, the retrofitted model computes the language\-model loss only from the final recurrent prediction corresponding to the sampled recurrence depth\.

Throughout this work, we evaluate released retrofitted recurrent checkpoints initialized from two pretrained model families: OLMo\-2\-0425\-1B and Llama\-3\.2\-1B\. Since the model does not include a learned halting mechanism, we evaluate it only under fixed\-depth inference by varying the number of recurrent iterations executed during generation\.

## Appendix BHermes Function\-Calling Dataset

All supervised fine\-tuning experiments described in this work use the Hermes Function\-Calling V1 dataset introduced by Nous Research\[[10](https://arxiv.org/html/2608.18171#bib.bib29),[26](https://arxiv.org/html/2608.18171#bib.bib30)\]\. The dataset is a synthetic instruction\-following corpus designed for training language models to produce structured function calls and JSON outputs from natural\-language requests\. It combines single\-function and multi\-function tool\-calling conversations together with structured extraction, JSON\-mode, and agentic interaction examples, all formatted according to the Hermes Function\-Calling standard\. The training examples include user requests, tool definitions expressed through JSON schemas, assistant\-generated tool calls, tool responses, and final assistant replies, allowing models to learn both API selection and argument generation in multi\-turn settings\. The released dataset also incorporates updated function calling data derived from the Glaive function\-calling corpus and additional synthetic tool use examples created by Nous Research\. Throughout this work, all controlled supervised fine\-tuning experiments use the same Hermes Function\-Calling V1 training split and ChatML formatting described in Section[4](https://arxiv.org/html/2608.18171#S4)\.

## Appendix CAdditional Qualitative Examples

This section provides further qualitative examples of how predictions change with recurrent depth, complementing Figure[5](https://arxiv.org/html/2608.18171#S5.F5)\. All examples are drawn from the NESTful subset described in Section[4\.3](https://arxiv.org/html/2608.18171#S4.SS3), using fixed\-depth inference\. In each figure, the tool catalogue is the full candidate set supplied to the model for that instance, and calls are shown in the compact formfunction\(argument=value\)→\\rightarrowlabel\. The examples here illustrate the error types we observe at low recurrent depth: functions absent from the supplied catalogue, argument names drawn from other tool specifications, incorrect call ordering, spurious additional calls, and omitted dependent calls\.

Figure[6](https://arxiv.org/html/2608.18171#A3.F6)illustrates several failure modes being corrected over recurrent refinement\. The initial prediction is malformed, while the second iteration produces a syntactically valid but semantically incorrect sequence that introduces an unsupported function\. Subsequent recurrent steps eliminate both the ordering error and the hallucinated tool invocation, converging to the gold execution trace without further modification\.

Figure 6:Ordering and spurious\-call correction\.At depth 1 the output is malformed, emitting tool specifications rather than call arguments \(excerpt shown truncated\)\. At depth 2 both gold functions appear but in reversed order, followed by a call tomultiply, which is absent from the tool catalogue, and an invalid variable reference\. Depths 3 and 4 match the gold sequence, differing from each other only in label naming\.The remaining examples isolate narrower changes\. Figure[7](https://arxiv.org/html/2608.18171#A3.F7)shows a case where function selection is already correct at depth 1 and only the argument names differ from the specification\. The model suppliesinput\_str, which is a parameter of a different tool in the same catalogue, and repeats it as a second argument\. The correction at depth 2 therefore affects argument grounding and the presence of the dependent call, rather than the choice of function\.

Figure 7:Argument correction\.At depth 1 the model selects the correct first function but names its argumentinput\_str, a parameter of a different tool in the same catalogue, duplicates it asinput\_str\_2, and omits the dependent call\. Depths 2 through 4 match the gold sequence and are identical to one another\.Figure[8](https://arxiv.org/html/2608.18171#A3.F8)shows a case in which the prediction changes between two consecutive incorrect depths\. Depths 1 and 2 name different functions, neither of which appears in the supplied catalogue, and both omit the second call\. The two correct depths differ only in the order of the keys within the second call’s argument dictionary, which the evaluator treats as equivalent\.

Figure 8:Two distinct incorrect attempts before recovery\.Depths 1 and 2 each emit a single call to a function absent from the tool catalogue and omit the required dependent call\. At depth 1, the model also uses an argument name belonging to a different tool in the catalogue\. Depths 3 and 4 select both gold functions and correctly pass$var1\.output\_0$, differing only in argument\-key order\.Finally, Figure[9](https://arxiv.org/html/2608.18171#A3.F9)separates the recovery of a dependency from any change in function selection\. The first call is already identical to the gold call at depth 2, and the only difference between depths 2 and 3 is the addition of the second call together with the reference$var1\.output\_0$\. Depth 1 in this example produces an object with no function name at all, which the parser does not resolve to a call\.

Figure 9:Isolated recovery of a missing dependent call\.Depth 1 emits an object with no function name, returning a computed literal, so the parser yields no calls\. Depth 2 emits a first call that matches the gold sequence exactly but stops there\. Depths 3 and 4 leave that first call unchanged and add the dependent call with the reference$var1\.output\_0$, isolating the recovery of the dependency from any change in function selection\.Across these examples, the changes observed with additional recurrent depth involve which functions are named, which arguments they receive, how many calls are emitted, and how intermediate outputs are referenced\. We describe only observable differences between predictions and the gold sequence, and we do not claim that these figures are representative of the error distribution over the full evaluation set\.

## Appendix DTool\-Calling Benchmark Examples

This section provides representative examples from the tool\-calling benchmarks evaluated in this work and relates their task structures to the formalism introduced in Section[3](https://arxiv.org/html/2608.18171#S3)\. We represent a tool use solution asGx=\(Cx,Ex\)G\_\{x\}=\(C\_\{x\},E\_\{x\}\), whereCxC\_\{x\}is the set of required function calls andExE\_\{x\}contains output\-to\-input dependencies between calls\. The benchmarks emphasize complementary aspects of this structure: API\-Bank focuses on evaluating the grounding of individual calls, BFCL evaluates function selection and the construction of independent multi\-call sets, and NESTful evaluates dependent call graphs in which intermediate outputs are consumed by subsequent calls\. Table[4](https://arxiv.org/html/2608.18171#A4.T4)summarizes these differences before we present representative examples from each benchmark\.

Table 4:Structural comparison of the evaluated tool\-calling benchmarks under the solution representationGx=\(Cx,Ex\)G\_\{x\}=\(C\_\{x\},E\_\{x\}\)\. API\-Bank emphasizes individual\-call grounding, BFCL evaluates increasingly complex independent call sets, and NESTful introduces explicit output\-to\-input dependencies\.### D\.1Berkeley Function Calling Leaderboard

The Berkeley Function Calling Leaderboard \(BFCL\) evaluates whether a language model can select and instantiate functions from natural\-language requests\[[19](https://arxiv.org/html/2608.18171#bib.bib27)\]\. We evaluate the non\-live single\-turn categories: Simple, Multiple, Parallel, and Parallel\-Multiple\. These categories differ in the number of candidate tools supplied to the model and in the number of calls that must be generated\. They do not require the output of one call to be consumed by another\. Such output\-to\-input dependencies are instead studied by the NESTful dataset\.

Using the notation introduced in Section[3](https://arxiv.org/html/2608.18171#S3), let𝒯x⊆𝒯\\mathcal\{T\}\_\{x\}\\subseteq\\mathcal\{T\}denote the candidate tools supplied with requestxx, and letCx=\{c1,…,cK\}​,​ck=\(fk,ak\),C\_\{x\}=\\\{c\_\{1\},\\ldots,c\_\{K\}\\\}\\text\{, \}c\_\{k\}=\(f\_\{k\},a\_\{k\}\),denote the reference call set\. For the BFCL single\-turn categories considered here, the calls within an example are independent, and hence the dependency graph satisfiesEx=∅E\_\{x\}=\\varnothing\. The categories differ mainly in\|𝒯x\|\|\\mathcal\{T\}\_\{x\}\|and\|Cx\|\|C\_\{x\}\|\. The following examples are reproduced in shortened form from the executable counterparts of the corresponding BFCL categories\. Tool descriptions are shortened for readability\.

#### Simple\.

Simple examples supply a single tool and require one call:\|𝒯x\|=1,\|Cx\|=1,Ex=∅\.\|\\mathcal\{T\}\_\{x\}\|=1,\\text\{ \}\|C\_\{x\}\|=1,\\text\{ \}E\_\{x\}=\\varnothing\.For example, the request

> “A biased die produces a six with probability0\.60\.6\. If it is rolled2020times, what is the probability of obtaining exactly five sixes?”

is accompanied by the toolcalc\_binomial\_probability\(n, k, p\),\\texttt\{calc\\\_binomial\\\_probability\(n, k, p\)\},and has the reference callCx=\{calc\_binomial\_probability\(n=20, k=5, p=0\.6\)\}\.C\_\{x\}=\\left\\\{\\texttt\{calc\\\_binomial\\\_probability\(n=20, k=5, p=0\.6\)\}\\right\\\}\.This category tests argument extraction and schema\-conformant call generation\.

#### Multiple\.

Multiple examples supply between two and four candidate tools but require only one call:\|𝒯x\|\>1,\|Cx\|=1,Ex=∅\.\|\\mathcal\{T\}\_\{x\}\|\>1,\\text\{ \}\|C\_\{x\}\|=1,\\text\{ \}E\_\{x\}=\\varnothing\.For example, a request asks for the probability of obtaining exactly 5 sixes in2020fair\-die rolls\. The candidate set contains bothget\_weather\_data\(coordinates\)andcalc\_binomial\_probability\(n, k, p\)\.\\texttt\{get\\\_weather\\\_data\(coordinates\)\}\\text\{ and \}\\texttt\{calc\\\_binomial\\\_probability\(n, k, p\)\}\.The correct call isCx=\{calc\_binomial\_probability\(n=20, k=5, p=1/6\)\}\.C\_\{x\}=\\left\\\{\\texttt\{calc\\\_binomial\\\_probability\(n=20, k=5, p=1/6\)\}\\right\\\}\.Thus, “Multiple” refers to the presence of multiple candidate function definitions, rather than to the generation of multiple calls\. The category tests function selection in addition to argument grounding\.

#### Parallel\.

Parallel examples require multiple independent invocations of a supplied function:\|Cx\|\>1,Ex=∅\.\|C\_\{x\}\|\>1,\\text\{ \}E\_\{x\}=\\varnothing\.For example, BFCL includes the request

> “Play songs from Taylor Swift and Maroon 5 for 20 minutes and 15 minutes, respectively, on Spotify\.”

with the toolspotify\.play\(artist, duration\)\.\\texttt\{spotify\.play\(artist, duration\)\}\.The reference call set is

Cx=\{spotify\.play\(artist=\{Taylor Swift\}, duration=20\),spotify\.play\(artist=\{Maroon 5\}, duration=15\)\}\.C\_\{x\}=\\left\\\{\\begin\{aligned\} &\\texttt\{spotify\.play\(artist=\\lx@text@lbrace Taylor Swift\\lx@text@rbrace, duration=20\)\},\\\\ &\\texttt\{spotify\.play\(artist=\\lx@text@lbrace Maroon 5\\lx@text@rbrace, duration=15\)\}\\end\{aligned\}\\right\\\}\.The calls do not consume one another’s outputs and may therefore be executed concurrently\. The model must identify the correct number of calls and align each entity with its corresponding arguments\.

#### Parallel\-Multiple\.

Parallel\-Multiple combines multiple candidate functions with the generation of multiple independent calls:\|𝒯x\|\>1,\|Cx\|\>1,Ex=∅\.\|\\mathcal\{T\}\_\{x\}\|\>1,\\text\{ \}\|C\_\{x\}\|\>1,\\text\{ \}E\_\{x\}=\\varnothing\.For example, a request asks both for the current weather in Ottawa and for the probability of obtaining 5 wins in ten independent attempts with success probability0\.50\.5\. The candidate tools areget\_weather\_data\(coordinates\)andcalc\_binomial\_probability\(n, k, p\),\\texttt\{get\\\_weather\\\_data\(coordinates\)\}\\text\{ and \}\\texttt\{calc\\\_binomial\\\_probability\(n, k, p\)\},and the reference call set is

Cx=\{get\_weather\_data\( coordinates=\[45\.4215,\-75\.6972\]\),calc\_binomial\_probability\( n=10, k=5, p=0\.5\)\}\.C\_\{x\}=\\left\\\{\\begin\{aligned\} &\\texttt\{get\\\_weather\\\_data\( coordinates=\[45\.4215,\-75\.6972\]\)\},\\\\ &\\texttt\{calc\\\_binomial\\\_probability\( n=10, k=5, p=0\.5\)\}\\end\{aligned\}\\right\\\}\.This category jointly tests function selection, call\-set construction, and argument assignment across different tools\.

### D\.2NESTful

NESTful evaluates nested sequences of executable API calls in which the output of one function is passed as an argument to a subsequent function\[[4](https://arxiv.org/html/2608.18171#bib.bib28)\]\. Each instance contains a user request, a catalog of available tools, a gold sequence of calls with arguments, and the final answer obtained by executing that sequence\. The released evaluation set contains 1861 instances drawn from mathematical reasoning and coding domains, together with executable implementations of the corresponding functions\.

Using the notation of Section[3](https://arxiv.org/html/2608.18171#S3), a NESTful solution is represented asGx=\(Cx,Ex\),G\_\{x\}=\(C\_\{x\},E\_\{x\}\),whereCx=\{c1,…,cK\}C\_\{x\}=\\\{c\_\{1\},\\ldots,c\_\{K\}\\\}contains the required function calls and\(ci,cj\)∈Ex\(c\_\{i\},c\_\{j\}\)\\in E\_\{x\}whenever the output ofcic\_\{i\}is used to instantiate an argument ofcjc\_\{j\}\. Unlike the BFCL single\-turn categories considered in this work, NESTful therefore evaluates both call\-set construction and explicit output\-to\-input dependencies\. Its call structure is generally a directed acyclic graph rather than merely a collection of independent calls\. NESTful assigns a unique label to the output of every call\. If a callcic\_\{i\}is assigned the label$var\_i, a later argument can refer to one of its output fields using notation such as$var\_i\.result$\.\\texttt\{\\$var\\\_i\.result\\$\}\.This makes the dependency relation explicit in the serialized reference sequence\. For example, consider the request

> “Find the average of all the numbers between 6 and 34 that are divisible by 5\.”

The corresponding solution consists of the call setCx=\{c1,c2,c3,c4\},C\_\{x\}=\\\{c\_\{1\},c\_\{2\},c\_\{3\},c\_\{4\}\\\},where

c1\\displaystyle c\_\{1\}=add​\(6,4\),\\displaystyle=\\texttt\{add\}\(6,4\),c2\\displaystyle c\_\{2\}=subtract​\(34,4\),\\displaystyle=\\texttt\{subtract\}\(34,4\),c3\\displaystyle c\_\{3\}=add​\(out⁡\(c1\),out⁡\(c2\)\),\\displaystyle=\\texttt\{add\}\\\!\\left\(\\operatorname\{out\}\(c\_\{1\}\),\\operatorname\{out\}\(c\_\{2\}\)\\right\),c4\\displaystyle c\_\{4\}=divide​\(out⁡\(c3\),2\)\.\\displaystyle=\\texttt\{divide\}\\\!\\left\(\\operatorname\{out\}\(c\_\{3\}\),2\\right\)\.
The corresponding dependency graph hasCx=\{c1,c2,c3,c4\}C\_\{x\}=\\\{c\_\{1\},c\_\{2\},c\_\{3\},c\_\{4\}\\\}andEx=\{\(c1,c3\),\(c2,c3\),\(c3,c4\)\}\.E\_\{x\}=\\\{\(c\_\{1\},c\_\{3\}\),\(c\_\{2\},c\_\{3\}\),\(c\_\{3\},c\_\{4\}\)\\\}\.Callsc1c\_\{1\}andc2c\_\{2\}are independent and may be evaluated in parallel\. Callc3c\_\{3\}depends on both of their outputs, whilec4c\_\{4\}depends on the output ofc3c\_\{3\}\. The longest dependency path therefore has two edges:

c1→c3→c4orc2→c3→c4\.c\_\{1\}\\rightarrow c\_\{3\}\\rightarrow c\_\{4\}\\qquad\\text\{or\}\\qquad c\_\{2\}\\rightarrow c\_\{3\}\\rightarrow c\_\{4\}\.Executing the complete sequence produces the gold answer2020\.

This example illustrates the distinction between node composition and dependency composition\. The model must first select the correct calls and instantiate their constant arguments, as in ordinary multi\-call generation\. It must additionally assign outputs to variables, select the correct output fields, and bind those variables to the arguments of subsequent calls\. Errors can therefore arise from selecting an incorrect function, constructing an incorrect argument, omitting a call, producing the wrong ordering, or referencing the wrong intermediate variable\. NESTful reports complementary metrics at different levels of the predicted solution\. Function and parameter scores measure the correctness of individual calls, partial sequence matching measures how much of the gold call sequence is recovered, and full sequence matching requires the complete sequence of functions and arguments to match\. The benchmark additionally executes the predicted calls and reports a win rate based on whether the resulting answer is correct\. These metrics distinguish locally plausible calls from complete, dependency\-preserving solutions\.

### D\.3API\-Bank

API\-Bank evaluates tool\-augmented language models through conversational API usage\[[16](https://arxiv.org/html/2608.18171#bib.bib26)\]\. Each instance consists of a user request, a collection of available APIs, an expected API invocation, the API response, and the final assistant response\. Compared to BFCL and NESTful, API\-Bank evaluates the grounding of individual tool calls rather than the construction of multi\-call workflows\. An API\-Bank example is represented asGx=\(Cx,Ex\),G\_\{x\}=\(C\_\{x\},E\_\{x\}\),where\|Cx\|=1,Ex=∅\.\|C\_\{x\}\|=1,\\text\{ \}E\_\{x\}=\\varnothing\.The task is therefore to select the correct function and instantiate its arguments from the user request before integrating the returned observation into the final response\.

For example, consider the dialogue “Can you calculate\(5\+6\)×3\(5\+6\)\\times 3for me?” The available API isCalculator\(formula\),\\texttt\{Calculator\(formula\)\},whereformulais a string containing an arithmetic expression\. The corresponding reference call isCx=\{Calculator​\(formula=’\(5\+6\)\*3’\)\}\.C\_\{x\}=\\left\\\{\\texttt\{Calculator\}\\\!\\left\(\\texttt\{formula\}=\\texttt\{'\(5\+6\)\*3'\}\\right\)\\right\\\}\.Since the instance requires a single API invocation, its dependency relation isEx=∅\.E\_\{x\}=\\varnothing\.

The example tests whether the model can identify the required API, translate the natural\-language request into the expected argument representation, and produce a correctly formatted invocation\. More generally, API\-Bank evaluates API selection and argument generation within conversational contexts, which may contain information accumulated across multiple dialogue turns\. Unlike BFCL, which explicitly evaluates the construction of independent multi\-call sets, and NESTful, which evaluates output\-to\-input dependencies between calls, the API\-Bank setting considered in our evaluation emphasizes the grounding and invocation of individual APIs\.