A financial services firm needs to call the Claude API from a serverless function that cold-starts frequently. The SDK client is initialized inside the handler function. During peak load, the team observes elevated p99 latency attributed to SDK initialization overhead on every cold start. What is the best practice for SDK client lifecycle management in serverless environments?

The correct practice is to initialize the Anthropic SDK client in the module-level scope outside the handler function so it is reused across warm invocations within the same execution environment. Serverless runtimes such as AWS Lambda and Google Cloud Functions reuse the same execution environment for multiple invocations during warm periods. Initializing the SDK client at module scope means the client is created once at cold start and reused for all subsequent warm invocations in the same environment. This is the standard pattern for SDKs, database connections, and HTTP clients in serverless architectures. Initializing a new SDK client inside the handler on every invocation to ensure connection state is fresh is wrong because it recreates the client object, re-reads environment variables, and re-establishes connection state on every call; this is the pattern causing the observed latency, not a solution. Using the raw HTTP API instead of the SDK to eliminate SDK initialization overhead is wrong because the Anthropic SDK is well-suited for serverless use; it is a thin wrapper over the HTTP API with minimal overhead when initialized at module scope, and switching to raw HTTP adds maintenance burden without addressing the root cause. Setting the SDK client's connection_timeout to 0 to disable connection establishment overhead is wrong because setting timeout to 0 typically means 'no timeout' or unlimited wait rather than 'skip connection establishment'; this misunderstands the parameter semantics and could cause hung requests.