Letta Agent Repetition and max_tokens_exceeded

A Letta agent that repeats the same phrase until max_tokens_exceeded has reached an output limit without ending the turn normally. The stop reason describes how the response ended. It does not identify why the response became repetitive.

When the repetition exists inside one persisted assistant message, the model or provider generation path is the leading explanation. The model may have entered a self-reinforcing pattern or may be unreliable for that agentic workload. Similar-looking symptoms can also come from duplicate requests, repeated tool calls, stream replay, or duplicate channel delivery. Check which event actually repeated before assigning blame. Reliable Agent Systems places these symptoms within the wider path from model output to external effect.

Stop the immediate loop

Use this recovery sequence:

1. Stop or cancel the active turn.
2. Tell the agent: “You are repeating the same phrase. State the conclusion once, take one concrete next action, or finish.”
3. Use /model to retry with a model known to perform well on agentic and tool-use tasks.
4. If the repeated passage now occupies much of the active context, use /new for a clean conversation with the same agent. Use /compact all when preserving the thread through a generated summary is more important than obtaining a clean comparison.

Do not raise the output limit while the model is producing meaningless repetition. A larger allowance usually buys a longer loop. Increasing the limit makes sense only when the response remains coherent, keeps making progress, and is clearly truncated.

For repeated tool calls, stop after two or three identical calls that produce no progress. Require approval for consequential tools during diagnosis so a loop cannot repeatedly modify files, spend money, or send messages.

Read the stop reason narrowly

In Letta Code's local provider-executor path, an upstream completion reason of length becomes max_tokens_exceeded. The interactive client's retry classifier treats that stop reason as non-retriable. These implementation details are visible in the versioned provider executor and retry classifier.

The stop reason establishes that a length limit ended the response. It does not establish whether:

• the model entered a repetition loop;
• the model produced a useful but unfinished answer;
• the configured output budget was too small;
• context pressure reduced the available output allowance;
• an OpenAI-compatible provider used length for a different upstream limit; or
• the effective model, provider, or reasoning settings differed from the user's expectation.

A tiny output followed by max_tokens_exceeded deserves provider and settings inspection. A long response that repeats one sentence hundreds of times is a different incident.

Output shape	Leading interpretation	First response
One phrase repeats without informational progress	Generation degeneration or failed termination	Stop, correct once, and test a stronger model
The answer remains coherent but ends mid-thought	Output or reasoning budget may be insufficient	Split the task or inspect the effective output limit
Only a few tokens appear before the stop reason	Provider, gateway, or limit metadata may be wrong	Inspect finish reason, usage, and effective settings
The interface shows copies, but history contains one message	Presentation or stream replay	Collect interface, transcript, run, and stream evidence

Why a model can repeat

Language models generate each token from the preceding context. Research on neural text degeneration has shown that some model and decoding combinations can enter repetitive patterns. Once a phrase appears several times in the context, the continuation can make another copy increasingly likely. The papers The Curious Case of Neural Text Degeneration and Learning to Break the Loop describe this class of failure. They provide a plausible mechanism, not a diagnosis of every production incident.

An agent asks more of a model than ordinary chat. The model must interpret system instructions and memory, choose tools, format arguments, understand tool results, track completion, and decide when to stop. A model can write fluent prose while performing this control task poorly.

Letta's model guide recommends a large frontier model for first-time users because weaker models can produce unexpected agent behavior. Model size alone does not settle the issue. Training, quantization, prompt formatting, reasoning mode, decoding settings, provider implementation, and tool schemas can all affect reliability.

One common failure is continued narration after the task has ended. The model may repeatedly say “wait,” “stay quiet,” or “I should stop” without actually ending the response. A sentence about stopping is still generated text, not a mechanical stop signal. Explicit completion criteria help:

Once the requested result is verified, report it once and finish. Do not repeat a successful no-op check.

Classify the repeated event

Repetition inside one assistant message

