notes.aimodels.fyi

AIModels.fyi has published an open invitation for builders to submit their AI tools to the site, announced in a "Build In Public" post titled "You're invited to submit your AI tool to AIModels.fyi" (dated Mar 19, 2024). To submit, start from that post in the Build In Public section of notes.aimodels.fyi — it is the site's stated entry point for getting a tool considered for listing. The site does not publish the exact submission form fields or review timeline in the material available here, so treat the post itself as the source of the current requirements before you prepare anything.

Where to Find the Submission Invitation

The invitation lives in the Build In Public section of the site, alongside other behind-the-scenes posts such as "Transforming Spaces with Artificial Intelligence" and "Different now." The site's navigation lists these sections:

Open Build In Public, then select the post "You're invited to submit your AI tool to AIModels.fyi." That post is where the site explains what it wants from submitters.

What to Prepare Before You Submit

Because the post is the authoritative source, read it first and follow whatever it asks for. In the meantime, you can get ahead by assembling the material a model directory typically needs — and that AIModels.fyi's own framing suggests:

• A clear name and one-line description of what your tool does, in plain English. The site's editorial style favors plain-language explanations (see its "Plain English Papers" section).
• The problem it solves and who it's for. The site's stated purpose is helping people "find the right one for your project," so describe the project types your tool fits.
• A working link to the tool or its documentation.
• Any notable capability or result worth highlighting — for example, a benchmark, a demo output, or a use case writeup.

If your tool has a public writeup or tutorial, that maps well onto the site's existing Guides format, which covers concrete tasks like turning audio into a waveform or swapping faces with a specific model.

How the Review Likely Works

The material available does not describe an approval process, acceptance criteria, or response time. What is documented is that the site actively curates and publishes tool- and model-focused content, and that it explicitly invites submissions. A reasonable expectation, based on how the site is organized, is that accepted tools would appear in its searchable model database or be covered in a post — but confirm this with the site rather than assuming a listing is guaranteed.

Common Pitfalls

• Submitting without reading the invitation post. The post is the only documented channel; skipping it means guessing at requirements.
• Vague descriptions. The site's audience is looking for a model that fits a specific project. A description that names the task, the input, and the output is more useful than a slogan.
• Assuming submission equals listing. No source here promises publication, so plan to follow up through whatever contact route the post provides.

If you want a model of the site's preferred depth, read one of its Guides (such as the Audio-To-Waveform tutorial) before writing your own description — it shows the level of concrete, step-level detail the editors tend to publish.

AIModels.fyi publishes hands-on, model-specific tutorials and practical AI engineering guides rather than general news or opinion pieces. The Guides section focuses on showing readers how to use a particular model or technique to complete a concrete task—from converting audio into a waveform to swapping faces in images—alongside product-oriented pieces on turning models into usable applications. If you want step-by-step walkthroughs tied to specific AI models, this is the section to check; if you want research summaries, the Plain English Papers section is the better fit.

The main guide formats

Based on the published entries, the Guides section clusters into three recognizable types:

1. Model-specific how-to tutorials

These walk through using a named model for a defined output. Examples visible on the site include:

• Audio-To-Waveform — turning spoken audio or music into a waveform using a simple AI model.
• Faceswap — swapping faces seamlessly with the Faceswap model.
• JoJoGAN — one-shot face stylization.
• Stable Diffusion Img2Img — an introduction to image-to-image generation.

The pattern here is: pick one model, describe the task it solves, and show the reader how to get a result. These are the closest thing to copy-and-follow tutorials on the site.

2. Technique and method guides

These are less about a single model and more about a workflow or method you can apply across projects. Examples include:

• Hypothetical document embeddings (HyDE) for improving semantic search.
• AI-driven categorization — moving "from chaos to clarity."
• Step-by-step reasoning applied to vision AI.

These guides explain a mechanism and then show how to apply it, which makes them useful when you already have a pipeline and want to improve one stage of it.

3. Product-building guides

A smaller set focuses on the jump from model to shipped product:

• "From AI Models to AI Products: Turning Intelligence into Impact."
• "Build Your Own Epik-inspired App" — transforming selfies into '90s yearbook photos with Node.js and AI.

These are aimed at readers who already know which model they want and need help wrapping it into an application.

How to choose which guide to read

What the guides are not

Two boundaries are worth setting before you dive in:

• They are not research summaries. That content lives under Plain English Papers, which covers papers like Netflix's VOID video-editing work or SmolDocling. If you want to understand a paper's contribution, start there instead.
• They are not a model directory. The site's core function is searching, filtering, and sorting a database of AI models. Guides sit alongside that directory as applied walkthroughs, not as replacements for it.

