Considering config['configurable'] vs context

OSS Product Help LangGraph
1

Hello Everyone!

The concept of graph Context was introduced with the update of Langgraph to 0.6.0. I’ve been grappling with understanding the use of Context vs the use of config[“configurable”] since. My understanding is that Context is meant to be a complete replacement of config[“configurable”], but in my experience this hasn’t been the case. For example, when passing immutable state to a thread run, context does a great job with taking the place of config[“configurable”] and is accessed, per the documentation, via Runtime (runtime.context). The exception here being the thread_id. I’ve yet to figure out how to correctly handle thread_id. Conversely, I’ve found it better to store Assistant configurations in config[“configurable”] instead of Context. For me, it makes sense for there to be a deliniation between where immutable state and configuration of an Assistant lives; afterall these are two different responsibilities. Unfortunately, packages depend on context being pased as config. For example, for LangMem’s namespace templates to work, you must pass the parameter you’re templating in config['“configurable”]. Overall Context to replace config[“configurable”] seemed like a great update surface but has had unexpected consequences downstream.

As this concept is so new, I wanted to see if anyone else here thoughts on this, what they’re doing for best practices with the concepts, etc. Let me know your thoughts and lets discuss!

2 Likes
2

You’re right, the idea behind LangGraph 0.6.0 was for Context to be the unified place for user defined data, effectively replacing config["configurable"]. In practice though, most developers are still using a hybrid approach because the ecosystem (and core features like thread_id) hasn’t fully caught up.

What’s emerging as best practice looks like this:

  • Use Context for immutable runtime state that’s tied to application logic and should be accessible across nodes.

  • Use config["configurable"] for system level configuration (e.g. thread_id, assistant settings) and for compatibility with packages like LangMem that haven’t fully transitioned to Context.

So your separation, Context for state, config for assistant config and package compatibility, is actually the cleanest approach for now. Until the core and ecosystem fully align on Context, treating them as complementary rather than mutually exclusive is the most practical path.

3

that’s tricky.
When running RemoteGraph with Context and Configurable i get :

Cannot specify both configurable and context. Prefer setting context alone. Context was introduced in LangGraph 0.6.0 and is the long term planned replacement for configurable

When using context alone, ( with thread_id key chekpointer doesn’t seem to work!!)

I’m obliged to use config only to have memory.
Do you have any idea on how to fix this?
Thanks

4

Hi @errajibadr

what LangGraph/LangChain version are you using?

5

_Streaming_enhancement) ✗ uv pip freeze | grep langg

langgraph==1.0.1
langgraph-api==0.4.7
langgraph-checkpoint==3.0.0
langgraph-checkpoint-sqlite==3.0.0
langgraph-cli==0.4.0
langgraph-prebuilt==1.0.1
langgraph-runtime-inmem==0.9.0
langgraph-sdk==0.2.4

Extra context: i’m using Remote Graph with local docker images ( api+postgres+redis)

url = "http://localhost:8123"

graph_name = "agent"

remote_graph = RemoteGraph(graph_name, url=url)
context = {"user_id": "123", "thread_id": str(uuid.uuid4())}
config = {"configurable": context}
# %%
for chunk in remote_graph.stream(
    {"messages": [{"role": "user", "content": "hello"}]},
context=context,
config=config,
stream_mode="values",
):

i get the following error

httpx.HTTPStatusError: Client error ‘400 Bad Request’ for url ‘http://localhost:8123/threads/cc14719b-f4aa-4aa2-9a64-120ce0d86ff3/runs/stream’
For more information check: 400 Bad Request - HTTP | MDN
Cannot specify both configurable and context. Prefer setting context alone. Context was introduced in LangGraph 0.6.0 and is the long term planned replacement for configurable.

6

Hmmm I am getting the same error. It seems like it comes from LangSmith itself.
I dunno why it works this way. @LangChain-Team - is this expected behavior? :slight_smile:

7

I’ll attempt to succiently explain how I am currently handling this. I use the assistants provided by LangSmith

I set up configurations on the assistant. These variables are defined in my Context, but are not passed when calling the runs endpoints. I then am able to pass immutable data needed by the run through the context parameters of run calls. In order to maintain thread_id, I create a thread and then pass that to each run call with an assistant id. Hopefully this is helpful information. I can potentially provide code examples if this isn’t enough. The majority of what I described is expressed in the documentation link.

8

Thanks for the reply! but it doesn’t seem right as we can’t have dynamic contexts if we need to create different assistant Variations each time!! the hole point of context is to dynamically charge them no ?

  • MiddleWare V1.0 mainly relies on runtime.Context ! so if we can’t provide the context it’s does seem right at all.

@LangChain-Team curious to know

Will raise an issue if no answer by tonight
–> [Major BUG] - RemoteGraph in LangGraph 1.0: Cannot use `context` and `config` together - Forces choice between checkpointing OR middleware · Issue #6342 · langchain-ai/langgraph · GitHub