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.

How this site is produced

OpenSourcesAI is run by CJ Zwart, who sets the project's direction, decides what gets tested, listed and recommended, and approves every change before publication. AI assistants contribute to research, writing, development, testing and review under his direction.

Calculated by software

Compatibility Checker verdicts and VRAM requirements come from fixed rules applied to model file sizes read from the Ollama registry, or from the model's published files where Ollama has no tag. No AI model decides an individual verdict. Estimates on hardware pages we have not measured are worked out from file sizes and published specifications, and those pages say so.

Measured on our own hardware

A figure labelled as measured comes from a test run on a machine CJ owns. The measured hardware sections read their figures from recorded results and link the underlying files, and automated build checks compare those sections with the recorded data. Other pages may summarize measurements and link to the supporting evidence. We do not extend one card's results to another card. On tool pages, the label "Hands-on tested" appears only when a test run and its evidence files exist.

Guides, reviews and profiles

Guides, reviews, comparisons and directory profiles are prepared from the primary sources listed below. More than 40 automated checks run on every build, and some of them block publication outright, for example when a license is still an unverified placeholder. If you find a mistake, the corrections protocol below is the fastest way to get it fixed.

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 build fails if a monetized tool has no partner record, or if a record that needs a disclosure has no disclosure text. Each quarterly re-audit also requests every partner's own website. It does not open tracking links, because each one would record a false click with the partner.

Update cadence

Every quarter we re-check model availability and licenses, Ollama tags, MCP servers, whether the tool projects we list are still alive, prices, and partner websites. A script does the checking and a scheduled job files the report for review. Each finding is then fixed, dismissed with a reason, or listed below as still open.

Some checks run more often. A scan for new model and tool releases runs every week. GPU price ranges stop showing after 60 days without a re-check. Deployment risk records and MCP profiles carry their own review dates, and the site stops recommending them once those dates pass.

An updated date records when a page's content last changed. A review or test date appears only where the page says what was checked. Neither guarantees that downstream vendor or model details have not changed since.

Latest re-audit, completed November 5, 2026

• Models and licenses: 105 Hugging Face repositories checked. All are still readable, none changed its access rules, and every license we show agrees with the model card where the card names one. 7 repositories had updated their files, so we refreshed our pinned record of them.
• Ollama tags: All 123 tags the Compatibility Checker can suggest still match the Ollama registry.
• MCP servers: All 56 upstream packages and repositories were reachable. The AWS MCP Server profile had passed its review date, so we re-read its AWS sources on November 5 and updated it: AWS has added six Regions and removed the older call-aws tool. This was a review of AWS's documentation and its public tool list, not a signed-in test.
• Tool projects: 54 GitHub repositories behind live tool pages checked, and none has disappeared. Two are in decline, and their pages already say so: TGI is archived and GPT4All has had no code pushed since May 2025. On 5 November 2026 we read all 64 tool pages dated June or July 2026 against each vendor's or project's own pages. 49 needed corrections and now carry a November 2026 date. 15 needed none and keep their dates. 0 pages remain unreviewed. This was a review of sources: nothing was run. The largest corrections: Continue and AutoGen are no longer maintained, Chroma Cloud closes in December 2026, and Gemini CLI no longer has a free tier. The Continue and AutoGen pages stay live and say so, and Cline has replaced Continue on the homepage. The other pages on this site that named these tools were corrected the same day: they no longer recommend Continue, AutoGen, TGI or GPT4All for new work, and they call Windsurf by its new name, Devin Desktop.
• Prices: The 7 GPU price ranges were last checked 20 days ago. Four partner pages show price figures: ThorData, Browse AI, MeetGeek and AdCreative. On November 5 we compared each with the vendor's own pricing, and the figures all matched. AdCreative's free trial and credit wording had gone out of date, so we corrected it. The Grok 4.6 and Claude Code cost figures we show also still match their sources. Partner pages with no figures tell the reader to check the vendor, and we did not re-check their plan descriptions.
• Partners and disclosure (items still open): 34 partner websites requested and none has gone. 4 refuse automated requests (Gamma, Vultr, Lovable and Make), and all four loaded normally in a browser on November 5. The build check for disclosure records passes. Tracking links were not opened, because each one would record a false click with the partner. On November 7 the referral link in each program of our PartnerStack account was compared with the link on the site, and all 27 match. Seven links are outside that check and stay open: Dify, whose program page was not found in the account, CloudTalk (Introw), DigitalOcean (Awin), Lovable, Vast.ai, Vultr and Make.

The next re-audit is due in January to March 2027.

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.