v2.11 introduces ~45% sustained CPU consumption on idle instance (pure Python asyncio, not PyTorch)

Environment:

Agent Zero v2.11, Docker container, Ubuntu 24.04 VPS: 2 vCPU / 4GB RAM (KVM hypervisor) Supervisord managing run_ui, run_cron, run_tunnel_api Observation: After updating to v2.11, run_ui consumes ~45% CPU on a 2-vCPU server at idle (no active chat sessions). Prior to the v2.11 update, idle CPU was ~4%. The increase appears immediately after the update and persists indefinitely.

Diagnostics performed:

PyTorch eliminated as cause:

top -H showed hot thread named pt_main_thread initially Traced to sentence_transformers importing torch at module level in models.py (line 46, from sentence_transformers import SentenceTransformer) Made import lazy (deferred to inside _get_local_embedding_model()) — freed ~750MB RAM Also commented out top-level kokoro_tts and whisper_stt imports in preload.py After fix: pt_main_thread disappeared from run_ui entirely Residual 45% CPU — pure Python asyncio:

Hot thread renamed to python (generic name, not PyTorch) wchan=ep_poll — thread sleeping in epoll_wait(), waking on network events Context switches: ~440/2s baseline, spiking to ~1,988/2s every ~60 seconds (likely job_loop firing) docker logs --since 5m returns quickly with no error loops No active chat sessions during measurement ss -tn and further asyncio profiling not completed — py-spy not available in this environment What has NOT been investigated (requires py-spy or built-in profiling):

Which specific coroutine/callback is responsible for ~1,250 network wakeups/second at idle Whether ACP session bridge, fasta2a server, or new WebSocket handling introduced in v2.11 is polling or keeping connections alive unnecessarily Whether the job_loop task schedule changed between v2.10 and v2.11 Request: Could the team advise what changed in v2.11 regarding background task scheduling or async connection management? A built-in profiling endpoint or py-spy guide for Docker deployments would help isolate this further. The 45% idle CPU on a shared VPS risks hypervisor throttling and makes the platform unsuitable for always-on VPS deployments without significant over-provisioning.