How OpenSourcesAI evaluates models, tools, and hardware claims.

Scope of coverage

OpenSourcesAI covers tools and models that operate in the local AI, open-weight, self-hosted, and developer-controlled inference stack. This includes local model runners, model-serving runtimes, vector databases, RAG frameworks, coding assistants, agent frameworks, AI infrastructure, document processing pipelines, and embedding workflows.

Hosted frontier models and commercial SaaS tools may appear in the directory when they serve a genuine AI-builder workflow alongside open-source alternatives. They are always labeled and structurally separated from open-source editorial content.

Hardware compatibility analysis protocol

All model hardware compatibility assessments on OpenSourcesAI are derived from physical memory boundary analysis, not from vendor marketing sheets or community rule-of-thumb estimates. The methodology follows three layers:

1. Weight VRAM estimation

VRAM consumption is calculated from parameter count and quantization format using empirical bits-per-weight coefficients derived from llama.cpp and similar runtime measurements: FP16 at 16 bits per weight, Q8_0 at 8.5 bits, Q4_K_M at 4.85 bits, Q3_K_M at 3.91 bits. The formula is: (parameters_billions × bits_per_weight) ÷ 8 = weight_vram_gb. These are effective bits, not nominal ones: K-quants store per-block scale and minimum metadata alongside the weights, so a Q4_K_M checkpoint measures above 4 bits per weight in practice. Using the nominal 4 bits instead of 4.85 understates real weight VRAM by about 17 percent.

2. Runtime overhead

A fixed runtime overhead of approximately 1.5 GB is added above the weight estimate to account for activations, KV-cache initialization, and runtime bookkeeping. Context-dependent KV-cache growth is noted separately when context window length materially affects fit (particularly for RAG workflows using 32K+ token contexts).

3. Fit grading

Configurations are graded: comfortable when available VRAM exceeds total required by 2 GB or more; tight when VRAM exactly covers the requirement; partial when VRAM is insufficient but system RAM at 1.6× the bare weights can support CPU offload; too large otherwise. Partial fits are flagged as CPU offload paths with an explicit throughput warning (typically 1–5 tokens per second). The offload check deliberately uses bare weights rather than the full requirement: the runtime overhead is already resident in VRAM, so charging it again to system RAM would count it twice and rule out configurations we have measured running.

Where vendor documentation conflicts with empirical VRAM estimates, we note the discrepancy on the affected page rather than silently deferring to either source.

Tensor execution and quantization limits

Quantization format eligibility is evaluated against hardware constraints before a format is recommended. The selection order for a given VRAM budget follows: FP16 → Q8_0 → Q4_K_M, stopping at the highest-fidelity format that fits the available VRAM. Formats below Q4_K_M (Q3, Q2) are noted as available but are not recommended as primary formats due to measurable generation quality degradation at those bit depths.

Attention mechanism overhead scales with context window length and is not included in base VRAM estimates. For models with 128K or larger context windows evaluated in long-context workflows, this is called out explicitly in the hardware compatibility notes.

Multi-GPU configurations are not treated as linearly additive VRAM pools in compatibility assessments. A dual-GPU setup requires tensor parallelism support from the serving runtime (such as vLLM or TensorRT-LLM) to pool memory across devices. This limitation is surfaced in the compatibility checker output for any multi-GPU preset.

Openness classification

• Open source: Source code is publicly available under a recognized OSI-approved license. The license governs redistribution, modification, and commercial use explicitly.
• Open weight: Model weights are downloadable and redistributable, but training data, architecture source, or commercial use rights may be partially or fully restricted. The weight license governs deployment — not the base model name.
• Open core: A usable open-source component exists, but a hosted layer, managed tier, or enterprise feature set is commercial. The open component is evaluated on its own merit; hosted tiers are labeled separately.
• Source available: Code or weights can be inspected but do not qualify as open source under OSI definitions. Usage rights, modification terms, or redistribution restrictions prevent open classification.
• Commercial: Proprietary hosted or packaged software. Listed when it solves a genuine AI-builder workflow and is clearly labeled as commercial. Commercial status is visible in all directory cards and comparison matrices.

