Testing standard
Every meaningful TokenByte review should identify the hardware, software, model or workflow, settings, measured result, and limitations. When a page is based on a planned test rather than a completed one, it should say so clearly.
Exact hardware, OS, drivers, model files, storage, cooling, and power context.
The prompt, ComfyUI graph, automation task, file set, or repeatable local model run.
Measured speed, memory or VRAM use, output quality notes, screenshots, and failure cases.
What reviews include
- Who the product or setup is for.
- Who should avoid it.
- Comparable alternatives.
- Original screenshots, photos, or measurements wherever possible.
- A clear buying verdict that does not hide drawbacks.
Benchmark queue
Queued benchmark rows are not performance claims. They are public test plans. A queued test can influence buying advice only after the exact setup, measured values, limitations, and evidence files are added to the public benchmark queue.
Evidence before rankings
A setup should not be called faster, better, or best until the matching benchmark queue entry has moved from queued to measured.
Affiliate policy
Affiliate links should support the recommendation, not drive it. TokenByte should disclose commissions clearly and place buying links near practical explanation, alternatives, and reasons not to buy.
Corrections and retests
If a reader sends evidence that a claim is wrong or stale, the affected article should be updated with the new context. If the claim depends on measured performance, the benchmark queue should move to retest instead of treating old numbers as current buying proof.