Memcached item-size ceiling is startup-only and invisible to protocol clients

Memcached does not provide a query language, so bounding a dataset means constraining value size and key length rather than applying LIMIT or OFFSET semantics. The documented default maximum item size is 1 MB; a larger store is rejected with an object-too-large error and is never truncated or spilled to disk. That ceiling is set at startup with the -I option, cannot be negotiated per request, and the text protocol exposes no command that reports the effective value to clients.

Because the server neither negotiates nor advertises its item ceiling, clients must choose a conservative budget and enforce it before issuing a store. The rejection is deterministic rather than transient, so retrying the same payload keeps failing. Binary-protocol clients receive numeric status codes rather than text error strings, adding another layer of indirection when mapping failures. The open decision is the payload-size policy: should a client library hard-code the 1 MB default as its validation ceiling, or should it require operators to configure the budget explicitly for each deployment?

If a deployment raises the limit with -I, what mechanism allows clients to detect the new ceiling without a protocol-level introspection command? Is there a documented pattern for advertising the effective item-size limit to clients outside the memcached protocol? Should applications split or compress values proactively, or treat the too-large rejection as the sole enforcement mechanism?