Java applications reach large language models (LLMs) through an integration framework, and rely on it to handle a failing provider: to retry what can be retried and nothing else, to wait as long as the provider asks, never to present a truncated answer as complete, and to record each failure in the application's metrics. We state these expectations as a six-clause reliability contract and measure Spring AI 2.0.1 and LangChain4j 1.21.0 against it with a scripted OpenAI-compatible provider: fifteen failure scenarios, synchronous and streaming, three repetitions. LangChain4j meets it in 47 of 77 applicable cases with its defaults and in 51 of 83 when configured explicitly, Spring AI in 72 of 77 and 76 of 83; both deliver a stream that ended without its terminator as a complete answer. We then place one implementation of the contract beneath both frameworks, at the HTTP boundary - an OkHttp interceptor for Spring AI, an HttpClient for LangChain4j, and a java.net.http transport for code without a framework - sharing a 725-line core that depends only on the JDK and the Micrometer Observation API. With it, all three clients behave identically and meet the contract in 90 of 91 cases; the remaining case is a policy trade-off between retrying a hung provider and waiting for a slow first token. Against a local model server the layer rejected none of 700 calls, and it adds a median of 32-217 microseconds to a call.
Figures & tables
Fig. 1: Placement of the layer. Each framework keeps its API and its exception types; its own retries are switched off and its HTTP client is replaced by an adapter that delegates to one core implementing the contract. Code without a framework uses the java.net.http transport directly.
Clause
LC4j defaults
LC4j explicit
LC4j + guard
Spring AI defaults
Spring AI explicit
Spring AI + guard
plain + guard
C1 retry exactly the transient
11/15
11/16
17/17
15/15
15/16
17/17
17/17
C2 wait as asked
0/3
0/3
3/3
3/3
3/3
3/3
3/3
C3 no incomplete answer as complete
16/18
17/19
21/21
16/18
17/19
21/21
21/21
C4 bound silence, not length
3/5
4/7
7/8
4/5
5/7
7/8
7/8
C5 record every outcome
5/18
6/19
21/21
16/18
17/19
21/21
21/21
C6 every attempt visible
12/18
13/19
21/21
18/18
19/19
21/21
21/21
TABLE I: Cells meeting each clause / cells to which it applies (all repetitions agree).
Fig. 2: Share of applicable cells that meet all six clauses (Table I , last row): each framework with its defaults, with an explicit configuration, and with the guard installed; and the guard without a framework.
Client
Mode
llama3.2 native
llama3.2 + guard
qwen2.5:7b native
qwen2.5:7b + guard
Spring AI
sync
50/50 · 229
50/50 · 221
20/20 · 342
20/20 · 391
Spring AI
stream
50/50 · 223
50/50 · 234
20/20 · 380
20/20 · 327
LangChain4j
sync
50/50 · 241
50/50 · 236
20/20 · 353
20/20 · 342
LangChain4j
stream
50/50 · 224
50/50 · 245
20/20 · 363
20/20 · 351
plain
sync
—
50/50 · 243
—
20/20 · 361
plain
stream
—
50/50 · 239
—
20/20 · 370
TABLE II: Real server: successful calls / calls, and median latency (ms).
Client
Mode
Median without / with ( μ s)
Added, median ( μ s)
Added, P95 ( μ s)
Spring AI
sync
582 / 645
63
987
Spring AI
stream
839 / 977
138
576
LangChain4j
sync
621 / 653
32
201
LangChain4j
stream
522 / 739
217
617
java.net.http
sync
325 / 364
39
90
java.net.http
stream
358 / 513
155
313
TABLE III: Latency added to a successful call by the guard, against the scripted provider (2,000 calls each).
Large language model reliability studies whether outputs remain correct, calibrated, robust, and controllable across prompts, contexts, and deployment conditions.
In production large language model (LLM) deployments, high API availability guarantees do not equate to conversational continuity. When a primary provider experiences an outage or strict rate-limiting, naive stateless failover mechanisms successfully maintain uptime but silently discard conversation history, severely disrupting the user experience. To rigorously quantify and resolve this failure mode, we introduce two novel metrics: Continuity Preservation Rate (CPR) and Continuity Latency Overhead (CLO). We propose a stateful, multi-provider proxy architecture utilizing a History-Forwarding strategy to seamlessly reconstruct conversational state across heterogeneous LLM endpoints during failover events. Furthermore, we release continuity-bench, https://github.com/Vishal-sys-code/continuity-bench, an open evaluation harness designed to stress-test context preservation under high-concurrency provider failure conditions. Our empirical evaluation (N=750 failover events) demonstrates that our stateful proxy achieves a 99.20% CPR [95% CI: 98.27%, 99.63%], cleanly transferring deep conversational context to fallback providers, compared to a near-0% preservation rate for standard stateless architectures. Finally, we characterize failover latency distributions, identifying the critical necessity of asynchronous exponential backoff with jitter to prevent cascading retry storms against strict-limit fallback APIs. Our results provide a principled foundation for building robust, state-preserving multi-model inference systems.
When an LLM agent fails a multi-step tool-augmented task and retries, the failed attempt typically remains in its context window -- contaminating the next attempt and elevating the per-step error rate beyond the base level. This context-contaminated restart phenomenon is widely observed in practice yet entirely lacks formal treatment. We introduce the Context-Contaminated Restart Model (CCRM): a chain of T tool-call steps, each failing with base rate epsilon_0; after any failed attempt, the subsequent attempt operates in contaminated context with elevated error rate epsilon_1 > epsilon_0. Under this model we derive five main results. (R1) An exact closed-form formula for P(succeed in at most K attempts). (R2) A cascade-overhead theorem giving the additional attempts Delta K incurred by contamination versus the clean-restart baseline. (R3) An optimal budget-allocation theorem identifying the pipeline depth T* that maximises success probability for a fixed total budget B=KT; we prove the closed form T* = sqrt(B * log(1/(1-epsilon_1)) / log(1/(1-epsilon_0))), with K*=B/T*. (R4) An information-theoretic lower bound via Le Cam's method showing K_CCRM is tight up to O(1). (R5) A clean-restart dominance theorem quantifying the exact benefit of context-clearing before retry. We validate CCRM on real SWE-bench Verified data: the IID model overestimates pass@3 by 17.4 percentage points (98.6% vs. 81.2%), while CCRM fits with error less than 0.001, implying a cascade ratio of epsilon_1/epsilon_0 = 7.1. Monte Carlo experiments confirm all theoretical predictions.
Zhanfu Yang
Department of Computer Science, Rutgers University, Piscataway, NJ 08854, USA
Reliability in large language model (LLM) systems is typically framed as a function of model capability. We challenge this by demonstrating that reliability is significantly influenced by inference-time control -- the computational layer governing task framing and context selection. We introduce CogniConsole, an architectural instantiation that externalizes this control into a structured interface combining programmatic coordination with bounded prompt-based reasoning. Through controllability-oriented probes (N=489) in a multi-step interactive environment, we show that increasing structural scaffolding -- from unstructured to fully scaffolded -- systematically reduces output variance and failure rates under a fixed model architecture. Our results indicate that many observed failure modes, such as context drift and inconsistent constraint adherence, arise from under-specified control rather than insufficient capability. This work provides an empirical basis for treating inference-time control as a first-class abstraction, opening new directions for designing and evaluating LLM systems beyond scaling alone.