- Set the destination project statically
- Set the destination project dynamically
- Set the destination workspace dynamically
- Write traces to multiple destinations with replicas
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 service key or PAT has the necessary permissions for all target workspaces. We recommend using a multi-workspace service key for production deployments. For LangSmith deployments, you must add a service 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.Write traces to multiple destinations with replicas
Replicas let you send every trace to multiple projects or workspaces at the same time. Unlike the dynamic routing patterns where each trace goes to one destination, replicas duplicate the trace to all configured destinations in parallel. Replicas can be useful for:- Mirror production traces into a staging or personal project for debugging.
- Write to multiple workspaces for multi-tenant isolation without changing any application code.
- Send traces to the same server under different projects, with per-replica metadata overrides.
Configure replicas via environment variable
Set theLANGSMITH_RUNS_ENDPOINTS environment variable to a JSON value. Two formats are supported:
-
Object format: maps each endpoint URL to its API key:
-
Array format: a list of replica objects, useful when you need multiple replicas pointing at the same URL or when you want to set a
project_nameper replica:
Configure replicas at runtime
You can also pass replicas directly in code, which is useful when destinations vary per request or tenant.updates field to merge additional fields (such as metadata or tags) into a run for a specific replica only—the primary trace is unchanged. Replica errors are non-fatal: if a replica endpoint is unavailable, LangSmith logs the error without affecting the primary trace.
Replicate within the same server (project-only replicas)
If all your replicas use the same LangSmith server, you can omitapi_url and auth and specify only a project_name. The SDK reuses the default client credentials:
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

