Run concurrent Omnigent conversations with real hosts and runners while replacing the LLM with a zero-latency mock. Read the generated report to explain response-time distributions, throughput, and failures, helping assess Omnigent's own processing overhead.
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 local stack (dev/loadtest/run.py). Gather inputs, run it, then read the generated summary.md and explain the latency distribution (avg/median/p95/p99, throughput, failures). NOT for single-request latency micro-benchmarks (that is dev/benchmarks/).
Review the instructions the agent will receive before you install.
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).
python dev/loadtest/run.py \
--users <N> --spawn-rate <R> --run-time <T> \
--sessions-per-user <S> --turns-per-session <TU>
It boots the stack, prints the server URL + registered agent, runs Locust, and
writes dev/loadtest/results/omnigent_load_test-<timestamp>/.
Read the summary.md and relay it. Focus on:
console.log and, for a host that failed to register,
the per-host results/.../host-workspaces/<name>/host.log. At high N, failures
usually mean the load box saturated, not the server.--turns-per-session is expected and is the interesting signal.If failures appeared or the tail looks high, suggest a concrete next step (lower
N if the load box is saturated, raise --turns-per-session to study history
growth, lengthen --run-time for steady state, or check server logs/metrics).
dev/loadtest/omnigent_load_test.py; driver + report:
dev/loadtest/run.py. Full reference: dev/loadtest/README.md.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Test Omnigent’s native Antigravity integration with a live local server and the real agy CLI. Verify messages traveling between the web interface and terminal, mirrored replies, permission requests, interruption, session resumption, and process cleanup.
Test Omnigent’s Antigravity SDK integration against a live local server. Build test agents and run real conversations to check Gemini authentication, model selection, tool connections, and failures across the full execution path.
Create reference documentation directly from source code for public functions, classes, command-line commands, and endpoints. Organize parameters, defaults, return values, errors, and runnable examples, then check that the documentation matches the implementation.
Create an Omnigent agent directory using validated templates for configuration and instructions. Choose how the agent runs, then add web search, shell access, external tool connections, or subagents only when the task requires them.
Turn a selected range of commits or merged pull requests into release notes grouped by change type. Describe user-visible effects, link to supporting changes, and highlight breaking changes so readers can assess an upgrade.
Test Omnigent’s setup, help, and terminal interactions by driving the real CLI in an isolated environment. Capture rendered screens and compare checks before and after a change to establish whether a reported interface problem was fixed.