Practical note on scope and freshness

The Guides list mixes recent entries (April 2026) with older ones (2023), so coverage is not uniformly current—check the date on a guide before assuming it reflects the latest model versions or library APIs. The site also signals a subscription option, so some content or features may sit behind an account; the public listing itself does not state which guides, if any, require it.

If your task is "learn to run model X end to end," start with the model-specific tutorials. If your task is "make my existing system better," the technique guides are the more direct route.

AIModels.fyi is a site for finding AI models to use in a project: it lets you search, filter, and sort through a large database of models. It also publishes editorial content in five sections — Latest, Plain English Papers, Guides, Build In Public, and News — so it works both as a model-discovery tool and as a source of practical AI writing. It is most useful if you already have a task in mind (image generation, document understanding, semantic search) and want to locate a model or read a walkthrough before committing.

What you can do on the site

Find a model for a specific task

The core function is narrowing a large model catalog down to candidates. The site describes itself as a way to "search, filter, and sort through a vast database of AI models" to "find the right one for your project." In practice, that means starting from your task constraints rather than browsing aimlessly.

A workable approach:

1. Write down the task and its hard constraints (input type, output type, size or speed limits).
2. Search on the task terms, then use filters to cut the list.
3. Sort the remaining candidates by whatever matters most to you.
4. Read the linked write-up, if one exists, before testing.

Expected result: a shortlist you can evaluate, not a single "best" answer — the site provides the catalog and filters, and the judgment about fit is yours.

Read up before you build

The editorial sections cover different needs:

Examples from the page show the range: a guide on turning spoken audio or music into a waveform with an Audio-To-Waveform model; a plain-English summary of Netflix's VOID, which treats object removal in video as a causal simulation rather than pixel patching to avoid "ghost" physics in edited scenes; and a guide on improving semantic search with hypothetical document embeddings.

How to get the most out of it

• Match the section to your stage. If you are still choosing an approach, start with Plain English Papers; if you have picked a model and need to implement it, go to Guides.
• Treat guides as starting points, not specifications. A guide shows one working path; check the model's own documentation for current inputs and limits before relying on it.
• Use Build In Public for product-level lessons. These posts describe how sites and tools were assembled, which is useful for the gap between "a model works" and "a product ships."
• Expect a mix of dates. The page lists items from 2023 through 2026, so check the date on any guide before following it — older tutorials may reference tooling that has since changed.

Limits worth knowing

The site is a discovery and editorial layer, not a model host or benchmark authority. It does not, on the evidence available, publish standardized performance comparisons you can rely on for a final decision, and the page does not state pricing for any model or for the site itself. The site references subscribing and uses Stripe for payments, which indicates paid options exist, but the specific terms are not described here — check the site directly if cost matters for your choice.

For a quick decision: use AIModels.fyi when you need to locate candidate models for a defined task or want a plain-language explanation of a paper or technique. Do not use it as your only source for performance claims or licensing terms; verify those with the model's own documentation.

AIModels.fyi is built around a searchable, filterable, and sortable database of AI models, so the practical way to find the right one is to define your project's task, modality, and constraints first, then use search and filters to narrow the list, and finally review model details before committing. This approach works best when you already know the job the model must do (for example, image generation, document understanding, or audio-to-waveform conversion) and are choosing among candidates rather than browsing for inspiration.

Start with a clear model brief

Before touching the search bar, write down three things:

• Task type — what the model must actually do. The site's own coverage spans very different jobs, from Stable Diffusion Img2Img for image generation to SmolDocling for document understanding to an audio-to-waveform model for turning sound into sight.
• Modality — text, image, audio, video, or documents. Mixing modalities in your search terms is the most common reason results feel irrelevant.
• Constraints — size, speed, licensing, or deployment environment. The site highlights compact options (SmolDocling is described as an "ultra-compact VLM"), which matters if you are deploying to limited hardware.

A one-paragraph brief like this turns a vague "find me an AI model" into a filterable query.

Use search, filter, and sort in that order

The site's stated purpose is to "search, filter, and sort through a vast database of AI models." Treat those as three distinct steps:

1. Search with the task and modality from your brief, not with product names. Searching "document understanding" is more productive than searching a model you half-remember.
2. Filter the results down using your constraints. Filters are where you eliminate candidates that cannot fit your deployment or input type.
3. Sort the remaining list by whatever matters most to your project — recency, popularity, or relevance — so the top of the list reflects your priority, not the site's default.