One run and one persisted assistant message contain the repeated text. The canonical transcript and stream deltas show the same repetition, with no extra user submissions or runs.

Model generation, provider decoding, and the supplied context remain the leading hypotheses. Switch models and repeat the test in a fresh conversation before making a stronger attribution.

Repeated tool calls

The agent calls the same tool with the same arguments and receives the same result repeatedly. Ask whether request N included the tool result from request N−1.

If the prior result is present, investigate model control, unclear completion criteria, and tool-result semantics. If the prior result is absent, investigate result persistence, continuation state, and request construction.

Duplicate inference or input dispatch

One human action creates multiple user messages, runs, assistant message IDs, or provider requests. This points toward client resubmission, ingress duplication, retry or idempotency failure, or multiple active runtimes.

Preserve the identifiers before restarting anything. Duplicate inference can duplicate external effects and provider charges.

Interface or stream replay

The interface renders several copies while authoritative history contains one message, run, or tool execution. This points toward presentation, reconnect, stream accumulation, or history reconciliation. Repeated cards alone do not prove repeated inference.

Duplicate channel delivery

An external destination contains multiple delivered messages. Count destination message IDs. Possible causes include repeated model-issued send calls, duplicate ingress, multiple listeners for one bot account, or adapter delivery behavior.

Run a small diagnostic comparison

Use benign prompts with no external effects.

Test	Result	What it suggests
Same conversation, stronger model	Loop disappears	The original model, provider, or configuration path is implicated
New conversation, same model	Loop disappears	The prior conversation context contributed
New conversation, stronger model	Loop remains	Inspect shared instructions, memory, tool contracts, provider behavior, and runtime evidence
Transcript has one message while the interface shows many	Presentation or replay problem	Collect client and stream evidence
One user action creates several runs	Duplicate dispatch	Preserve run and request identifiers
Prior tool result is present, but the model repeats the call	Control, instruction, tool semantics, or completion failure	Stop, simplify, and switch models
Prior tool result is absent from the next request	Continuation or request-construction failure	Report a minimal trace

A cross-model comparison narrows the search but does not prove that the harness caused the problem. Different models can continue the same contaminated context or follow the same problematic instruction.

Reduce the workload during diagnosis

Use one concrete objective, one success condition, and one stopping condition. Reduce the number of tools, summarize large tool results, and split long work into bounded stages. For local or custom providers, verify that the endpoint supports Chat Completions and tool calling as required by the current model guide.

The current CLI provides the following controls:

• /model switches the model and applicable reasoning settings.
• /context shows context-window usage.
• /compact all summarizes the current conversation history.
• /new starts a new conversation with the current agent.
• /clear clears in-context messages.
• /fork branches with the current conversation history, so it is unsuitable for a clean-context comparison.

The slash-command reference is the current source for command behavior.

Report evidence when the symptom points beyond generation

Use the Letta Code issue tracker when the evidence shows duplicate runs, inconsistent persistence, replay, or cross-provider reproduction. Include:

1. The exact model handle and provider path.
2. The Letta surface and version: app, CLI, web, Agent SDK, API, or Channel.
3. The runtime location: local, cloud, or connected computer.
4. Whether repetition occurred inside one message, across runs, across tool calls, only in the interface, or at the external destination.
5. A short canonical transcript excerpt with roles preserved.
6. Run, message, and tool-call identifiers when available.
7. Output-token usage, reasoning setting, context usage, and nearby compaction.
8. A sanitized upstream finish reason and usage summary when you control the provider.
9. The stronger-model comparison.
10. The fresh-conversation comparison.

Never include API keys, authorization headers, signed URLs, cookies, pairing codes, or unreviewed provider request bodies. Preserve one minimal, sanitized example before clearing or compacting the conversation.

Evidence should change the diagnosis. One repeated assistant message starts with generation and context. Multiple runs start with dispatch. One run rendered several times starts with the client. One intended send delivered several times starts with tool calls, listeners, and the destination receipt chain. The screenshot alone cannot make those distinctions.