Machine first
A local test record should name the hardware or container limit before it names a model pick.
Editorial Policy
How AI Jupyter keeps test records and model picks checkable
Last updated: June 17, 2026. This policy explains how AI Jupyter selects sources, handles local test records, uses AI-assisted research, corrects mistakes, and keeps model picks from sounding more certain than the evidence allows.
Editorial principles
- Local LLM test pages start with the machine, settings, screenshots, measured speed, memory pressure, and slow boundary.
- Keep source coverage visible when evidence is uneven.
- Use official provider pages for API price rows whenever possible.
- Separate real machine tests, model quality, API cost, local hardware fit, and where the model is available.
- Treat every model score page as a list of models to test, not as a final answer.
Local LLM test record rules
A local test page should not ask the reader to trust a model name alone. The record has to show what ran, where it ran, how it was configured, what the machine did, and where the result stopped being practical.
Raw proof stays close
Screenshots, command output, Docker notes, nvidia-smi evidence, and test JSON should stay near the model pick when available.
Speed is not enough
Tokens per second is useful, but the page also needs memory pressure, headroom, repeated-turn behavior, and the slow boundary.
Retest path
A reader should leave knowing which smaller or larger model to try next on their own prompt.
Source selection
Local test pages use the test record itself as the primary source: hardware limit, runtime, settings, screenshots, raw notes, measured speed, and memory behavior.
Model score pages use public leaderboards, independent benchmark sites, task-specific evaluations, and official model or product pages when they are relevant to the query. A coding page gives more weight to coding benchmarks; an image page gives more weight to visual preference and image-generation evaluations.
API pricing pages use official provider pages and docs as the source of record. Aggregators, routers, and resale APIs can be useful market context, but they are not treated as official price rows.
Collect evidence
Gather local test notes, screenshots, raw command output, public benchmark rows, official provider pages, pricing pages, and local model metadata relevant to the page.
Normalize carefully
Keep original units visible, then add comparable fields only where the conversion is safe enough to explain.
Write for the next check
Explain what a reader should inspect next: the test record, source date, price row, local prompt, hardware limit, or official evidence.
Review before publishing
Check dates, source links, obvious source contradictions, unsupported claims, and whether the page overstates certainty.
AI assistance and human review
AI tools may help with crawling, deduplication, summarization, translation, table cleanup, and first-draft wording. They should not be treated as a source of truth. They also should not invent local test results. The useful standard is simple: a reader should be able to inspect the source trail, understand the reasoning, and decide what still needs their own testing.
When a claim depends on a release date, model availability, official price row, or benchmark result, the page should point back to a source or make the uncertainty clear. If the evidence is weak, the language should be weaker too.
Corrections and update cadence
AI model releases, benchmark pages, API prices, local test records, and local model metadata change frequently. Source pages and snapshots are checked by the site workflows where automation exists, and high-impact pages are revised when new evidence changes the decision a reader would make.
For corrections, send the details to james.jupyter@gmail.com. Helpful correction requests include:
- Page URL
- Model or provider name
- Official source or benchmark link
- Screenshot, log, or test JSON if the issue involves a local test record
- Date observed
- What should be changed and why
Limits, disclosures, and trademarks
AI Jupyter is independent and is not affiliated with Google, OpenAI, Anthropic, Meta, Mistral, xAI, Moonshot AI, or benchmark providers unless explicitly stated. Product names, model names, company names, and logos belong to their respective owners and are used for identification and comparison.
Model score pages are not financial, legal, procurement, safety, or compliance advice. They are decision aids. Local test records are hardware snapshots, not speed guarantees. Readers should verify licensing, privacy, security, data retention, latency, pricing, and real behavior before relying on any model.
Editorial FAQ
Does AI Jupyter use AI to help create pages?
AI may help collect, compare, and summarize public information, but pages should keep human editorial judgment in the loop. Claims should be tied to sources, softened when evidence is weak, and removed when they cannot be checked.
How are local LLM test records edited?
They should preserve the machine or container limit, runtime, settings, screenshots or raw proof, measured speed, memory behavior, and the point where the model stops feeling practical.
How are missing benchmark rows handled?
Missing rows lower confidence or source coverage. They should not automatically count as zero unless the source clearly defines absence that way.
Are API prices guaranteed?
No. AI Jupyter keeps official source links and checked dates, but provider pricing can change. Readers should open the official provider page before production routing, procurement, or publishing a comparison.
Can a provider pay to improve a score or placement?
No paid placement should override the scoring method or editorial judgment. Advertising or affiliate relationships must be disclosed separately from model scoring logic.