fix(*): stop silent output truncation from becoming a retry loop

[gloryfromca]

Summary

A session that asked the agent to write a terminal game produced 15 tool failures, 11 of them from one root cause, and burned 51% of its output budget re-sending the same payload. The chain: output was capped far below what the model could produce, the resulting truncation was reported as a missing required field, and the model's most reasonable answer to that message was to send the same oversized call again.

This PR cuts the chain at every link, and the last third of it comes from running the thing rather than reading it -- a live reproduction turned up four defects that review had not.

1. The ceiling: from one number to the model's own limit

chat_stream declared literal defaults for max_tokens, temperature and reasoning_effort. The agent loop calls it with messages / tools / model only, so those literals shadowed the configured values on every streaming turn -- requests went out at 4096 / 0.7 / unset. Across the last 10 days of traces, exactly one call out of 1549 produced more than 4096 output tokens, and that one took the non-streaming path.

Lifting the shadow exposed the next problem: the value it had been hiding, agents.defaults.maxTokens, defaulted to 8192 for every model, and onboarding wrote that default into the user's config file -- so by the time it reached the provider it was indistinguishable from a number the user had chosen. No single number works here: claude-sonnet-4 emits 64000 and gpt-4o 16384, while models below 8192 reject the larger value outright.

The setting is retired and the ceiling now resolves per model from the same catalogue the context window comes from. An old config carrying the key is ignored rather than rejected (AgentDefaults does not forbid extras), so no migration is needed and nobody edits a file. resolve_max_output_tokens always answers with a number -- catalogue first, then a fixed 16384 -- because the caller is about to build a request.

This is the shape LiteLLM's own Anthropic path uses, and the shape of the two surveyed implementations without known config-shadowing bugs; the four with such bugs all merge a global constant into user configuration somewhere.

2. Detecting truncation, on both paths

Two judgements, and only one of them guesses.

About the turn -- finish_reason == "length", or output_tokens reaching the ceiling we sent. Neither can be rested on alone: measured through openrouter, gpt-4o answers a ceiling hit with "tool_calls" -- a positive claim of success -- in 4 of 4 probes, with usage sitting exactly at the ceiling. The call this puts in doubt is the last one, because generation is sequential.

About one call -- its arguments had to be repaired to parse. Local, certain, and it names its own call wherever that sits in the turn.

The second needs no ceiling signal and makes no guess. The first is the guess, and it stays coarse on purpose: refusing a whole call costs one retry, while dispatching a cut one writes half a file, or turns an append into an overwrite because the optional mode never arrived, and reports success either way.

An earlier draft refined that guess further -- whether the cut landed in tool arguments or in prose, which position a repair sat at, which of two causes to name. Each layer rested on an assumption nothing had measured, two were wrong, and none of them changed what the model does next. They are gone.

The ceiling used by the first judgement is the one the request actually carried, resolved through the same function the provider uses. Computed separately the two would drift the moment either grew a bound, and the check would stop firing without ever failing.

Where the judgement happens matters as much as what it decides. The non-streaming one runs inside chat_with_retry, before it returns: trace.instrument extracts span attributes in a finally and closes the span before the caller sees the result, so a verdict reached afterwards is recorded as False every time. That method also walks [model, *fallback_models], and LLMResponse records nothing about which one answered -- deciding inside is the only place the model that actually served the turn is still known. The streaming path calls the same function from the loop, where its tool calls are assembled.

3. What the model is told, and who tells it

The shared message states what happened and why nothing ran: the call was cut at the ceiling, it was therefore not executed, and the missing part could have changed what it does. All three are true of every tool. It avoids the word "saved" on purpose -- the tool most likely to be truncated is the one that saves files, where "not saved" reads as "the write failed" rather than "your arguments never arrived".

What to do about it is the tool's to say, through Tool.truncation_hint. write_file names the append mode; exec says to shorten the command, because half a command is not a command and the previous generic advice told it to send one anyway.

A call refused for malformed JSON gets a different message and no hint at all: it is asked to resend with well-formed arguments, not to split anything up.

Two earlier wordings were wrong and both were caught by running it. The first said "do not resend the same content" -- the exact opposite of what has to happen, since nothing past the cut survives anywhere, and the model followed it for forty turns. The second put the instruction back into the shared sentence, where it duplicated the tool's own hint and still did not fit exec.

