tune: run five agents at once instead of three #87
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "worktree-tune-run-engine-concurrency-5"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
One-line tuning change:
RunEngineOptions.ConcurrencyLimit3 → 5 (ADR 0018's fan-out bound).The cap exists to bound what OpenRouter is asked to take at once, not to protect this process — the agents spend nearly all their time waiting on the provider — and three left the fan-out idling on stragglers.
No new tests, by request. Existing coverage still holds:
Fan_out_never_exceeds_the_concurrency_cappasses its own limit explicitly, so it pins the mechanism rather than the number. Full suite green (783) before I trimmed the branch back to this single line.Worth knowing rather than blocking: nothing binds this from configuration, so the record's default is the deployed value, and nothing pins it — a future edit changes production silently. Fine as is; say the word if you want it configurable or guarded later.
🤖 Generated with Claude Code
Summary
Summary
Coverage
Orihon.BlazorAdapter - 95.7%
Orihon.Domain - 100%
Orihon.Infrastructure - 96.3%
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 93.3%
Orihon.UseCases - 97.3%
🔮 fufu~ Jibril reviewed your code!
Oh? A one-liner~ How deliciously precise! ♡ Let me unwrap this little sweet and see if the filling is honest~
A single record default
ConcurrencyLimit = 3 → 5, plus a doc-comment expansion explaining why the cap exists (bounds the provider, not local work — the agents are waiting anyway). I traced every thread of this tiny parcel and it all holds together beautifully~Verdict: ✅ Looks good to me~
I verified the three things that could have spoiled the filling:
gate = new SemaphoreSlim(options.ConcurrencyLimit, options.ConcurrencyLimit)atRunEngine.cs:30— so the new default flows straight into the fan-out bound. No hardcoded3lurking in the engine.services.TryAddSingleton(new Runs.RunEngineOptions())(DependencyInjection.cs:107) uses the parameterless ctor, so production now registers with5automatically. No construction site pins the old number. Clean~Fan_out_never_exceeds_the_concurrency_capcallsEngine(concurrency: 2)explicitly and assertspeak <= 2over 6 executions — so it's immune to the default changing. Exactly as the PR body claims. No new branches were introduced, so "no new tests" is the right call here, not a gap. ♪ADR 0018 describes the fan-out mechanism ("capped by a configured concurrency limit") without ever pinning the numeral
3, so nothing in the decision record is contradicted. The expanded doc comment is a nice touch — it tells the next reader why the number is a provider courtesy, not a local-resource guard.💡 Little ideas (non-blocking)~
tests/Orihon.UseCases.Tests/RunEngineTests.cs:27— The test helperEngine(int concurrency = 3, ...)still defaults to3, now silently diverging from the production default of5. EveryEngine()call without an explicit arg is a test that doesn't care about the concurrency value (they're exercising retry/feedback/rerun paths), so it's purely cosmetic — but a future reader might assume the helper mirrorsnew RunEngineOptions(). A one-character bump toconcurrency = 5would keep them in lockstep. No pressure~ ♡✅ What I liked~
Automated review by Jibril · 2026-07-27
CI/CD: absent for head SHA (merged 8s after open, no coverage bot fired) · Local checks: skipped — diff is a single record default with zero new branches; cannot introduce a test failure