惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V
Visual Studio Blog
IT之家
IT之家
博客园 - 聂微东
The Cloudflare Blog
月光博客
月光博客
阮一峰的网络日志
阮一峰的网络日志
S
SegmentFault 最新的问题
Apple Machine Learning Research
Apple Machine Learning Research
酷 壳 – CoolShell
酷 壳 – CoolShell
爱范儿
爱范儿
H
Help Net Security
博客园 - 叶小钗
V
V2EX
WordPress大学
WordPress大学
J
Java Code Geeks
Hugging Face - Blog
Hugging Face - Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园_首页
C
Check Point Blog
B
Blog
D
DataBreaches.Net
美团技术团队
罗磊的独立博客

LangChain Forum - Latest posts

Prompt_cache_retention: '24h' supported in langchain agents and where to provide it, inside invoke or while creating client? Could RAG pipelines realistically cause deployment timeouts, is Render suitable for first-time RAG deployments? How do I use langchain_postgres' init_vectorstore_table correctly? Proposal: Graph-wide default error handler for StateGraph (fallback for nodes without error_handler) Support timedelta for CachePolicy.ttl, consistent with TimeoutPolicy Question about LangSmith Trace Search via API How to cancel a run correct !! Anyone confirms this issue that deepagent ui streaming is disturb by update in deepagent or bug issue Would pre-inference routing help long-context agent workflows? Best Stack for Building AI Applications Question about LangSmith Trace Search Seeking help regarding the connection between Websocket and tool calls Tool invocation error with empty error message when using `InjectedState` + `Command` return in async tool How to use @langchain/react FileSystem middleware Using ChatSnowflake with agents Built llmsessioncontract on AgentMiddleware: runtime enforcement of tool-call protocols — feedback wanted DeltaChannelHistory not found in langgraph-api:3.12 Improving citation accuracy and reducing hallucinations in custom Parent-Child RAG pipeline (Gemma3:4B + FAISS+BM25 + Cross-encoder reranker) Metadata filter not filtering for alerts Connecting the Slack integration fails with invalid_team_for_non_distributed_app Trouble understanding and editing experiment summary evaluators feedbacks SSL certificate error from httpx with LangGraph server WikipediaLoader endup in JSONDecodeError Human-in-the-loop approval dashboard for LangGraph agents — open source, free to deploy Should interrupt() be split into two primitives — one for human input, one for s2s data fetching? How are people handling data governance across agent handoffs in production? Feature Request: @task metadata Research: Friction Points in Agentic Commerce Transactions How should I provide an agent to a LangGraph server?
Cache disable in Deepagent
@mdrxy Mason · 2026-04-19 · via LangChain Forum - Latest posts

hi @AmitPZepto

what I can see from the souce code is that there is no public flag on create_deep_agent to turn the prompt-cache middleware off. It is appended unconditionally to the middleware stack (deepagents/graph.py:462, :520, :591):

# graph.py (deepagents)
gp_middleware.append(AnthropicPromptCachingMiddleware(unsupported_model_behavior="ignore"))
# ...
subagent_middleware.append(AnthropicPromptCachingMiddleware(unsupported_model_behavior="ignore"))
# ...
deepagent_middleware.append(AnthropicPromptCachingMiddleware(unsupported_model_behavior="ignore"))

The good news: that middleware is a no-op for any model that is not a ChatAnthropic instance - including ChatLiteLLM. So the right fix depends on why you are seeing cache_control headers at all.


How the cache middleware actually decides to fire

AnthropicPromptCachingMiddleware._should_apply_caching gates on an isinstance check:

# langchain_anthropic/middleware/prompt_caching.py
def _should_apply_caching(self, request: ModelRequest) -> bool:
    if not isinstance(request.model, ChatAnthropic):
        msg = (
            "AnthropicPromptCachingMiddleware caching middleware only supports "
            f"Anthropic models, not instances of {type(request.model)}"
        )
        if self.unsupported_model_behavior == "raise":
            raise ValueError(msg)
        if self.unsupported_model_behavior == "warn":
            warn(msg, stacklevel=3)
        return False
    ...

