Unicode characters appear double-escaped in system_alert.message from summarization

[tylerstraub]

When summaries are returned in system_alert messages via the /summarize endpoint, Unicode characters (especially emoji) appear double-escaped in the API response. After JSON parsing on the client, sequences like \ud83d\udcdd remain as literal strings instead of being decoded to actual characters.

Steps to reproduce

1. Call POST /v1/agents/{agent_id}/summarize with compaction settings
2. Fetch messages via GET /v1/agents/{agent_id}/messages
3. Locate the user_message with system_alert in its content field
4. Parse the JSON-encoded content string
5. Observe that parsed.message contains Unicode escape sequences like \ud83d\udcdd instead of decoded characters

Expected behavior

The system_alert.message field should contain properly decoded Unicode characters (e.g., emoji) that display correctly without additional client-side decoding.

Actual behavior

The system_alert.message field contains escaped Unicode sequences that require client-side workarounds to decode properly.

Example

Raw API response (from GET /v1/agents/{id}/messages):

{
  "message_type": "user_message",
  "content": "{\"type\":\"system_alert\",\"message\":\"Note: prior messages...\\\\ud83d\\\\udcdd...\",\"time\":\"2025-12-22 08:03:58 AM UTC+0000\"}"
}

After client-side JSON.parse(content), the parsed.message still contains:

"...\\ud83d\\udcdd..."

Instead of the actual emoji character.

Please describe your setup

• How are you running Letta?
  • Docker
• Describe your setup
  • OS: Linux (WSL2)
  • Running via Docker container (self-hosted instance)
  • Accessing via reverse proxy that forwards /api/* requests to Letta

Additional context

• Model being used: openai-proxy/glm-4.7-coding-preview-atlas (via LiteLLM proxy)
• The double-escaping occurs in Letta's API response before any client processing
• Client-side code only performs standard response.json() and JSON.parse() - no custom encoding/decoding
• This affects any summary content that contains Unicode characters (emojis, special symbols, etc.)
• We've implemented a client-side workaround to decode these sequences, but this should be fixed server-side

Evidence

The escaping pattern (\\\\ud83d in raw JSON string, \\ud83d after standard JSON parsing) is present in the raw API response from GET /v1/agents/{agent_id}/messages, confirming this is a server-side encoding issue rather than client-side processing.

Workaround

Currently decoding Unicode escape sequences client-side after parsing the system_alert JSON, but a server-side fix would be preferable to ensure proper Unicode handling throughout the API.

[tylerstraub]

Hmm, there seems to be a lot more buggy interactions after I sorted out the escaping pattern issue here. Maybe there is a much deeper issue going on with my configuration. Will continue to investigate.

[tylerstraub]

Yeah I'm seeing cascade failures with compaction on OSS through the OpenAI proxy. Full context: https://discord.com/channels/1161736243340640419/1452573762250739763