Benchmark reveals Ollama queue, not runner or hardware, caps LLM agent concurrency

A developer benchmarking a local AI agent runner found that at four concurrent sessions, total wall-clock time scaled to 4.8 times the single-session baseline — worse than a perfectly serialised queue. Profiling showed the bottleneck was Ollama's internal request queue for the loaded model, while the runner's event loop responded in milliseconds and CPU and RAM remained well within limits. Background memory extraction after each reply also kept Ollama saturated long after users received answers, a hidden cost standard RPS benchmarks overlook. For coding jobs routed to the Claude API, a separate issue was found: a hardcoded rule serialised all work targeting the same repository regardless of the MAX_CONCURRENT setting. The developer replaced that blanket restriction with a path-overlap predicate, allowing two jobs in the same repo to run concurrently only when their target file paths are fully disjoint and neither job depends on the other.