4. Downstream effects of a cut-off turn

• Think-tag debris. A turn cut off inside an inlined reasoning block arrives as a lone closing tag; an eleven-character string read as a real answer and skipped empty-response recovery. Three patterns matched only bare spellings, missing both the namespaced form vendors emit (<mm:think>) and the orphan closing tag. The paired-block substitution was the last one still matching a literal, which meant a complete <mm:think>...</mm:think> block reached the user as if the reasoning were the answer.
• Failure-streak misfires. The loop-break nudge fired after N consecutive failures of the same tool, regardless of whether they were the same failure. A model getting a truncation, then a schema error, then a missing path is adapting, not stuck. The streak now keys on (tool, failure class).
• A nudge that guessed. Its text offered three guessed causes, one of which told the model to re-examine the path -- advice that, given to a model whose arguments were truncated, sends it hunting for a mistake it did not make.

5. Somewhere to go

write_file only overwrote, so a file it could not finish in one call had no second move: continuing meant re-sending everything already written, which is the same oversized call that just got truncated. mode=append adds to the end, overwrite stays the default. An append with empty content is refused rather than treated as a no-op -- that is precisely what a call cut off before its content field looks like, and the one thing it must never silently become is an overwrite of the part already written.

The tool's description keeps its original wording and gains one line about the new parameter. An earlier draft had rewritten it around truncation -- how to split a long file, why an over-long call is lost -- but every caller of write_file reads that description and almost none are recovering from a cut-off turn. What only a truncated caller needs lives in truncation_hint, where only that caller sees it. A test asserts the description carries no truncation vocabulary, so the next scenario wanting something said to every caller has to argue for it.

6. A truncated call is not dispatched at all

This was originally left out of scope as "a call whose fields all validate still executes, writing a half-file". Running the branch showed the boundary is worse than that description: it is not only about incomplete content.

mode is optional on write_file. A cut landing before it arrives falls back to overwrite, which silently replaces everything an earlier append had written -- and reports success. The model asked to append, was told it worked, and the file is now the last chunk alone. Validation cannot see this: the call is well-formed. Only the fact that it was cut says the intent behind it is incomplete.

So the refusal moves ahead of validation and is keyed on truncation alone. Being wrong costs one retry; being right avoids a silent overwrite.

Also fixed on the way

• Three providers (azure, codex, minimax) kept max_tokens: int = 4096 in their own signatures. Harmless while the resolved value was always a number; a crash once it could be None, since chat_with_retry passes the resolved value explicitly and Azure took that None into max(1, max_tokens).
• The context-window lookup briefly lost its max_tokens fallback in this branch. The field reading behind that was right, the conclusion was not: six catalogue rows carry no max_input_tokens, and dropping them to the documented 65536 default over-estimates gemma-2's real 8192 window eightfold. Restored, with the reason stated as the bound it is -- a model's window is never smaller than what it is allowed to emit.

Type

• Fix
• Feature
• Docs
• CI / tooling
• Refactor
• Other

Verification

uv run pytest tests/
  6213 passed, 33 skipped, 1 failed

uv run ruff check raven/ tests/
  All checks passed!

uv run ruff format --check raven/ tests/
  819 files already formatted

The one failure is test_cli_theme::test_bold_accent_renders_styled_not_bare, pre-existing and unrelated: it fails identically on a clean base, and passes alone but fails when its file runs as a whole -- intra-file state leakage that predates this branch.

Live reproduction

The branch was run against a real backend (openrouter/anthropic/claude-sonnet-4-5) with the ceiling pinned low enough to force truncation, on the same task the original incident used. Same task, same ceiling, before and after:

	before	after
iterations	40 (hit the cap)	4
bytes written	0	6213
file parses	n/a	yes, 218 lines
model's closing line	"sorry, I hit a technical limit"	"done!"

The run before the fixes is the incident in miniature: forty turns of write_file({"path": "snake.py"}) with the content withheld, the model announcing at turn 5 that it would supply a field it had never omitted. The session record confirms every one of those forty calls carried exactly twenty characters of arguments, while the first eight were billed 1200 output tokens each -- the content was written, charged for, and dropped before it reached anything that stores it.

After: turn 1 is cut off, turn 2 says "I'll write this in two parts" and lands 2934 bytes with mode=overwrite, turn 3 appends 2935 more, turn 4 reports done.

