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?

A is correct because serverless runtimes (AWS Lambda, Google Cloud Functions, etc.) reuse the same execution environment for multiple invocations during warm periods. Initializing the SDK client at module scope (outside the handler) 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. B is wrong because initializing a new client per invocation 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. C 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; switching to raw HTTP adds maintenance burden without addressing the root cause. D is wrong because setting timeout to 0 typically means 'no timeout' (unlimited wait) rather than 'skip connection establishment'; this misunderstands the parameter semantics and could cause hung requests.