Related Pages

Related topics: LLM Provider Integration & Compatibility, Hierarchical Memory & Data Layer, Agents, Tools & Sandbox Execution

Project Overview & System Architecture

Letta is an open-source framework (Apache-2.0, ex-MemGPT) for building and serving stateful agents with hierarchical long-term memory. The codebase is delivered as a single Python package that bundles a CLI, a FastAPI-based server, provider adapters for many LLM backends, a tool execution sandbox, and a persistent storage layer. The current release line is v0.16.8 (see CHANGELOG) and the project tracks a stable 1.0 API surface described in README.md Source: README.md:1-120.

Purpose and Scope

Letta's purpose is to give agents a durable, inspectable memory substrate rather than relying on the chat completion window alone. According to the project README, Letta exposes agents with memory blocks (core, archival, recall) and a set of file-like primitives such as memory_insert and memory_replace that the agent can call on itself Source: README.md:30-90. The framework targets three audiences:

• Developers integrating agents into Python applications via the letta package and the letta-python client.
• Operators who run the bundled server and interact through the REST API.
• Researchers and contributors extending the provider, tool, or memory subsystems.

The scope explicitly excludes being a model provider; Letta delegates inference to OpenAI, Azure, Anthropic, Bedrock, vLLM, LM Studio, GLM/z.ai, and other OpenAI-compatible endpoints, with a uniform interface defined in letta/llm_api/ Source: letta/llm_api/__init__.py:1-40.

High-Level Architecture

The system is organized as four cooperating layers, entered through a single CLI dispatcher.

The CLI is the single user-facing entry: letta/main.py instantiates a Typer/argparse tree and delegates to either the local runner or the server launcher Source: letta/main.py:1-80.

Agent Runtime and Memory Model

At the heart of the system is agent_loop.py, which implements the turn-by-turn cycle that lets an agent reason, invoke tools, and persist state. The loop is responsible for assembling the system prompt from hierarchical memory blocks, calling the configured provider, parsing tool calls, and writing tool results back into memory before the next iteration Source: letta/agents/agent_loop.py:1-150.

Memory is split into three tiers, as described in community evaluations:

• Core memory: always-in-context blocks edited via memory_replace / memory_insert.
• Archival memory: long-form searchable storage (vector + keyword hybrid).
• Recall memory: episodic log of past messages and tool invocations.

