Embedding calls crash with 400 when stored memory exceeds model context window

[PaoloC68]

Description

When Agent Zero stores or searches memory documents that exceed the embedding model's context window (e.g. BAAI/bge-m3: 8192 tokens), the embedding call crashes with a 400 error:

```
litellm.BadRequestError: Error code: 400 - You passed 8193 input tokens and requested 0 output tokens.
However, the model's context length is only 8192 tokens.
```

This is a hard crash — the agent errors out and memory operations fail completely.

Root Cause

Two separate issues in LiteLLMEmbeddingWrapper:

Issue 1: LiteLLM ≥1.80.11 sends encoding_format: null in embedding requests when the parameter is not set. Strict OpenAI-compatible validators (DeepInfra, vLLM, HuggingFace TEI) reject null with 422. (Upstream LiteLLM issue: BerriAI/litellm#19174)

Issue 2: There is no input truncation before embedding calls. If a memory document exceeds the model's context window, the API returns 400. Additionally, when truncation is applied using cl100k_base (GPT tokenizer), it can undercount tokens compared to the model's own tokenizer (e.g. bge-m3 SentencePiece), causing 400 errors even at the apparent limit.

Steps to Reproduce

1. Configure an OpenAI-compatible embedding provider via api_base (e.g. DeepInfra with BAAI/bge-m3)
2. Ask the agent to memorize or search a long document (>8192 tokens)
3. The embedding call raises BadRequestError: 400

Fix

In models.py, LiteLLMEmbeddingWrapper.embed_documents and embed_query:

1. Default encoding_format to "float" before merging kwargs (prevents null being sent)
2. Truncate input to ctx_length - 500 tokens before embedding (the 500-token margin accounts for tokenizer divergence between cl100k_base used for counting and the model's actual tokenizer)

PR: #PLACEHOLDER

[PaoloC68]

Root cause found

The trigger is in plugins/_memory/extensions/python/message_loop_prompts_after/_50_recall_memories.py.

When memory_recall_query_prep: false (the default in default_config.yaml), the fallback query is:

query = user_instruction + "\n\n" + history[-memory_recall_history_len:]

With memory_recall_history_len: 10000 (also the default), this produces a query of up to 10,000 characters. At high content density (~1 char/token for code or CJK text), this exceeds the 8,192-token context window of BAAI/bge-m3.

Additionally, the loop-halving retry in models.py was silently bypassed because the condition "input_tokens" in str(e) did not reliably match the litellm.BadRequestError string representation across versions.

Two additional fixes (included in PR #1437)

1. plugins/_memory/extensions/python/message_loop_prompts_after/_50_recall_memories.py — cap fallback query at 4,000 characters. Semantic similarity search does not need 10,000 characters of raw history; 4,000 is ~1,000 tokens for any content type and sufficient for retrieval quality.

query = (user_instruction + "\n\n" + history)[:4000]

2. models.py — replace brittle "input_tokens" in str(e) string check with getattr(e, "status_code", None) == 400, which reliably identifies context-length errors regardless of litellm version or message formatting.

[GoliathDeveloper]

Same here:
litellm.exceptions.ContextWindowExceededError: litellm.ContextWindowExceededError: litellm.BadRequestError: ContextWindowExceededError: OpenAIException - This model's maximum context length is 130000 tokens. However, you requested 0 output tokens and your prompt contains at least 130001 input tokens, for a total of at least 130001 tokens. Please reduce the length of the input prompt or the number of requested output tokens. (parameter=input_tokens, value=130001)