MFLUX is a native MLX implementation of generative image models that runs locally on Mac computers. It is for generating images with supported models through command-line tools or a Python API. The catalogue skills and instruction support workflows built around these image-generation models.
Borrowing it
Nothing to install: this file belongs to mflux-community/mflux. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/mflux-community/mflux/main/.cursor/skills/mflux-model-tiny-test/SKILL.mdgit clone --depth 1 https://github.com/mflux-community/mfluxWrote 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/mflux-community/mflux/mflux-model-tiny-test)<a href="https://agentmods.dev/skills/mflux-community/mflux/mflux-model-tiny-test"><img src="https://agentmods.dev/badge/skills/mflux-community/mflux/mflux-model-tiny-test/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/mflux-community/mflux/mflux-model-tiny-test"><img src="https://agentmods.dev/badge/skills/mflux-community/mflux/mflux-model-tiny-test.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00073 | $0.01992 |
| Opus 5.5 | $0.00029 | $0.00797 |
| Sonnet 5.5 | $0.00015 | $0.00398 |
| Haiku 4.5 | $0.00007 | $0.00199 |
Grade A, and why
mflux-model-tiny-test 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 2mo 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 — 123 lines — stays where its author put it; the contents beside it link to each section on GitHub.
mflux tiny model-saving test
A tiny test proves a model's quantized checkpoint survives a save/load roundtrip byte-for-byte, in about a second, without downloading anything. It builds the model's real component classes at toy dimensions and pushes them through the real save/load code path.
When to Use
- You're asked to "make tiny test for
<model>" or add a fast twin of a slow save/load test. - You ported a new model (see
mflux-model-porting) and want cheap checkpoint coverage.
Related: mflux-testing for running the suite and golden-image rules.
Reference implementations
Read these before writing a new one — they are the source of truth:
tests/model_saving/tiny_checkpoint_helper.py— the shared harnesstests/model_saving/test_tiny_model_saving_ernie_image.py— components take explicit kwargstests/model_saving/test_tiny_model_saving_ideogram4.py— components take a Config dataclass
Do not trust code quoted in this skill over those files. The pattern landed as an RFC (PR #599, "proposal + demo on 2 models") and is expected to evolve.
Models that already have tiny tests: ernie_image, ideogram4.
What you write
One file, no src/ changes:
tests/model_saving/test_tiny_model_saving_<model>.py
The whole test is a single call into TinyCheckpointRoundtrip. The real work is figuring out how to build that model's components small. Match the two examples exactly:
- class
TestTiny<Model>ModelSaving - method
test_tiny_quantized_checkpoint_roundtrips_exactly, decorated@pytest.mark.fast - a
@staticmethod _tiny_components()returning the component dict - a comment naming the slow twin it mirrors
Instructions
1. Read the weight definition — it is the contract
src/mflux/models/<model>/weights/<model>_weight_definition.py
get_components() is authoritative: it gives the exact set of component names you must produce, and how many. While there, note two things:
quantization_group_size— a class attribute on the weight definition. Defaults to 64 but is not always 64 (booguuses 32). Every tiny dimension must be a multiple of this model's value. Check withgrep -n "quantization_group_size" src/mflux/models/<model>/weights/*.py.skip_quantization=Trueon any component (krea2andqweneach have one). In production,WeightApplier._quantizehonors this flag and leaves the component unquantized.TinyCheckpointRoundtrip._quantizedoes not — it callsnn.quantizeon every saved component regardless of the flag, so askip_quantizationcomponent comes out of the "saved" side quantized (withscales/biases) while the reloaded "fresh" side stays unquantized (noscales/biases). The helper's exact key-set comparison (saved_weights.keys() == fresh_weights.keys()) will then fail for that component. This is a real gap intiny_checkpoint_helper.py, not a quirk to work around in the test file — if you're writing a tiny test forkrea2,qwen, or any other model with askip_quantizationcomponent, stop and fixTinyCheckpointRoundtrip._quantizeto skip those components (mirroringWeightApplier._quantize) rather than special-casing it in the test.
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.
- 2mo ago First seen · 123 lines · 73 tokens per session scan A de0b9d53e7ed
mflux-model-tiny-test is a skill published in the GitHub repository mflux-community/mflux (2,547 stars, last pushed yesterday), licensed MIT. It adds 73 tokens to every session and 1,992 once invoked, about $0.0003 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-08-30.
Other skills, from other repositories
test-generation
Generate a test strategy and starter test stubs for given modules across unit, integration, and e2e layers (pytest/jest/playwright). Trigger on: generate tests, test plan, test strategy, coverage plan, test scaffolding.
verify-omnigent
Drive Omnigent the way a user does and prove a behavior with recorded evidence, using an isolated server, runner, and mock model plus a feature map of every user entry point. Load before reproducing a user-facing bug, before claiming a fix works, or when reviewing whether a change covered every surface (session vs.…
test-master
Generates test files, creates mocking strategies, analyzes code coverage, designs test architectures, and produces test plans and defect reports across functional, performance, and security testing disciplines. Use when writing unit tests, integration tests, or E2E tests; creating test strategies or automation…
migrate-xunit-to-xunit-v3
Migrate .NET test projects from xUnit.net v2 to xunit.v3 and fix v3 breaks. Use for package/CPM conversion, OutputType=Exe, preserving the VSTest or MTP runner (including projects currently using YTest.MTP.XUnit2), incompatible TFMs, async void tests, string-to-Type attributes, custom Fact/Theory/BeforeAfterTest…
go-testing
Trigger: Go tests, go test coverage, Bubbletea teatest, golden files. Apply focused Go testing patterns.
principle-test-behavior-not-implementation
Apply when you write, change, or keep a test. Assert what the code's users can observe, so that the test fails when that behavior breaks and keeps passing when only the internals change.