PATCH /v3/settings: filterPrompt is accepted but stored and returned empty (shouldLLMFilter persists) #1698

Summary

PATCH /v3/settings accepts a filterPrompt but it is not stored. The response's updated.filterPrompt comes back empty, and a following GET /v3/settings also returns an empty filterPrompt. shouldLLMFilter: true in the same request is stored, so the org ends up with LLM filtering enabled and no filter instructions.

Steps to reproduce

1. PATCH https://api.supermemory.ai/v3/settings with a JSON body such as:

   { "shouldLLMFilter": true, "filterPrompt": "<plain-English instructions, ~450 characters, no special characters beyond punctuation>" }

2. Inspect the response.
3. GET https://api.supermemory.ai/v3/settings.

Sending filterPrompt on its own (without shouldLLMFilter) behaves the same way.

Expected

updated.filterPrompt and the subsequent GET return the submitted prompt, as in the examples in the Customization and Update settings docs.

Actual

• The PATCH returns 200 with orgId, orgSlug and updated, where updated.shouldLLMFilter is true and updated.filterPrompt is an empty string.
• The GET returns shouldLLMFilter: true and an empty filterPrompt.
• There is no error or validation message explaining why the prompt was dropped.

Questions

• Is filterPrompt restricted by plan tier, length, or some other precondition that isn't documented? If so, could the API return an error rather than silently dropping it?
• With shouldLLMFilter: true and an empty prompt, what does the filter do: pass everything, or apply a default?

Environment

• REST API called directly (Python, JSON body, bearer API key), 2026-09-23.
• Reproduced twice, with identical results.