Hugging Face on DNotifier: Setup Guide

Part of a series on running AI workflows across model providers — this one's about the provider that isn't really one provider at all.

Every other provider in this series ships a handful of its own models. Hugging Face is different: it's a hub sitting on top of millions of models trained by thousands of different teams, plus a routing layer — Inference Providers — that gives you API access to a lot of them through one token. Connecting it to DNotifier opens up open-weight models alongside whatever proprietary providers you're already running, without a separate integration for each one.

What Hugging Face actually is, in practice

If you've only heard of Hugging Face as "the GitHub of AI models," that's directionally right but undersells what's changed recently. The Hub itself passed three million public models in August 2026, adding roughly three thousand more every day, with no sign of slowing down. Most of those models aren't ones you'll ever use — plenty are experiments, fine-tunes, and one-off research checkpoints. But a real and growing slice are genuinely production-worthy: open-weight language models, specialized embedding models, image and speech models, all downloadable or callable through a consistent API.

Inference Providers is the part that matters most for a DNotifier integration. Instead of hosting inference infrastructure yourself, it routes your request to one of sixteen-plus backing infrastructure providers — Groq, Together AI, Fireworks, Cerebras, and others — using a single Hugging Face token, with automatic failover if your first choice is unavailable. Hugging Face doesn't mark up the pricing; you pay the underlying provider's rate.

One token, one call, sixteen-plus backing providers behind it — DNotifier just sees one more connected model.

Step 1: Connect Hugging Face in the dashboard

Same pattern as every provider on DNotifier: Settings → Models, paste in a Hugging Face access token generated with inference permissions. No SDK changes.

Step 2: Install the SDK

npm install @dnotifier-realtime/dnotifier

Step 3: Make a call

import { DNotifier } from "@dnotifier-realtime/dnotifier";

const notifier = new DNotifier({
  appId: process.env.DNOTIFIER_APP_ID,
  secret: process.env.DNOTIFIER_SECRET,
  userId: "user-2210",
  transport: "ws",
  WebSocketImpl: WebSocket,
});

await notifier.connect();

const response = await notifier.sendAI({
  senderId: "user-2210",
  message: {
    text: "Summarize the tradeoffs between open-weight and closed AI models in two sentences.",
  },
  saveHistory: true,
});

console.log(response.text);

Nothing here names Hugging Face specifically — the model behind this call is whatever your app's configured to use, which is the whole point of routing it through DNotifier in the first place.

Choosing which model actually answers

This is where Hugging Face is genuinely different from the other providers in this series. There's no single "Hugging Face model" the way there's a Claude or a Gemini — you're picking a specific model from the Hub, identified by its repository path (meta-llama/Llama-3.1-70B-Instruct, openai/gpt-oss-120b, and thousands of others). Inference Providers lets you append a routing hint to that model ID:

That's a meaningfully different decision than picking between "Flash and Pro" — you're choosing both a model family and, often, a specific fine-tune or size variant within it.

A real use case: adding a specialized model without a new vendor relationship

Say your app already runs general text generation through Claude or Gemini, and you hit a narrow, specific need — say, classifying support tickets in a less common language your primary provider handles inconsistently, or running a specialized embedding model for a domain-specific search feature. Standing up a new vendor relationship for one narrow task is a lot of overhead for a single use case. Adding a Hugging Face-hosted model for just that one agent, while everything else stays on your primary provider, is a config change inside an app you already run:

const embeddingAgent = DNotifier.defineAgent({
  name: "domain-embedding-agent",
  model: "huggingface/BAAI/bge-large-en-v1.5",
  async run(ctx) {
    const embedding = await ctx.sendAI({ message: { text: ctx.input.text } });
    return embedding;
  },
});

One agent, one narrow job, no new integration to maintain outside the platform you're already using for everything else.

Session memory and knowledge base grounding

These work the same way they do for every other provider — tie a sessionId to a conversation for running history, and connect a knowledge base for RAG-grounded answers. Hugging Face models participate in both exactly like Claude, Gemini, or OpenAI models do; DNotifier's memory and retrieval layers don't care which provider is answering.

What to watch for with open-weight models specifically

Licensing varies model to model. Unlike a single vendor's terms of service, every model on the Hub carries its own license — some genuinely permissive, some with usage restrictions worth reading before you put a model into production. This is unique to the open-model world and worth actually checking, not assuming.

Quality varies a lot more than the provider name suggests. "A Hugging Face model" tells you almost nothing about capability — you're choosing a specific model, and the gap between a well-regarded 70-billion-parameter release and an obscure fine-tune is enormous. Test before you commit.

Not every model is available through every backing provider. Inference Providers' coverage differs by model — a niche or very new model might only be served by one or two of the sixteen-plus providers, which matters for the failover story described above.

Frequently asked questions

Do I need a paid Hugging Face plan to use this through DNotifier?

No — Inference Providers includes a free usage tier, though production traffic at real volume will want to understand the underlying provider's rate limits and pricing, since Hugging Face passes those through without markup.

Can I mix a Hugging Face model with Claude or OpenAI in the same app?

Yes — this is exactly the scenario in the use case above. Model selection happens per agent, so a single DNotifier app can route different tasks to whichever provider and model actually fits.

How do I know which model to actually pick from three million options?

Start narrow — search the Hub filtered by task type and sort by downloads or likes as a rough popularity signal, then test the top few candidates against your actual data rather than picking on reputation alone. We go deeper on this in a later post in this series.

Does DNotifier support Hugging Face's dedicated Inference Endpoints, not just the serverless routing?

The setup here covers Inference Providers, the serverless multi-vendor routing layer. Dedicated Endpoints are a different deployment model, covered later in this series, and can be pointed to from DNotifier the same way any custom inference URL would be.

Is switching from one Hugging Face model to another disruptive?

Not at the application level — it's a model-ID change in the agent definition, the same kind of small, isolated change as adjusting which Claude or Gemini variant an agent uses.

The Bottom Line

Next in this series: what "open weights" actually means, and the honest tradeoffs against a closed, proprietary model API.

Read part two: Open Weights vs. Closed APIs, Explained. Explore dnotifier.com.