Four defects came out of that run and would not have come out of review: the non-streaming path had no detection at all; three providers still hardcoded the old ceiling, one of them into a crash; the message told the model to withhold exactly what it needed to resend; and the generic advice did not fit tools with no smaller form.

It also exercised a design decision that had only been argued on paper. Turn 2 emitted two calls -- the first landed 2934 bytes, the second was cut off. Only the last call of a turn is marked, so the first executed normally. Marking every call would have rejected a write that succeeded.

Regression detection

This class of defect does not turn a suite red; it makes the suite unable to see the behaviour. For each change the implementation was reverted while keeping its tests, and the new cases were confirmed to fail before restoring it:

Change	Cases that go red without it
generation settings in chat_stream	3
finish_reason passthrough	3
truncation detection	3
truncation reporting	3
think-tag debris	2
namespaced / orphan think tags	2
flag out of the arguments dict	1
empty-append guard	1
nudge stops guessing	1
non-streaming detection (end to end)	1
chat_stream signature guard	1
per-tool recovery advice	1
truncated call refused before dispatch	6
parse failure kept per call	3
description stays free of one caller's concern	1
span carries the verdict / fallback ceiling	3
malformed arguments as their own failure class	1
a cut with no tool call is still logged	1

Two of those checks failed the first time and are worth naming, because both are ways a test can look thorough and verify nothing:

• Six unit cases around the truncation decision all stayed green when the non-streaming call site was deleted -- they tested the function, not that the path called it. An end-to-end case driving a real AgentLoop with no token callback is what actually fails.
• The provider-signature check first flagged 23 test doubles instead of shipped code, and the regression run that "confirmed" it had edited a different method than the one being asserted on.
• The same mistake recurred a third time on the cut-location signal: three cases called the decision function directly and all stayed green when the streaming call site stopped passing it. Two cases driving the real stream loop are what fail.
• The parse-failure signal was first added as a per-response boolean, which cannot say which call failed. Review caught it before it shipped as a wrong refusal, but only after it was pushed.

Assertions land on outgoing request bodies, returned messages, the serialized assistant message, and file contents on disk -- not on whether a call happened.

What an outside review found that self-checking did not

An automated review on the branch raised seven findings and all seven held up. Five share a shape: a change made here, its counterpart left alone.

• MiniMaxOAuthProvider.chat_stream still declared literal defaults for temperature and reasoning_effort -- the same shadowing this PR opens with, in the one signature where only max_tokens had been fixed, because that was the field this branch was about. A configured 0.1 went out as 0.7. The guard test had the same blind spot and now checks all three.
• failure_class did not know about [invalid arguments], a message this branch introduced after that classifier was written, so it shared the other bucket with every uncategorised error -- undoing the per-class streak keying for the newest failure shape.
• The truncation warning had been nested under "there is a tool call to mark", hiding a plain reply cut at the ceiling from the log.
• Two comment blocks stayed behind when their code moved to another module.

The other two are the span timing and the fallback ceiling described in section 2 -- both cases of adding code to a call chain without knowing what the rest of it does.

None of these were reachable by checking the diff, because the diff is where the change is and the damage was next to it.

Problems surfaced while building this

• _SENTINEL does not resolve across modules. It is a class attribute on base.py, so naming it directly in a subclass signature raises NameError at import. Qualified as LLMProvider._SENTINEL.

• Three existing tests broke, and the breakage was real. A subclass that never runs the base __init__ has no self.generation, and the base chat_stream fallback exists precisely for such thin implementations. Crashing there would be worse than the settings it restores, so generation is read defensively.

• The terminal chunk was being dropped. finish_reason rides only on the chunk carrying no content, no tool calls and no usage, which the emptiness check skipped. One existing assertion was split rather than loosened.

• The truncation flag was reaching the model. to_openai_tool_call serializes arguments into the assistant message, and the loop does that before the registry strips anything -- so a marker stored there was already fixed into history. Now covered by a test asserting on the serialized payload.

• One test's premise stopped existing. test_unknown_ceiling_does_not_flag_truncation pinned that signal 2 sits out when no ceiling is known. Every model now resolves to one, so the case was rewritten to pin what replaced it.

• Relevant tests pass locally

• Relevant lint / type checks pass locally

• User-facing docs or screenshots are updated when needed

Risk

