EverOS 1.5.1

Hybrid and vector search keep up with 10 requests a second out of the box.
Each of those searches embeds its query first, and the slots reserved for
those calls were the limit: with 4 of them and a remote embedding endpoint
answering in about 0.45 s, search topped out near 9 requests a second and a
steady 10 queued without bound. The default is now 16, which held the same
load at a p50 of 0.42 s and a p95 of 1.45 s.

Changed

• [embedding].query_max_concurrent defaults to 16 instead of 4. Every
  hybrid or vector search makes one query embedding call, and the budget
  reserved for those calls bounded search throughput: with a remote
  endpoint answering in about 0.45 s, 4 slots capped hybrid search near 9
  requests/s, so a steady 10 requests/s queued without bound (10,020
  indexed entries, 5 minutes: p50 64 s, p95 101 s). At 16 the same load
  held p50 0.42 s, p95 1.45 s, p99 2.11 s, all 3,000 requests served at
  9.99/s. In-flight requests to the endpoint can now reach
  max_concurrent + 16; set it lower if the endpoint is rate-limited.

Upgrade

pip install --upgrade everos   # or: uv sync

Nothing to migrate. One thing to check: requests in flight to the embedding
endpoint can now reach max_concurrent + 16 (26 with the shipped values)
instead of 14. If your endpoint is rate-limited or a small self-hosted model,
set [embedding] query_max_concurrent (or EVEROS_EMBEDDING__QUERY_MAX_CONCURRENT)
back to what it can take. Roughly, the searches per second it can serve is
this value divided by the endpoint's per-call latency.

Full changelog: v1.5.0...v1.5.1