This three-tier design is what differentiates Letta from stateless chat-completion wrappers and is the main reason community integrators (e.g. issue #3389) adopt it as a substrate for external agents Source: README.md:60-110.

Server, REST API, and Sandboxing

The server layer wraps the agent runtime behind a stable HTTP surface. letta/server/server.py defines the FastAPI app, lifespan management, and dependency wiring, while letta/server/rest_api/app.py mounts routers for agents, tools, memory, sources, and streaming chat completions Source: letta/server/server.py:1-120Source: letta/server/rest_api/app.py:1-160.

Because custom tools execute untrusted code, Letta runs them in an isolated sandbox that:

1. Parses the tool's args_json_schema and compiles it into a Pydantic model (the DynamicModel path).
2. Executes the tool function in a subprocess/separate process.
3. Returns the result as JSON to the server over a non-pickle transport (security hardening landed in v0.16.8, PR #3343) Source: letta/sandbox/tool_sandbox.py:1-200.

A known fragility in this path is documented in issue #3319: when args_json_schema lacks a title field, the sandbox raises NameError: name 'DynamicModel' is not defined because two code paths default to different class names. This is representative of the broader class of bugs the community files against the provider and sandbox boundary.

Provider Layer and Cross-Cutting Concerns

The provider layer (letta/llm_api/) normalizes streaming chat completions, model discovery, and error mapping across backends. Each provider subclass implements list_models, request, and stream, and the server selects one based on the agent's configured handle. Recent community reports (#3385, #3386, #3384, #3383, #3382, #3381, #3380, #3379) cluster around provider robustness: ignoring encrypted credentials (Bedrock, vLLM), crashes on missing fields (max_model_len), wrong base URLs (/api/v0 for LM Studio), HTTP-error swallowing, and 500 responses on empty message arrays. These are routed through the same provider base class, which is why a single architectural fix (e.g. honoring encrypted keys everywhere) covers many tickets.

Cross-cutting, project-wide conventions are captured in AGENTS.md, which documents contribution rules, the modular provider contract, and the testing layout (unit, integration, sandbox). It is the canonical entry point for new contributors and complements README.md Source: AGENTS.md:1-80.

Operational Modes

Letta supports two principal operating modes:

1. Hosted server mode — letta server boots server.py, exposes REST/WebSocket endpoints, persists to PostgreSQL/SQLite, and can run tool sandboxes out-of-process.
2. Local/embedded mode — letta run instantiates agent_loop.py directly inside a Python process for notebook or script use, sharing the same provider and memory stack.

Both modes share the agent loop and memory model; only the transport differs, which keeps client SDKs (letta-python) and the web frontend pointing at the same logical surface Source: letta/main.py:80-160.

Known Architectural Limitations

The architecture intentionally centralizes error handling in a thin wrapper per provider, which produces provider-name leakage bugs (issue #3310: non-OpenAI rate limits mislabeled as Rate limited by OpenAI). Security-sensitive areas — tool sandbox transport, encrypted credential handling, cross-session isolation (issue #3388) — have seen the most active recent fixes and remain the highest-leverage areas for contributors.

Related Pages

Related topics: Project Overview & System Architecture, Agents, Tools & Sandbox Execution

LLM Provider Integration & Compatibility

Purpose and Scope

Letta supports many LLM backends through a unified provider abstraction. The integration layer lives in letta/llm_api/, where each vendor exposes a thin client that conforms to a shared interface for chat completions, streaming, and tool calling. A central dispatcher in letta/llm_api/llm_client.py routes requests to the correct client based on the agent's configured LLMConfig, while provider metadata and credentials are normalized in letta/schemas/providers.py and letta/schemas/llm_config.py.

The compatibility strategy is twofold:

1. Native SDK clients for first-class providers (OpenAI, Anthropic, Bedrock, Azure, Google AI, Groq, Together).
2. OpenAI-compatible shims that reuse the OpenAI SDK against an arbitrary base_url for self-hosted and proxy backends (vLLM, LM Studio, Ollama, SGLang, z.ai/GLM-5, and other OpenAI-protocol-compatible services).

This layered approach keeps the agent runtime agnostic to vendor-specific protocol details, but it also concentrates risk in the OpenAI-compatibility path, where every non-OpenAI upstream inherits OpenAI's assumptions.

Provider Matrix

The table below summarizes the major integrations found in letta/llm_api/. It is derived from the per-provider client modules and the LLMConfig enum entries in letta/schemas/llm_config.py.

Source: letta/llm_api/llm_client.py and letta/schemas/providers.py:1-120.

Request Flow and Routing

The dispatcher in letta/llm_api/llm_client.py selects the client by inspecting LLMConfig.model_endpoint_type (or the provider handle). It then constructs the appropriate provider-specific request object, invokes the SDK, and converts the response back into Letta's internal AssistantMessage, ToolCall, and UsageStatistics schemas.

flowchart LR
    A[Agent Loop] --> B[llm_client.py dispatcher]
    B -->|LLMConfig| C{Endpoint type}
    C -->|openai| D[openai_client.py]
    C -->|anthropic| E[anthropic_client.py]
    C -->|bedrock| F[bedrock_client.py]
    C -->|azure| G[azure_client.py]
    C -->|zai| D
    C -->|vllm| D
    C -->|lmstudio| D
    C -->|sglang_native| H[sglang_native_client.py]
    D --> I[error_utils.py]
    E --> I
    F --> I
    G --> I
    H --> I
    I --> J[Normalized Letta error]

Because several providers delegate to the OpenAI client, the request flow can route *OpenAI-compatible* traffic through one client implementation while still preserving per-provider endpoint configuration. Source: letta/llm_api/llm_client.py:1-200.

Error Normalization and Compatibility Edge Cases

letta/llm_api/error_utils.py translates raw SDK exceptions into Letta's typed errors (LLMError, LLMRateLimitError, LLMContextWindowExceededError, etc.). This is where most cross-provider edge cases surface.

Known community-reported issues mapped to this layer include:

• Hardcoded provider name in rate-limit messages — the llm_rate_limit error wrapper text is hardcoded to "Rate limited by OpenAI" even when the upstream is z.ai/GLM-5 or another OpenAI-compatible service. Source: letta/llm_api/error_utils.py:1-180 and issue #3310.
• Bedrock encrypted credentials ignored — encrypted AWS keys are not decrypted before use, causing silent auth failures. Source: letta/llm_api/bedrock_client.py:1-160 and issue #3386.
• vLLM model discovery — encrypted keys and a missing max_model_len field both cause crashes during /v1/models enumeration. Sources: letta/llm_api/vllm_client.py with issues #3384 and #3385.
• LM Studio endpoint and wrapper — /api/v0 is persisted as the inference endpoint, and the chat-completions wrapper both hides HTTP failures and mutates the caller's message list in place. Source: letta/llm_api/lmstudio_client.py and issues #3382, #3383.
• OpenAI-compatible agent endpoint returns 500 on empty messages — input validation is deferred to the upstream and surfaced as an opaque 500. Source: letta/llm_api/openai_client.py:1-220 and issue #3381.
• Local LLM completion settings mutated across requests — shared mutable state in the local-provider path leaks between concurrent calls. Source: letta/llm_api/llm_client.py:200-400 and issue #3379.
• Azure model listing regression — historical breakage in dropdown population after setting AZURE_API_KEY/AZURE_BASE_URL. Source: letta/llm_api/azure_client.py:1-200 and issue #2582.

Extending Provider Support

To add a new OpenAI-compatible backend, the convention is to create a client module under letta/llm_api/ that subclasses or composes the existing OpenAI client, register a new LLMConfig enum value in letta/schemas/llm_config.py, and add a dispatcher branch in letta/llm_api/llm_client.py. For native (non-OpenAI) protocols such as SGLang's, the pattern in letta/llm_api/sglang_native_client.py shows the alternative: a standalone client that performs its own request/response translation before reusing the shared error-handling pipeline in letta/llm_api/error_utils.py. Source: letta/llm_api/sglang_native_client.py:1-160 and letta/schemas/llm_config.py:1-220.

In all cases, error normalization must be updated alongside the client so that downstream consumers see consistent error semantics regardless of the underlying provider.

Related Pages

Related topics: Project Overview & System Architecture, Agents, Tools & Sandbox Execution

Hierarchical Memory & Data Layer

Letta (ex-MemGPT) organizes an agent's persistent state into a three-tier hierarchy: *core memory* (in-context editable blocks), *archival memory* (unbounded, searchable passages), and *recall memory* (append-only conversation history). This layered design lets the model mutate short-term working context while still retrieving from long-term storage, and is exposed through file-like primitives (memory_insert, memory_replace, memory_rethink) that abstract the underlying SQL tables.

1. Core Memory (Blocks)

Core memory is the working scratchpad always attached to the agent's context window. It is decomposed into named Blocks — small text fields the LLM can read and edit in place.

• The Pydantic schema Block (in letta/schemas/block.py) defines fields such as label, value, limit, description, and metadata. A block's value is bounded by limit (character cap), and a read_only flag prevents mutation. Source: letta/schemas/block.py:1-120.
• A Memory aggregate (letta/schemas/memory.py) bundles a list of blocks per agent and tracks the total character usage against a global context-window budget, producing a compact (label, value) view that is rendered into the LLM's system prompt. Source: letta/schemas/memory.py:1-90.
• Block edits are applied through MemoryManager in letta/services/memory_manager.py, which validates limits, enforces that a block named human/persona cannot be removed, and rewrites the agent's memory column atomically. Source: letta/services/memory_manager.py:120-260.

Community issue #3388 ("Cross-Session State Leakage via Persistent Core Memory Poisoning") highlights the security implications of this design: because core memory persists across sandbox invocations, a compromised tool that mutates a block can poison every subsequent session for that agent.

2. Archival Memory (Passages)

Archival memory is an append-only, vector-indexed store of free-form text fragments. It is unbounded in size and acts as the agent's long-term knowledge base.

• A Passage schema (letta/schemas/passage.py) carries text, an optional embedding vector, an agent/owner identifier, and creation metadata. Source: letta/schemas/passage.py:1-80.
• PassageManager (letta/services/passage_manager.py) handles inserts, deletes, and similarity search. Inserts persist rows and, when an embedding config is attached, upsert them into the configured vector backend (pgvector or external providers). Source: letta/services/passage_manager.py:60-180.
• The file-like API maps to passage operations: memory_insert appends a new passage, memory_replace rewrites matching text, and memory_rethink re-asks the LLM to consolidate or rewrite a passage.

3. Recall Memory (Conversations)

Recall memory captures the full chronological message log between user and agent. It is *not* in the prompt by default; the LLM requests windows of it on demand.

• Conversation and Message schemas live in letta/schemas/conversation.py, where each message carries a role, content, and tool-call trace metadata. Source: letta/schemas/conversation.py:1-110.
• ConversationManager (letta/services/conversation_manager.py) appends messages, retrieves paginated windows by ID or token budget, and supports soft-deletion of tool-result pairs for context pruning. Source: letta/services/conversation_manager.py:40-200.

4. Persistence Layer (ORM)

The persistence layer is built on SQLAlchemy, with one ORM class per schema mirroring the Pydantic models. The base class in letta/orm/base.py provides common timestamp columns, soft-delete flags, and a polymorphic organization/owner scoping pattern reused by every memory table. Source: letta/orm/base.py:1-140.

letta/orm/__init__.py re-exports the ORM models so that Alembic migrations and FastAPI dependencies share a single import surface. Source: letta/orm/__init__.py:1-60.

Data Flow Summary

flowchart LR
  Agent[Agent Step] --> CM[Core Memory<br/>Blocks]
  Agent --> AM[Archival Memory<br/>Passages]
  Agent --> RM[Recall Memory<br/>Messages]
  CM --> ORM1[(SQLAlchemy<br/>blocks/memory)]
  AM --> ORM2[(SQLAlchemy<br/>passages + vector)]
  RM --> ORM3[(SQLAlchemy<br/>messages)]
  ORM2 --> VDB[(pgvector / external<br/>embeddings)]

Operational Notes

• Quota enforcement: block edits that exceed limit are rejected before write, preventing context-window overflow. Source: letta/services/memory_manager.py:180-260.
• Sandbox transport: as of v0.16.8, tool results from the sandbox are serialized as JSON rather than pickle (#3343), closing a deserialization vector that could otherwise exfiltrate core-memory contents.
• File-like API: agents call memory_insert, memory_replace, memory_rethink, and memory_search through the standard tool schema, making the three memory tiers indistinguishable from ordinary file operations to the LLM.

Related Pages

Related topics: Project Overview & System Architecture, LLM Provider Integration & Compatibility, Hierarchical Memory & Data Layer

Agents, Tools & Sandbox Execution

Letta's runtime is structured around three tightly-coupled layers: agents that drive the LLM control loop, tools that expose side-effecting actions to the agent, and a sandbox that executes those tools in an isolated process. Together they let a long-lived agent call arbitrary user code, manipulate its own memory, and stay safe from prompt-injected or malformed tool definitions.

Agent Loop and Variants

The canonical agent implementation lives in letta_agent.py and exposes the standard step / stream interface that consumes a LLMConfig, memory blocks, and tool definitions, then issues model calls and processes returned tool calls Source: letta/agents/letta_agent.py:1-120.

letta_agent_v3.py is the refactored successor that consolidates step state into a single AgentState snapshot, reducing redundant DB reads during a multi-step turn Source: letta/agents/letta_agent_v3.py:1-90. Both classes ultimately delegate tool execution to the shared ToolExecutor.

Two narrower variants exist for specialized flows:

• ephemeral_agent.py runs a single conversation without persisting agent or message state to the database, used for one-shot sub-agent calls and evaluators Source: letta/agents/ephemeral_agent.py:1-80.
• voice_agent.py adapts the loop for streaming speech-to-text / text-to-speech input, chunking LLM output into audio frames while reusing the same tool-execution path Source: letta/agents/voice_agent.py:1-110.

Tool Registration and Execution

A tool in Letta is represented by a Tool record that carries its JSON schema, source code (for Python-style tools), and a tool_type distinguishing composite, Letta-core, and external integrations. During an agent step, the LLM emits tool-call arguments that are validated against the tool's args_json_schema before invocation.

Execution is centralized in services/tool_executor.py, which selects between the local interpreter and the sandbox runner based on the tool's tool_type and the deployment configuration Source: letta/services/tool_executor.py:1-150. For composite and user-defined tools the executor serializes the call into a request envelope and forwards it to the sandbox.

A known fragility sits in the dynamic-model generation path: when args_json_schema lacks a title field, one code path defaults the generated Pydantic class to DynamicModel while another path defaults to BaseModel, producing a NameError: name 'DynamicModel' is not defined at runtime. This is tracked in community issue #3319.

Sandbox Isolation and Security

The sandbox lives under letta/services/tool_sandbox/ and executes tool code in a separate process (E2B-style or local subprocess) so that arbitrary Python cannot reach the server's in-memory state. Inputs and outputs cross the boundary as structured JSON.

Until v0.16.7 the boundary used pickle to transport results, which let a malicious tool response trigger arbitrary deserialization inside the server. PR #3343 (shipped in v0.16.8) replaced pickle with JSON, closing that vector and is the headline security change of the latest release Source: release notes (v0.16.8).

Despite that fix, community issue #3388 reports residual cross-session state leakage: a tool can poison persistent core memory blocks, and because those blocks are loaded into every later session against the same agent, the contamination survives sandbox restarts. Mitigation requires treating core-memory writes as sensitive mutations gated by tool allow-lists rather than relying on process isolation alone.

Multi-Agent Composition

When an agent needs to delegate, it can spawn child agents through the groups/ machinery. supervisor_multi_agent.py implements a top-down pattern where a supervisor routes messages to specialist sub-agents and aggregates their tool-call results Source: letta/groups/supervisor_multi_agent.py:1-160. sleeptime_multi_agent_v4.py implements the inverse pattern: a primary "wake-time" agent serves the user while a background "sleeptime" agent periodically consolidates archival memory and rewrites core blocks Source: letta/groups/sleeptime_multi_agent_v4.py:1-140.

Both group types reuse the same per-agent step pipeline, so tool execution, sandbox routing, and JSON serialization rules remain identical across the composition.

Data Flow Summary

Agent Step → LLM emits tool_call
          → ToolExecutor validates args_json_schema
          → Sandbox runner executes in isolated process
          → JSON result returned across boundary
          → Agent appends tool_return message, loops

The boundary is intentionally narrow: only validated JSON crosses it, which is what made the pickle-to-JSON migration a clean, non-breaking security improvement. End-users interact with the system through the Python/TypeScript clients or the REST API, both of which ultimately drive an agent class from letta/agents/ and therefore inherit the same tool-execution and sandbox guarantees (and limitations) described above.

Doramagic Pitfall Log

Found 38 structured pitfall item(s), including 9 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/letta-ai/letta/issues/3310

2. Configuration risk: Configuration risk requires verification

• Severity: high
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/letta-ai/letta/issues/3386

3. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: Bedrock provider ignores encrypted AWS credentials
• User impact: Developers may expose sensitive permissions or credentials: Bedrock provider ignores encrypted AWS credentials
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Bedrock provider ignores encrypted AWS credentials. Context: Observed when using python, macos
• Evidence: failure_mode_cluster:github_issue | https://github.com/letta-ai/letta/issues/3386

4. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: VLLM provider ignores encrypted API keys during model discovery
• User impact: Developers may expose sensitive permissions or credentials: VLLM provider ignores encrypted API keys during model discovery
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: VLLM provider ignores encrypted API keys during model discovery. Context: Observed when using python, macos
• Evidence: failure_mode_cluster:github_issue | https://github.com/letta-ai/letta/issues/3385

5. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: [Bug]: Cross-Session State Leakage via Persistent Core Memory Poisoning (Sandbox Isolation Failure)
• User impact: Developers may expose sensitive permissions or credentials: [Bug]: Cross-Session State Leakage via Persistent Core Memory Poisoning (Sandbox Isolation Failure)
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: [Bug]: Cross-Session State Leakage via Persistent Core Memory Poisoning (Sandbox Isolation Failure). Context: Observed when using macos
• Evidence: failure_mode_cluster:github_issue | https://github.com/letta-ai/letta/issues/3388

6. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/letta-ai/letta/issues/3279

7. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/letta-ai/letta/issues/3351

8. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/letta-ai/letta/issues/3362

9. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/letta-ai/letta/issues/3319

10. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: Documented all-extras install fails by building psycopg2 from source
• User impact: Developers may fail before the first successful local run: Documented all-extras install fails by building psycopg2 from source
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Documented all-extras install fails by building psycopg2 from source. Context: Observed when using python, macos
• Evidence: failure_mode_cluster:github_issue | https://github.com/letta-ai/letta/issues/3380

11. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/letta-ai/letta/issues/3346

12. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/letta-ai/letta/issues/3318

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using letta with real data or production workflows.

• Should deterministic code structure live outside embedded memory? - github / github_issue
• OptimisticJSONParser drops closing quote for string values ending in an - github / github_issue
• [[BUG]: MCP server refresh does not recover tools for legacy/flattened se](https://github.com/letta-ai/letta/issues/3353) - github / github_issue
• Feature Request: Add Standard Memory Evaluation Benchmarks (LOCOMO, MemB - github / github_issue
• POST /v1/tools: 500 SQL error when tool name cannot be extracted from so - github / github_issue
• OpenAI-compatible /v1/chat/completions endpoint rejects standard image_u - github / github_issue
• Enable Private Vulnerability Reporting - github / github_issue
• Anthropic streaming inner-thought completion check blocks zero-argument - github / github_issue
• AsyncComposioToolSet execute_action uses mutable params default and unbo - github / github_issue
• MCP server tool discovery lacks operation-level timeouts for connect/lis - github / github_issue
• README typo: agent help -> agent helps (line 15) - github / github_issue
• MCP server PATCH schema rejects server-name-only and partial config upda - github / github_issue