Longer completions, higher per-turn cost. Streaming turns now honour temperature and reasoning effort, and every turn asks for the model's real output ceiling instead of 4096. On claude-sonnet-4 that is 64000 rather than 8192. This reaches installs that never configured anything.

agents.defaults.maxTokens is gone. A config still carrying it is ignored, not rejected, so nothing breaks and no file needs editing -- but a user who set a low value to cap cost will find it no longer has an effect. There is no replacement setting: the ceiling is a per-model fact now. Models the catalogue does not know keep 16384.

write_file gained a parameter. A tool schema is a contract the model reads; this one is additive, mode is optional and defaults to the existing behaviour.

A truncated tool call is no longer executed. Previously it ran whenever its required fields happened to have arrived. Callers that relied on partial execution -- there are none in this tree -- would see the call refused instead, with the model asked to resend it in pieces. The cost when the refusal is wrong is one retry.

Error text the model reads changed. Anything parsing tool errors by string match will see different wording on truncated calls.

registry.execute gained one keyword-only parameter with a default, so its four other call sites are unaffected. Truncation metadata rides beside the arguments rather than inside them, so it reaches neither the tool nor the assistant message. llm.truncated / llm.max_tokens are stamped on the span only when truncation is detected.

Rollback is a straight revert of the branch; nothing persists state and no data migration is involved.

• Security impact considered
• Backward compatibility considered
• Rollback path is clear for risky changes

Related Issues

N/A

[claude]

Claude finished @gloryfromca's task in 4m 1s —— View job

---

Review: no blockers; this can merge

All 7 findings from the earlier review passes on this PR have been addressed by the subsequent commits (2e1c285, 4da66a6, 00cfe9c, cbd7e5c):

• MiniMaxOAuthProvider.chat_stream now uses LLMProvider._SENTINEL defaults for max_tokens/temperature/reasoning_effort and forwards them unresolved (minimax_oauth_provider.py:59-61) — the config-shadowing bug is fixed, and the guard test (test_no_chat_stream_override_hardcodes_a_generation_setting) now checks all three fields on every shipped chat_stream, not just max_tokens.
• The non-streaming flag_truncation call moved inside chat_with_retry (providers/base.py:810-819), so it now runs before the @trace.instrument span closes (fixing the llm.truncated/llm.max_tokens span-attribute gap) and is keyed on current_model — the model that actually answered — rather than the originally-requested model, fixing the fallback-chain ceiling mismatch. Both are covered by new end-to-end tests (test_the_llm_call_span_records_a_truncated_non_streaming_turn, test_the_ceiling_comes_from_the_model_that_actually_answered).
• The stray dangling comments (think-tag block above _strip_inline_images in main.py, synthetic-image-message block in failure_streak.py) are gone.
• failure_class() now has its own "invalid_arguments" bucket for [invalid arguments] text (failure_streak.py:42-46), no longer falling into the generic "other" bucket.
• truncation.py's logger.warning now fires on if truncated: regardless of tool_calls (current providers/truncation.py:74-80), so a plain truncated text reply with no tool call is logged again.
• The stale registry.execute docstring was superseded by the 4da66a6 rewrite of the truncation flow; current wording no longer describes it as reinterpreting a validation failure.

I re-verified the fixes against their call sites rather than trusting the commit messages alone: checked that Azure/Codex providers don't override chat_stream at all (so they're not exposed to the same shadowing bug, unlike MiniMax's override), confirmed send_max_tokens is the single function used both to build the outgoing request and to judge truncation (no drift), and confirmed AgentDefaults has no extra="forbid" so a config still carrying the retired maxTokens key is genuinely ignored rather than rejected.

Did not find any new issues introduced by the latest commits (4da66a6, cbd7e5c, 00cfe9c, merge 0b218a5). The cut_inside_tool_call heuristic removal in 4da66a6 is an intentional, documented simplification (coarser guess, cheaper false-positive cost), not a regression.

