Set the destination project statically
As mentioned in the Tracing Concepts section, LangSmith uses the concept of aProject to group traces. If left unspecified, the project is set to default. You can set the LANGSMITH_PROJECT environment variable to configure a custom project name for an entire application run. This should be done before executing your application.
Set the destination project dynamically
You can also set the project name at program runtime in various ways, depending on how you are annotating your code for tracing. This is useful when you want to log traces to different projects within the same application.Setting the project name dynamically using one of the below methods overrides the project name set by the
LANGSMITH_PROJECT environment variable.Set the destination workspace dynamically
If you need to dynamically route traces to different LangSmith workspaces based on runtime configuration (e.g., routing different users or tenants to separate workspaces), Python users can use workspace-specific LangSmith clients withtracing_context, while TypeScript users can pass a custom client to traceable or use LangChainTracer with callbacks.
This approach is useful for multi-tenant applications where you want to isolate traces by customer, environment, or team at the workspace level.
Prerequisites
- A LangSmith API key with access to multiple workspaces.
- The workspace IDs for each target workspace.
Generic cross-workspace tracing
Use this approach for general applications where you want to dynamically route traces to different workspaces based on runtime logic (e.g., customer ID, tenant, or environment). Key components:- Initialize separate
Clientinstances for each workspace with their respectiveworkspace_id. - Use
tracing_context(Python) or pass the workspace-specificclienttotraceable(TypeScript) to route traces. - Pass workspace configuration through your application’s runtime config.
Override default workspace for LangSmith deployments
When deploying agents to LangSmith, you can override the default workspace that traces are sent to by using a graph lifespan context manager. This is useful when you want to route traces from a deployed agent to different workspaces based on runtime configuration passed through theconfig parameter.
Key points
- Generic cross-workspace tracing: Use
tracing_context(Python) or pass a workspace-specificclienttotraceable(TypeScript) to dynamically route traces to different workspaces. - LangGraph cross-workspace tracing: For LangGraph applications, use
LangChainTracerwith the workspace-specific client and attach it via thecallbacksparameter. - LangSmith deployment override: Use a graph lifespan context manager (Python) to override the default deployment workspace based on runtime configuration.
- Each
Clientinstance maintains its own connection to a specific workspace via theworkspaceIdparameter. - You can customize both the workspace and project name for each route.
- This pattern works with any LangSmith-compatible tracing (LangChain, OpenAI, custom functions, etc.).
When deploying with cross-workspace tracing, ensure your API key has the necessary permissions for all target workspaces. For LangSmith deployments, you must add an API key with cross-workspace access to your environment variables (e.g.,
LS_CROSS_WORKSPACE_KEY) to override the default service key generated by your deployment.Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