Because deepagents constructs it with unsupported_model_behavior="ignore", a non-Anthropic model silently skips caching - no cache_control block, no warning, no error. A real langchain_litellm.ChatLiteLLM instance would not get cache headers added.

So if you are seeing cache headers reach the wire, one of the following is true:

  1. You are passing a model string (e.g. "anthropic:claude-haiku-4-5") to create_deep_agent. Internally resolve_model() calls init_chat_model() (deepagents/_models.py:45), which constructs a ChatAnthropic - not LiteLLM. The middleware then does fire
  2. You are pointing ChatAnthropic at a LiteLLM proxy via base_url=.... It is still a ChatAnthropic instance, so cache headers are injected; whether the proxy forwards them correctly is a separate problem
  3. A custom profile added its own cache middleware - unlikely unless you wrote one

Fix 1 - actually use

If your intent is “talk to Haiku through LiteLLM”, instantiate ChatLiteLLM yourself and pass the instance (not a string). The cache middleware will see it is not ChatAnthropic and silently skip (unsupported_model_behavior="ignore").

from langchain_litellm import ChatLiteLLM
from deepagents import create_deep_agent

llm = ChatLiteLLM(model="claude-3-5-haiku-20241022", temperature=0)

agent = create_deep_agent(
    model=llm,            # pass the instance, NOT a string like "anthropic:..."
    tools=[...],
    system_prompt="...",
)

Docs: ChatLiteLLM integration.

With this setup there are no cache_control blocks in the outbound payload at all - verify by enabling LiteLLM debug logging (litellm._turn_on_debug()). If you still see them, your model is not what you think it is; inspect type(agent.nodes[...].runnable.model) or just print the bound chat model.

Fix 2 - if you must keep ChatAnthropic but do not want caching

No public API exists today, so your options are:

(a) Subclass / replace the middleware. Build your own no-op class and ship it; you still cannot remove the deepagents-appended one, but you can post-process the request in your own middleware that runs inside it:

from langchain.agents.middleware.types import AgentMiddleware

class StripCacheControl(AgentMiddleware):
    def wrap_model_call(self, request, handler):
        # Remove cache_control that the Anthropic middleware just injected
        ms = dict(request.model_settings or {})
        ms.pop("cache_control", None)
        request = request.override(model_settings=ms)
        # also strip from system + tools if you need to be thorough
        return handler(request)

the AnthropicPromptCachingMiddleware is appended after user middleware= in graph.py:580-591, so your middleware wraps it from the outside. In the LangChain agents middleware model, wrap_model_call composes like an onion: the last-appended middleware runs closest to the model, which means your middleware runs after the cache middleware on the response but before it on the request - so stripping on the way in will be re-added by the Anthropic middleware on its way down. The practical way to kill it is a monkey-patch:

Apply this once at import time, before calling create_deep_agent. Ugly, but it is the only reliable switch today.

(b) Open a feature request. A disable_prompt_cache: bool = False kwarg on create_deep_agent (or better, letting the caller fully replace the tail middleware) is a reasonable ask - track or file it at https://github.com/langchain-ai/deepagents/issues.


Worth sanity-checking the premise. Per Anthropic’s prompt-caching docs, Claude 3 Haiku, Claude 3.5 Haiku and Claude Haiku 4.5 all support prompt caching (2,048-token minimum for the Haiku family). If your LiteLLM call is failing with a cache-related error, the likely culprit is not the model - it is that:

  • your LiteLLM version does not forward cache_control blocks on the Anthropic path, or
  • LiteLLM is routing to a backend that does not (e.g. Bedrock Claude Haiku, where caching support/headers differ), or
  • the request is below the 2,048-token minimum (this should be a silent no-cache, not an error - if it errors, the proxy is rejecting the block).

If you share the actual error message from LiteLLM, the root cause is usually identifiable without disabling caching at all. But if you just want it gone: use Fix 1.

Sources