- 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
LangSmith uses the concept of a project to group traces. If left unspecified, the project is set todefault.
You can set the LANGSMITH_PROJECT environment variable to configure a custom project name for an entire application run. Set this before running 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:- Pass the project name at decoration or configuration time.
- Override it per individual call.
- Set it when constructing a run directly.
Setting the project name dynamically using one of the following methods overrides the project name set by the
LANGSMITH_PROJECT environment variable.Set the destination workspace dynamically
If you need to route traces dynamically to different LangSmith workspaces based on runtime configuration (e.g., routing different users or tenants to separate workspaces), the approach differs by language:- Python: use workspace-specific LangSmith clients with
tracing_context. - TypeScript: pass a custom client to
traceable, or useLangChainTracerwith callbacks.
@traceable.
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 both the workspace and project name per route to organize traces further within each workspace.
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.
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:
Route between LangSmith and OpenTelemetry destinations
You can decide at runtime whether a given invocation sends traces to LangSmith, to an OpenTelemetry (OTel) backend, or to both, without redeploying or modifying application logic. This is useful when you want to toggle between observability backends per environment, or even per request, making the decision at runtime. Set the tracing mode using thetracing_mode constructor argument or the LANGSMITH_TRACING_MODE environment variable. Both accept the same values; an explicit tracing_mode argument always takes precedence over the env var:
"langsmith"(default): sends traces natively to LangSmith."otel": exports traces as OpenTelemetry spans to a configured OTel backend."hybrid"(Python only): sends to both LangSmith and an OTel backend from a single replica.
If you are using the deprecated
otel_enabled parameter on Client (Python only), migrate to tracing_mode: Client(otel_enabled=True) → Client(tracing_mode="hybrid"). The otel_enabled parameter will be removed in the next minor version.Client directly into a replica to apply the desired mode at runtime:
tracing_mode on each Client determines that replica’s export path. In Python, "hybrid" mode handles both destinations within a single replica. In TypeScript, the “send to both” case uses two separate replicas, one for each client, because there is no "hybrid" mode. Since each replica resolves its own client independently, you can also mix modes within a single tracing_context, for example keeping one replica sending to LangSmith while forwarding the same trace to an OTel collector via a second replica.
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

