Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →omnigent-ai/run-load-test
Run the Omnigent load test and produce a results file explaining the latencies. Load when the user wants to load-test / stress-test / benchmark Omnigent under concurrency ("load test omnigent", "stress test the server", "how many hosts/sessions/turns can it handle", "load test real agent turns / conversations", "run a load test"). The test makes each simulated user a real omnigent host that creates host-bound sessions and drives real multi-turn conversations with a mocked LLM; it boots its own l
Passed 17 of 21 test cases with the skill, and 4 of 21 without it.
and 20 more in the full report
15 fixed4 passed either way4 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 15 test cases the skill fixed. Same model, same prompt, with and without the skill.
Which underlying script contains the Locust scenario definitions driven by `dev/loadtest/run.py`?
| Checked | Without skill | With skill |
|---|---|---|
| identifies dev/loadtest/omnigent_load_test.py as the Locust scenario file | Missed | Passed |
The instructions your model reads when the skill loads.
Drives dev/loadtest/ end to end: collect inputs → run → read summary.md →
explain the latencies. Each Locust user is a real omnigent host that
registers over the host tunnel, creates host-bound sessions, and drives real
multi-turn conversations — every turn is a genuine post→idle loop through the
host's runner, with the LLM mocked (zero latency) so the numbers are
Omnigent's own overhead. -u N scales the number of hosts.
It boots its own local stack (server + mock LLM), so there is no server to
point at, and it runs from a repo checkout only. For single-request latency
micro-benchmarks (not concurrency), that is a different tool: dev/benchmarks/.
uv sync --extra loadtest --extra agents-sdk
Run with that same interpreter (e.g. .venv/bin/python), from the repo root.
Ask the user (AskUserQuestion when several are unknown); all have defaults.
| Input | Flag | Default | Notes |
|---|---|---|---|
| Hosts | --users | 4 | Concurrent hosts (N) — the main scale knob. |
| Spawn rate | --spawn-rate | 1 | Hosts started per second. |
| Run time | --run-time | 120s | 40s / 5m / 1h. |
| Sessions/host | --sessions-per-user | 2 | Host-bound sessions each host drives. |
| Turns/session | --turns-per-session | 4 | Turns per session — history grows across them. |
| Reply length | --reply-words | 60 | Words in the mocked (streamed) reply per turn. |
Capacity caveat — say this to the user if they ask for large N: turns run on
real host + runner subprocesses, so N hosts × M sessions = N×M runner processes
on this box. It is capacity-limited by design (real turns, not faked). Start at
--users 2 --sessions-per-user 1 --turns-per-session 2 --run-time 40s to confirm
the stack boots (~10-30s), then ramp to a few dozen hosts at most. At high N the
load box saturates before the server (Locust warns about CPU).
test cases passed, vs 4 / 21 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.