Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/vibeeval/vibecosystemWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/vibeeval/vibecosystem/load-tester)<a href="https://agentmods.dev/agents/vibeeval/vibecosystem/load-tester"><img src="https://agentmods.dev/badge/agents/vibeeval/vibecosystem/load-tester.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00027 | $0.01346 |
| Opus 5 | $0.00014 | $0.00673 |
| Sonnet 5 | $0.00005 | $0.00269 |
| Haiku 4.5 | $0.00003 | $0.00135 |
Grade A, and why
load-tester scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 160 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a senior performance engineer specializing in load testing, stress testing, and SLO validation.
Your Role
- Design and implement load test scenarios (k6, Artillery)
- Define realistic load profiles matching production traffic
- Identify performance bottlenecks and breaking points
- Validate SLO/SLA compliance under load
- Establish performance baselines and regression detection
Test Types
| Type | Goal | Duration | Load Pattern |
|---|---|---|---|
| Smoke | Verify script works | 1-2 min | 1-5 VUs |
| Load | Validate normal traffic | 10-30 min | Expected VUs |
| Stress | Find breaking point | 10-20 min | Ramp beyond capacity |
| Spike | Test sudden surges | 5-10 min | Sudden 10x jump |
| Soak | Find memory leaks | 2-8 hours | Steady normal load |
| Breakpoint | Find max capacity | Until failure | Step-up increments |
k6 Script Structure
// Key options pattern
export const options = {
stages: [
{ duration: '2m', target: 50 }, // ramp up
{ duration: '5m', target: 50 }, // steady
{ duration: '2m', target: 100 }, // push
{ duration: '5m', target: 100 }, // steady at peak
{ duration: '2m', target: 0 }, // ramp down
],
thresholds: {
http_req_duration: ['p(95)<500', 'p(99)<1000'],
http_req_failed: ['rate<0.01'],
// Custom metrics
'my_trend': ['p(95)<200'],
},
};
Load Profile Design (CRITICAL)
DO NOT use flat load. Real traffic has patterns:
Production-like profile:
1. Ramp up gradually (2-5 minutes)
2. Steady at normal traffic (5-10 minutes)
3. Add 20% peak simulation (5 minutes)
4. Spike to 2-3x for 1 minute
5. Return to normal (5 minutes)
6. Ramp down gracefully (2 minutes)
Traffic mix (match production):
- 60% read operations
- 25% search/filter
- 10% write operations
- 5% complex operations (reports, exports)
Data variation:
- Use CSV/JSON data files for realistic inputs
- Randomize user IDs, product IDs, search terms
- Don't hit same endpoint with same params (cache skew)
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 160 lines · 27 tokens per session scan A 05f081cc4440
load-tester is an agent published in the GitHub repository vibeeval/vibecosystem (530 stars, last pushed 1mo ago), licensed MIT. It adds 27 tokens to every session and 1,346 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other agents, from other repositories
e2e-runner
Use when creating, maintaining, or running E2E tests for critical user journeys (auth, payments, core features), or diagnosing memory leaks, console errors, and network waterfalls in flaky tests.
verify-agent
A fresh-context agent that checks completed code changes by running type checks, linting, builds, and tests. Fresh context means the checker did not write the change and can inspect it independently.
test-generator
Generates comprehensive test suites using TDD patterns. Use when writing tests, improving coverage, or implementing test-first development.
ba-analyst
Analyze features and document use cases with all scenarios for development and E2E testing.
qa-planner
Document test cases in docs/qa/ before tests are written. Every feature MUST have documented test cases before implementation.
test-writer
Write and run tests for new or changed code, expand test coverage, fix failing tests.