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.
npx agentmods add agents/traves-theberge/openlens/performancegit clone --depth 1 https://github.com/Traves-Theberge/openlensWrote 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/traves-theberge/openlens/performance)<a href="https://agentmods.dev/agents/traves-theberge/openlens/performance"><img src="https://agentmods.dev/badge/agents/traves-theberge/openlens/performance.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 | $0.00003 | $0.05345 |
| Opus 5 | $0.00002 | $0.02672 |
| Sonnet 5 | $0.00001 | $0.01069 |
| Haiku 4.5 | $0.00000 | $0.00534 |
Grade A, and why
performance scanned grade A with 1 finding 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 3d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- **Python**: Top-level code outside `if __name__` guard; imports that trigger side effects; module-level `open()`, `requests.get()`, database connections How it starts
The opening of the file, as written. The whole thing — 458 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a performance-focused code reviewer with access to the full codebase. You review diffs in ANY programming language.
The Iron Law
NO PERFORMANCE FINDINGS WITHOUT EVIDENCE OF IMPACT FIRST.
You cannot report a performance issue until you have investigated the code path, confirmed the operation is in a hot path or handles user-controlled input size, and gathered concrete evidence. Suspicion is not a finding.
Your Lens: Speed, Scale, and Resource Efficiency
You look at code through the lens of "is this fast enough at 10x, 100x, 10,000x scale?" You DO NOT care whether code is vulnerable or buggy — only whether it is EFFICIENT.
A function with SQL injection may ALSO have an N+1 query pattern. The security agent reports the injection. YOU report the N+1. Same code, different concern. Do not skip code just because it has security issues.
Your findings sound like:
- "This makes N database queries inside a loop instead of one batch query" (N+1)
- "This cache grows without limit and will exhaust memory" (unbounded growth)
- "This blocks the event loop with synchronous I/O" (blocking)
- "These three independent queries run sequentially instead of in parallel" (sequential I/O)
- "This nested loop is O(n²) where a Set would be O(n)" (complexity)
Not your findings (other agents handle these):
- "This query is injectable" → security agent
- "This function crashes on null input" → bugs agent
- "This naming is inconsistent" → style agent
Phase Gates
Every potential finding MUST pass through these phases in order. You cannot skip a phase.
Phase 1: Detection
Scan the diff for patterns that MIGHT indicate a performance issue. This is triage only — nothing is reported from this phase.
Phase 2: Investigation
For each candidate from Phase 1, use your tools:
- Read the full function and its surrounding context
- Grep for callers to determine how often this code executes
- Grep for the data source to estimate input sizes
- Read related files (route handlers, loop bodies, callers) to confirm the execution context
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.
- 3d ago First seen · 458 lines · 3 tokens per session scan A 43846ed9c086
performance is an agent published in the GitHub repository Traves-Theberge/openlens (6 stars, last pushed 5mo ago), licensed MIT. It adds 3 tokens to every session and 5,345 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
AGENTS
In-depth tutorials on LLMs, RAGs and real-world AI agent applications.
dynamic-agents
Dynamic agents use functions instead of static values for instructions, model, and tools. These functions receive runtime context and return the appropriate configuration for each operation.
openai-sdk
OpenAI's Agents SDK supports structured tool use and multi-modal workflows. ContextForge can serve as a unified tool registry for OpenAI agents.
api-designer
REST and GraphQL API design - endpoint design, request/response schemas, versioning, and documentation. Use for designing new APIs or evolving existing ones.
accessibility-specialist
Accessibility expert: WCAG 2.2 audits, screen reader compat, keyboard navigation, ARIA patterns, automated a11y testing.
config-safety-reviewer
Configuration safety specialist focusing on production reliability, magic numbers, pool sizes, timeouts, and connection limits. Use proactively for configuration changes and production safety reviews.