claude-codex-settings is a collection of configurations and reusable extensions for Claude Code, OpenAI Codex, Cursor, and related coding tools. Developers use its skills, commands, hooks, agents, plugins, and MCP servers to shape coding-agent workflows and connect alternative model APIs. The catalogue entries are components of this collection that can be installed into supported coding tools.
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 skills add fcakyon/claude-codex-settings --skill running-livekit-simulationsgit clone --depth 1 https://github.com/fcakyon/claude-codex-settingsWrote 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/skills/fcakyon/claude-codex-settings/running-livekit-simulations)<a href="https://agentmods.dev/skills/fcakyon/claude-codex-settings/running-livekit-simulations"><img src="https://agentmods.dev/badge/skills/fcakyon/claude-codex-settings/running-livekit-simulations/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/fcakyon/claude-codex-settings/running-livekit-simulations"><img src="https://agentmods.dev/badge/skills/fcakyon/claude-codex-settings/running-livekit-simulations.svg" alt="Reviewed on agentmods" width="80" 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.00183 | $0.01463 |
| Opus 5.5 | $0.00073 | $0.00585 |
| Sonnet 5.5 | $0.00037 | $0.00293 |
| Haiku 4.5 | $0.00018 | $0.00146 |
Grade A, and why
running-livekit-simulations 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 14d 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- running-livekit-simulations — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 112 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Running LiveKit simulations
A simulation plays a scenario against the real agent using an LLM-driven simulated user, then a judge grades the transcript. A unit test asserts on one turn. A simulation tells you whether a whole conversation reached the right outcome.
Read lk agent simulate --help before running. Subcommands and flags change, a wrong flag wastes a
paid run, and this skill doesn't restate them. reading-livekit-docs has the rest.
When to reach for a simulation
Use simulations to regression-test long-horizon behavior before deploying to production: whether a
multi-turn conversation reaches the right outcome when the caller backtracks, whether details
gathered early survive to the end, whether the agent holds to its instructions under pressure, and
whether it ended in the right state. For a single turn, use testing-livekit-agents; to poke at
behavior while editing, use debugging-livekit-agents.
Running
Run from the agent's project directory. The mode is a subcommand:
lk agent simulate text --scenarios scenarios.yaml # see --help for the current flags
With no scenario file, the CLI generates scenarios from the agent's source. That uploads the
code, and the CLI asks for confirmation first. Generation belongs to writing-livekit-scenarios.
By default the CLI starts the agent as a local worker, dispatches the scenarios to it, and stops it when the run ends. An option lets you grade an already-running agent by name instead. That needs a scenario file, since there's no local source to generate from.
Concurrency is limited per run and per project. The docs have the current limits.
Text or audio
Text is the default, and it's the right one. The simulated user exchanges text with the agent, so the run exercises the LLM, the tools and the conversation logic while the framework turns off STT, TTS and VAD. It's faster, cheaper and more deterministic. Use it for iteration and for anything automated.
Audio runs the same scenarios through the full speech pipeline. The simulated user speaks, listens and interrupts like a caller would, and the run scores what only speech exposes:
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.
- 14d ago First seen · 112 lines · 183 tokens per session scan A e373c9dc38f3
running-livekit-simulations is a skill published in the GitHub repository fcakyon/claude-codex-settings (1,178 stars, last pushed yesterday), licensed Apache-2.0. It adds 183 tokens to every session and 1,463 once invoked, about $0.0007 per session on Opus 5.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-10-02.
Other skills, from other repositories
lov-runtime-verification
Verify client runtime fixes on actual desktop builds, physical iOS/Android devices, React Native/Flutter hosts, and deployed Web/PWA browsers with comparable workloads and lifecycle checks.
build-verification-skill
Build this project's verification skill - a small CLI that drives the running app and captures evidence, plus a feature map of what exists and how to reach it - and the CI check that keeps the map current. Use when asked to 'build a verification skill', 'let the agent drive the app', 'make a feature map', 'the agent…
harness-config-testing
Use when working in the harness-config repository on test strategy, regression coverage, fixtures, docs/TESTING.md, CLI end-to-end checks, projection edge cases, profile and ignore scenarios, or focused quality commands.
frontend-ui
Check layout states, responsive behavior, accessibility, and browser-visible regressions before claiming the UI works.
screen-reader-testing
Test web applications with screen readers including VoiceOver, NVDA, and JAWS. Use when validating screen reader compatibility, debugging accessibility issues, or ensuring assistive technology support.
test-runner
For a code change, pick the right test tier by change surface, run apc test with baseline diff, and report only NEW reds vs baseline back to the task's acceptance criterion. Separates envblocked from SUT red so a broken machine never fails the code.