If a search returns nothing useful, loosen one dimension at a time (drop the constraint, then the modality) rather than rewriting the whole query.

Review model details before choosing

Search results are a shortlist, not a decision. Before picking a model, check:

• What the model was trained for — a model that performs well on one task may be the wrong fit for an adjacent one.
• Input and output format — confirm it accepts the data you have and returns what your pipeline needs.
• Size and resource expectations — compact models trade capability for deployability; decide which side of that trade you need.
• Recency and activity — the site's Latest and Plain English Papers sections show what is currently being discussed, which helps you judge whether a model is current or superseded.

The site also publishes plain-English explanations of papers and guides, such as its walkthrough of turning spoken audio or music into a waveform with a simple AI model. Reading the companion explainer for a candidate model is often faster than reading the paper itself and tells you whether the model's approach matches your problem.

Use the site's editorial sections as a second pass

Beyond the model database, AIModels.fyi organizes content into sections that help with selection:

For example, if your project needs to convert speech to a visual waveform, the Guides section's audio-to-waveform walkthrough is a more direct starting point than a raw database search, because it shows the model in use.

Common sticking points

• Searching by brand instead of capability. You will miss better-fitting models that you have never heard of.
• Skipping the brief. Without defined constraints, filters have nothing to filter against and you end up comparing incomparable models.
• Treating the top result as the answer. Sorting changes the top result; make sure the sort order matches your actual priority.
• Ignoring the explainer content. A five-minute read of a plain-English summary can save you from adopting a model built for a subtly different task.

What this site is and is not

AIModels.fyi is a discovery and evaluation resource: it helps you search, filter, sort, and understand models. It is not a guarantee that any listed model is production-ready for your specific use case, and the site's materials do not establish pricing or access terms for individual models — check each model's own documentation for licensing, cost, and usage limits before you build on it.

The Plain English Papers section on AIModels.fyi is a blog category that summarizes AI research in accessible language, aimed at readers who want research insights without reading full technical papers. Each entry takes a paper or research development and explains its core idea in plain terms, often with a short takeaway in the subtitle. It suits practitioners, product builders, and curious readers who want to keep up with AI research but don't need the full academic treatment.

What the section covers

Based on the posts listed on the site, the section spans model architecture, generative media, and applied AI research. Examples include:

• Video editing and physics — "Netflix's VOID shows video editing has finally learned the laws of physics," which frames object removal as a causal simulation rather than pixel patching, eliminating "ghost" physics from edited scenes.
• Model architecture — "Simplifying transformer blocks," a look at streamlining the building blocks of transformer models.
• Document understanding — "SmolDocling: An Ultra-Compact VLM for Document Understanding," covering a compact vision-language model for documents.
• Model evaluation and prompting — posts such as "What's the best AI model to handle $1 million in freelance software engineering?", "Creating artificial doubt significantly improves AI math accuracy," and "Step-by-step reasoning can fix madman logic in vision AI."
• Tokenization — "All LLMs use tokenization. Are we doing it totally wrong?"

The common thread is a research finding or technical mechanism, restated so a non-specialist can follow the idea and its implications.

Who it's for

The section fits three kinds of readers:

1. Builders and product people who need to know what a new technique does and whether it matters for their work, without parsing the full paper.
2. Readers tracking the field who want a regular digest of notable research across image, video, document, and language models.
3. Anyone deciding whether a paper is worth a deeper read — the plain-English summary acts as a filter before committing to the original.

It is less suited to readers who need implementation details, benchmark tables, or reproduction steps; those belong in the full papers or in the site's Guides section, which covers hands-on topics like turning audio into waveforms or improving semantic search with hypothetical document embeddings.

How it relates to the rest of the site

AIModels.fyi organizes its content into several sections visible on the homepage: Latest, Plain English Papers, Guides, Build In Public, and News. The distinction matters when choosing where to look:

If your goal is to understand a research idea, start with Plain English Papers. If your goal is to build something, the Guides section is the better entry point.

Practical tips for using the section

• Scan subtitles first. Posts often carry a one-line takeaway under the title (for example, the VOID post's note on eliminating ghost physics), which tells you quickly whether the topic is relevant.
• Use it as a triage step. Read the summary, then decide whether to open the original paper for methods and numbers.
• Check dates. The listed posts span from 2024 into 2026, so research coverage is ongoing; sort by recency if you need the current state of a topic.
• Cross-reference with Guides. When a summarized technique looks useful for a project, look for a corresponding hands-on guide before attempting implementation.

The section is a reading aid, not a substitute for primary sources — treat each post as a map of the idea, and go to the paper when you need the details.