Build1 distinct publisher2 min readPublished
Spring AI 2.0 moves schema enforcement to the provider, which trims input tokens on every healthy call. The retry path still bills the whole context again, in full.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The line item worth pricing first is not the failed call. Under the prompt-based route, the format instructions and the JSON schema are generated and appended to the prompt [5], which means they are billed on every call that works as well as on the ones that do not. Sending the schema to the provider as an API-level rule takes that block out of the input [7], and the input token count falls on every call [8]. That saving tracks request volume. The retry saving tracks defect rate, and the series' own example puts a 5% one-retry rate at roughly 5% extra input tokens with nothing to show for them [3]. On a busy endpoint with a low failure rate, the dull always-on saving is the larger of the two.
The failure path is expensive because of what it resends. A retry ships the system prompt, the conversation history, the RAG context and the tool schemas again, and the answer that could not be parsed is billed as output in full whether or not it was cut off [2]. With validation switched on, Spring AI appends the validation error to the user message and calls the model again, up to three attempts by default [11], so a single usable answer can reach four model calls [19] and up to four times the cost [4].
Prevention does not cover every method signature. Spring AI 2.0 supports provider-native structured output for OpenAI, Anthropic, Google GenAI, Mistral AI and, depending on the model, Ollama [9], but OpenAI rejects top-level array schemas, so asking for a List<T> fails, and Ollama models in reasoning mode can still return plain text [10]. Those endpoints keep the retry mechanism, which is why the series treats validation as a recovery step rather than the primary control [12].
The embedding side inverts the problem. At OpenAI's August 2026 list price, text-embedding-3-small is $0.02 per million input tokens [15], one fiftieth of the $1 per million input rate the series uses as its example rate elsewhere [16][18]. Per token, that is not a number anyone needs to manage. Per pass it is $20 for every billion tokens of corpus [17], and the pipeline pays it again whenever documents are added or updated, or a full re-index is required [13]. Dimensionality is the driver that keeps charging after the indexing run finishes, through storage and retrieval [14].
One gap to flag: the series says a fourth source of embedding calls has nothing to do with documents at all, and the text supplied to us stops in the pricing section before it is named [14][20].
Ranked by verification strength, evidence, and original report placement.
Each retry resends the request context - system prompt, conversation history, RAG context and tool schemas - so the input tokens are billed again, and the failed answer is billed as output in full, cut off or not.
Example given: if 5% of requests require one retry, input token usage increases by roughly 5% without producing additional business value.
A retry policy allowing three retries can make worst-case requests cost up to four times more.
According to OpenAI's pricing as of August 2026, text-embedding-3-small costs $0.02 per million input tokens.
The series uses list prices where a ratio matters and an example rate of $1 per million input tokens elsewhere.
The fourth and final part of a dev.to series on LLM cost control covers controls for failed responses and for the indexing side of RAG, and closes with a map of all ten cost drivers.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single self-published tutorial, internally consistent but unverified
Every claim traces to one dev.to article. Its strengths are specificity (named API methods, advisor class, default retry count, provider limitations) and arithmetic that checks out internally: $0.02 per million input tokens implies about $1 for a 50-million-token corpus and about $20 per billion tokens. Its weaknesses are that no primary Spring AI release notes, provider documentation or pricing page is present in the cluster, no measured token or cost deltas are reported, and the supplied text breaks off mid-sentence before the promised fourth embedding-call source and the ten-driver map.
No usage or deployment evidence
The cluster contains only a description of available Spring AI 2.0 features. There are no downloads, deployment reports, production usage disclosures, benchmark runs or third-party accounts of teams adopting provider-native structured output or the validation advisor, so adoption cannot be scored without inference.
Mildly overstated: savings asserted, never measured
The article is restrained by tutorial standards and volunteers its own limits (OpenAI top-level array rejection, Ollama reasoning-mode fallback, validation retries costing tokens). The gap is narrow but positive: 'reducing input token usage on every call' and prevention of invalid structured responses are asserted as properties of the provider path with no measured token delta, no failure-rate comparison and no cited provider documentation, while the cost examples are illustrative percentages rather than observed spend.
Author-series promotion, no disclosed vendor tie
The piece is part 4 of 4 in a self-published dev.to series that repeatedly cross-references its earlier parts and defers a teased item to the end, which serves audience-building. It advocates specific Spring AI 2.0 features and provider capabilities, so it is not neutral, but the cluster shows no vendor sponsorship, affiliate arrangement or employer relationship, and the article publishes limitations against its own recommendation. Incentive pressure is therefore present but modest.
Moderate-low: one publisher, one truncated source
Claim extraction is straightforward because the source is explicit and technical, and the arithmetic in the derived claims is verifiable. But the cluster has a single publisher and a single article whose supplied text is cut off, no corroboration for the framework or pricing claims, and no adoption signal at all, so confidence in the overall assessment stays moderate-low.
build
OpenClaw makes the channel the architecture, and the reasoning loop a lodger1 distinct publisher
product
Incogni ranks 13 AI assistants by privacy risk: bigger is worse, except ChatGPT1 distinct publisher
build
GitHub's Java agent runtime ships as a Maven dependency, and the tool schema comes from reflection1 distinct publisher
build
Hash-anchored edits turn a lost race into an error, and that contract outranks the tool count1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026