Note: I could not execute uv run pytest in this environment (command required approval that wasn't available), so this review is based on static reading of the diff, implementation, and tests rather than a live run — the PR body's own verification section already reports the full suite passing with one pre-existing, unrelated failure.

[claude]

[blocker] This override reintroduces exactly the shadowing bug this PR fixes elsewhere. AgentLoop calls self.provider.chat_stream(messages, tools, model) with no temperature/reasoning_effort, so this override's own literal defaults (temperature: float = 0.7, reasoning_effort: str | None = None at lines 57-58) win and get forwarded as concrete positional args to super().chat_stream(...) (LiteLLMProvider.chat_stream, litellm_provider.py) at lines 62-64.

LiteLLMProvider.chat_stream only falls back to self.generation.temperature / self.generation.reasoning_effort when it receives LLMProvider._SENTINEL (litellm_provider.py:513-519). Since this override always passes a concrete value (never the sentinel), that fallback path is dead for every MiniMax OAuth streaming call — a user-configured temperature/reasoning_effort is silently ignored, the same failure mode as §1 of the PR description.

max_tokens here happens to still work only because LiteLLMProvider.chat_stream has an additional if max_tokens is None: max_tokens = send_max_tokens(...) check that isn't sentinel-gated — temperature/reasoning_effort have no equivalent fallback.

Fix: give this override the same object = LLMProvider._SENTINEL defaults used in litellm_provider.py/base.py, and forward them unresolved so the parent resolves against self.generation. The same shadowing exists in chat() above, though it's masked there because chat_with_retry always resolves settings before calling chat() directly — chat_stream has no such wrapper.

No test in tests/test_minimax_oauth.py or tests/test_litellm_provider_stream.py exercises this override's defaults, so the new regression suite doesn't catch it.

[claude]

[nit] This comment block (opening/closing reasoning tag, vendor namespace prefixes) describes the think-tag regex logic that actually lives in recovery.py (_THINK_TAG_RE, strip_think_blocks) — it's dangling here above _strip_inline_images, an unrelated image-stripping helper. Looks like a stray leftover from moving that logic into recovery.py; safe to delete.

[claude]

[blocker] This flag_truncation call (and the whole point of the last commit, "record the sent ceiling on non-streaming responses too") runs after chat_with_retry has already returned — but chat_with_retry is itself wrapped in @trace.instrument("llm.call", extract=semconv.llm_call) (raven/providers/base.py:724). trace.instrument's awrapper runs _close/extract in a finally block and closes the span via the with span(...) context manager before returning control to the caller (raven/tracing/trace.py:367-385). semconv.llm_call builds attrs = llm_attrs(result, ...) synchronously off the result object at that point (raven/tracing/semconv.py:623), reading getattr(resp, "truncated", False) / getattr(resp, "max_tokens", None) — both still the defaults (False / None) since this mutation hasn't happened yet.

So on this whole branch (raven agent CLI, sub-agents that would use it, anything with no token callback), response.max_tokens/response.truncated are set here for downstream use in the loop (correctly — the tool-facing [truncated] error message still works because it reads tool_calls[-1].run_meta, mutated on the same objects), but the llm.call trace span for that request will always record llm.truncated as absent and never gets llm.max_tokens — contradicting this commit's stated goal and the PR's own risk section ("llm.truncated / llm.max_tokens are stamped on the span only when truncation is detected"). No test asserts on the span attributes for this path, which is why it wasn't caught (compare to the streaming path, where flag_truncation runs inside _llm_call_stream before that function — also @trace.instrument-wrapped — returns, so its span is correct).

Fix: either call flag_truncation before chat_with_retry returns (not possible without changing that method), or move the instrumentation point / re-emit the attribute after the fact, or accept and document that non-streaming truncation tracing is a known gap.

[claude]

[nit] Stale docstring after this commit. It still says run_meta "changes what a validation failure means," but the refusal now happens at line 79, before cast_params/validate_params ever run (lines 85-90) — a truncated call is refused unconditionally, regardless of whether it would have validated. Worth updating to say it preempts dispatch rather than reinterprets a validation error.

Fix this →

[claude]

[nit] This comment block (synthetic image-message rationale, _recovery_synthetic vs. attached-image key) describes _ATTACHED_IMAGE_KEY, which lives in raven/agent/loop/main.py:185 — it has nothing to do with is_hard_tool_failure below it. Looks like leftover residue from the 24da3e4 refactor(agent): move loop helpers out of main.py extraction (same class of issue already flagged on main.py:191 for the think-tag comment). Safe to delete.

Fix this →

[claude]

[blocker] flag_truncation is called here with model=call_model — the model this turn was requested under — but the response it is judging may have come from a different model. chat_with_retry (raven/providers/base.py:741-818) walks [model, *fallback_models] and returns as soon as some model in that chain answers without finish_reason == "error"; LLMResponse has no field recording which model in the chain actually produced it (confirmed — no response.model/served_model anywhere in base.py). fallback_models is a live feature here (wired from self.router.select_model_chain(content) at main.py:2676), so when the primary model errors and a fallback actually serves the turn, send_max_tokens(generation, call_model) inside flag_truncation resolves the primary's ceiling, not the ceiling that request actually carried.

Concretely: if the fallback's real output ceiling is much larger than the primary's (typical — that's often why it's a fallback, e.g. a different vendor), a normal-length completed tool call can have output_tokens >= sent_max_tokens against the wrong (too-small) ceiling → false positive → a complete call gets refused as [truncated]. If the fallback's ceiling is smaller than the primary's, a genuine cut-off is compared against a too-large ceiling → false negative → silently missed truncation, which is the exact incident this PR exists to prevent.

The streaming path (_llm_call_stream) doesn't have this gap since it never goes through the fallback chain. Fix: have chat_with_retry/_chat_attempt_with_retry record which model in the chain actually produced the response (e.g. a field on LLMResponse) and pass that into flag_truncation here instead of call_model.

Fix this →

[claude]

[nit] failure_class has no case for the [invalid arguments] error text that ToolRegistry.execute now returns for a call whose JSON failed to parse (raven/agent/tools/registry.py, the run_meta.arguments_repaired branch added in commit d27016a, after this file was written in 24da3e4). It falls through to "other", the same bucket as every unrelated uncategorized error.

That defeats the point of this file: the (tool, failure_class) streak key exists so "a truncation, then a schema error, then a missing path" reads as adapting, not stuck (per the PR description). A repeated [invalid arguments] failure interleaved with a genuinely different "other" failure will now be counted as the same failure class, which is the exact conflation the per-class keying was built to avoid.

[Fix this →](https://claude.ai/code?q=In%20raven%2Fagent%2Floop%2Ffailure_streak.py%2C%20add%20a%20case%20to%20failure_class()%20%28around%20line%2040-45%29%20for%20the%20%22%5Binvalid%20arguments%5D%22%20error%20text%20that%20ToolRegistry.execute%20returns%20in%20raven%2Fagent%2Ftools%2Fregistry.py%20when%20run_meta.arguments_repaired%20is%20set%20%28introduced%20in%20commit%20d27016a%29.%20Currently%20it%20falls%20through%20to%20the%20generic%20%22other%22%20bucket%20instead%20of%20getting%20its%20own%20class%20like%20%22truncated%22%2F%22schema%22%2C%20so%20it%20gets%20conflated%20with%20unrelated%20failures%20in%20the%20%28tool%2C%20failure_class%29%20loop-break%20streak.%20Add%20e.g.%20%60if%20%22invalid%20arguments%22%20in%20low%3A%20return%20%22invalid_arguments%22%60%20before%20the%20final%20fallback.&repo=EverMind-AI/Raven

[claude]

[nit] The logger.warning call moved inside if truncated and tool_calls: in the latest commit (4da66a6); before that (d27016a) it fired whenever truncated was True, independent of tool_calls. A turn that hits finish_reason == "length" or the ceiling with no tool calls at all (a plain truncated text reply) still returns truncated=True — which still reaches response.truncated for the llm.truncated trace attribute in semconv.py — but this warning is now silently skipped for that shape, making truncated non-tool-call turns invisible in the logs.

[Fix this →](https://claude.ai/code?q=In%20raven%2Fagent%2Floop%2Ftruncation.py%2C%20flag_truncation%28%29%20around%20lines%2058-69%3A%20the%20logger.warning%20call%20is%20nested%20inside%20%22if%20truncated%20and%20tool_calls%3A%22%2C%20so%20a%20truncated%20turn%20with%20no%20tool%20calls%20%28plain%20text%20cut%20off%20at%20the%20ceiling%29%20never%20logs%20a%20warning%2C%20even%20though%20truncated%3DTrue%20is%20still%20returned%20and%20recorded%20on%20response.truncated%20for%20tracing.%20Move%20the%20logger.warning%20call%20back%20out%20so%20it%20runs%20on%20%22if%20truncated%3A%22%20regardless%20of%20whether%20there%20are%20tool_calls.&repo=EverMind-AI/Raven