License classification is derived from the actual license file in the model or software repository — not from the project's self-description. When a project describes itself as open source but ships under a license that restricts commercial use, modification, or redistribution in ways inconsistent with OSI definitions, it is classified as source available and labeled accordingly.

Source hierarchy and validation protocol

Accepted primary sources

• Official project documentation and vendor docs (authoritative for pricing, limits, and supported features)
• GitHub repositories, release notes, and changelog history (authoritative for version-specific behavior)
• Hugging Face model cards and safetensors metadata (authoritative for parameter count, architecture, and license)
• Primary provider announcements and technical reports (authoritative for capability claims)
• License files — not README descriptions of license intent (authoritative for commercial use rights)

Not accepted as primary sources

• Vendor marketing PDFs or product briefs without primary documentation corroboration
• Third-party benchmark summaries without access to the underlying methodology
• Community posts for pricing, context window, or hardware requirement claims
• Model name descriptions as a proxy for actual license file terms
• GitHub star counts, download totals, or other popularity metrics as evidence of quality, adoption, or production readiness

Claims about hardware requirements, VRAM ceilings, context window limits, supported quantization formats, and license terms require a primary source citation before publication. Claims that cannot be traced to a primary source are withheld rather than published with a caveat. This is enforced rather than aspirational: a build gate blocks publication outright when a license field is left as an unverified placeholder, and catalog entries that have not been reviewed are held out of the Compatibility Checker rather than shown with a warning. Where we have no verified answer, the surface says so and recommends nothing.

Affiliate isolation architecture

OpenSourcesAI operates a three-registry content architecture to prevent commercial relationships from contaminating editorial signal:

Registry 1 — Open-source editorial

Tools and models evaluated purely on technical merit against open-source or open-weight criteria. No affiliate links appear in this lane. Rankings, comparisons, and guide conclusions in this registry are not influenced by commercial relationships.

Registry 2 — Commercial tool directory

Commercial and proprietary tools listed for workflow completeness. Clearly labeled as commercial on every card and page. May include affiliate links. Commercial listing does not imply editorial endorsement beyond the documented workflow fit assessment.

Registry 3 — Partner and affiliate placements

Tools with active affiliate or partner relationships. Every page carrying a partner link displays a disclosure statement. Partner status is stored in the partner registry and injected into pages automatically — it is not an ad-hoc editorial decision. Partner status does not unlock access to the open-source editorial lane, suppression of competitors, or editorial copy approval.

The affiliate link registry is audited quarterly alongside content to confirm tracking URLs remain active, correctly attributed, and disclosed on every page where they appear.

Update cadence

The site runs a quarterly re-audit covering model availability, licensing changes, runtime compatibility, pricing tier updates, and partner disclosure accuracy. Pages surfacing pricing, context windows, license terms, or VRAM specifications are prioritized in each cycle because those fields change most frequently in the open-weight and commercial AI ecosystem.

Pages include a verified or updated date. That label reflects the last time the page was reviewed against available public information — it does not guarantee that downstream vendor or model details have not changed since that review.

Corrections protocol

• Submit the page URL, the incorrect claim, and a link to the primary source that contradicts it.
• Corrections are prioritized in this order: hardware specifications, license terms, pricing, context window limits, safety notices, then general factual errors.
• Material corrections are applied with a dated note on the affected page. Silent overwrites are not used where the error could have influenced a deployment decision.
• Corrections that arrive without a primary source citation are reviewed but may take longer to process.
• Vendors may submit corrections through the free standard lane or the paid Expedited Editorial Review lane. Payment changes queue position, never the outcome — every correction, regardless of tier, is evaluated against primary sources independently before it is applied.

Logo and trademark note

Tool, model, and integration logos or favicons are used only to help readers recognize projects and products in directory cards. Trademarks and logos belong to their respective owners. Inclusion does not imply endorsement by the trademark owner of OpenSourcesAI content.