Should Replit reclaim memory from idle always-on deployments?

Replit Deployments provide an always-on mode for services that must remain continuously available. Assuming the current documented deployment model, the unresolved design question is whether an idle always-on deployment should automatically relinquish accumulated memory while preserving availability.

Community reports suggest resident-memory growth in some always-on containers, but this behavior has not been confirmed against current official documentation. The platform's garbage-collection schedule, associated CPU cost, and applicability across runtimes therefore require review. Any policy must also account for cold-start latency, workload-specific heap behavior, and changes to the hosting environment. No specific Replit runtime version is assumed here; current dashboard controls need verification.

A useful evaluation would compare resident memory, CPU time, request latency, and recovery time under defined idle thresholds and memory limits. The decision is whether automatic reclamation should be the default, opt-in, or restricted by deployment type.

Should idle always-on deployments automatically release memory, and what threshold would make that behavior predictable? Which safeguards should prevent reclamation from harming availability or performance?