Skip to main content
This page covers how to control where LangSmith sends your traces—from static configuration to dynamic routing and multi-destination fan-out:

Set the destination project statically

As mentioned in the Tracing Concepts section, LangSmith uses the concept of a Project 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.
The LANGSMITH_PROJECT flag is only supported in JS SDK versions >= 0.2.16, use LANGCHAIN_PROJECT instead if you are using an older version.
If the project specified does not exist, it will be created automatically when the first trace is ingested.

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 with tracing_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

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:
  1. Initialize separate Client instances for each workspace with their respective workspace_id.
  2. Use tracing_context (Python) or pass the workspace-specific client to traceable (TypeScript) to route traces.
  3. 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 the config parameter.

Key points

  • Generic cross-workspace tracing: Use tracing_context (Python) or pass a workspace-specific client to traceable (TypeScript) to dynamically route traces to different workspaces.
  • LangGraph cross-workspace tracing: For LangGraph applications, use LangChainTracer with the workspace-specific client and attach it via the callbacks parameter.
  • LangSmith deployment override: Use a graph lifespan context manager (Python) to override the default deployment workspace based on runtime configuration.
  • Each Client instance maintains its own connection to a specific workspace via the workspaceId parameter.
  • 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 the LANGSMITH_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_name per replica:
You cannot use LANGSMITH_RUNS_ENDPOINTS alongside LANGSMITH_ENDPOINT. If you set both, LangSmith raises an error. Use only one to configure your endpoint.

Configure replicas at runtime

You can also pass replicas directly in code, which is useful when destinations vary per request or tenant.
You can also use the 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.
Auth does not propagate in distributed traces. When a trace spans multiple services, LangSmith forwards replica project_name and updates to downstream services automatically, but not API keys or credentials. Each service must configure its own credentials for replica destinations.

Replicate within the same server (project-only replicas)

If all your replicas use the same LangSmith server, you can omit api_url and auth and specify only a project_name. The SDK reuses the default client credentials: