Claude on DNotifier: Setup Guide

Part of a series on running AI workflows across model providers — this one is about Claude.

The first time you wire an LLM into a real product, you learn a fast lesson: the model is maybe a third of the work. The rest is memory, retrieval, logging, and the quiet infrastructure that turns "it works in my terminal" into "it works for 10,000 users who all expect it to remember what they said five minutes ago."

This post is about that other two-thirds, specifically when Claude is the model doing the reasoning. If you already know why you want Claude — the writing quality, the long context window, the way it handles nuanced instructions without going off the rails — this is the part where we show you how DNotifier gets it into production without you building the plumbing yourself.

What sits between your app and Claude

DNotifier is the layer in between. Your code makes one call — notifier.sendAI() — and DNotifier takes care of routing that request to Claude, attaching session history if there's a conversation involved, pulling context from a knowledge base if you've connected one, and logging the exchange so it's visible in a dashboard instead of buried in a log file you'll only read after something breaks.

┌─────────────────────────┐
│   Your Application      │
│   notifier.sendAI()     │
└────────────┬────────────┘
             │
             ▼
┌────────────────────────────────────────────────────────────┐
│              DNotifier Foundation Layer                     │
│  Routing │ Session Memory │ Knowledge Base │ Logging       │
└────────────┬───────────────────────────────────────────────┘
             │
             ▼
┌─────────────────────┐       ┌──────────────────────────────┐
│       Claude        │       │  OpenAI, Gemini, Bedrock,    │
│  (active provider)  │       │  Ollama (alt providers)      │
└─────────────────────┘       └──────────────────────────────┘

Your code calls sendAI() once. Routing, memory, retrieval, and logging happen behind that call — the Claude request itself isn't something your application code has to construct by hand.

Notice the greyed-out boxes on the right. OpenAI, Gemini, Bedrock, Ollama — none of them are wired up in this example, but the same sendAI() call would reach any of them if you configured your app that way. Starting on Claude doesn't lock you into Claude. It just means Claude is what's answering today.

Getting connected

1. Create your app. Every DNotifier app comes with an appId and a secret, generated the moment you create it. Keep the secret server-side.

2. Add your Anthropic API key. In your app's dashboard, under the AI/Models section, connect Claude by pasting in your Anthropic API key. One-time setup — from then on, the model router knows where to send requests from this app.

3. Install the SDK.

npm install @dnotifier-realtime/dnotifier

4. Connect and send a prompt.

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

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

await notifier.connect();

const response = await notifier.sendAI({
  senderId: "user_204",
  message: { text: "Rewrite this paragraph so a tired reader still gets it in one pass." },
  saveHistory: true,
});

console.log(response);

No Anthropic SDK import, no manually shaping a messages array, no separate handling for whichever API version is current by the time you read this. sendAI() is the interface your code talks to. What's behind it is DNotifier's problem.

Picking a model, not just a provider

"Claude" isn't one thing anymore, and treating it like one thing costs you either quality or money. As of this writing, the lineup looks like this:

None of this is a ranking. It's a menu. A classification step that runs on every message doesn't need Opus 5's depth. A final answer a customer will actually read might be exactly where that depth earns its cost.

Testing before you commit

DNotifier's Prompt Testing Studio lets you run one prompt against several model configurations side by side and compare the actual outputs, cost, and latency — not a guess, a real comparison. Draft the prompt, pick your candidates (Sonnet 5 against Opus 5, or Claude against a model from another provider entirely if you've connected one), run it against inputs pulled from your real use case, and look at where the answers genuinely diverge. Most of the time the cheaper model handles the easy majority fine, and the expensive one earns its keep on the hard minority. This is how you find out which is which before your users do.

Memory that doesn't require you to rebuild the message array

Claude's context window is enormous — 1M tokens across the current lineup — but a big window and good memory management aren't the same thing, and conflating them gets expensive fast. DNotifier's session memory ties conversation history to a sessionId, so each new call in the same session already has the right prior context without your code reassembling it:

const sessionId = "chat-2291";

await notifier.sendAI({
  senderId: "user_204",
  sessionId,
  message: { text: "I need help drafting a response to an upset customer." },
  saveHistory: true,
});

// Later, same session:
await notifier.sendAI({
  senderId: "user_204",
  sessionId,
  message: { text: "Make it warmer, and shorter." },
  saveHistory: true,
});

The second call already knows what "it" refers to. You didn't have to store that yourself.

Grounding Claude in your own content

Claude is very good at reasoning over whatever you hand it and not very good at knowing things you never told it — your pricing page, your last product update, the exact wording of your refund policy. DNotifier's built-in knowledge base closes that gap: connect your documents, and relevant context gets pulled into sendAI() calls automatically, no separate vector database to stand up and maintain.

Watching what happened

Every call, every token, every response shows up in the observability dashboard when logging is on for your app. "The AI said something odd" stops being a shrug and starts being an actual session you can open and read.

Frequently asked questions

Which Claude model should I default to if I'm not sure?

Sonnet 5 is the reasonable starting point for most general-purpose work — strong quality at a price that doesn't punish you for using it on everything. Move specific steps up to Opus 5 or over to Fable/Mythos once you know, from testing, that they're worth it for that step.

Does a 1M-token context window mean I don't need session memory?

No — it means you can afford to be less careful about it, which is a different thing. Session memory keeps your calls efficient and your costs predictable even when the ceiling is high. We go deeper on this exact question in a companion post in this series.

Can I mix Claude with other providers in one app?

Yes. Model selection happens per app, and within a multi-agent workflow, per agent — so a Claude-powered writing step and an OpenAI-powered classification step can sit in the same pipeline if that's the right call for each job.

Is my data used to train Claude?

That's governed by your Anthropic account's terms and API agreement, not by DNotifier. We're the routing and infrastructure layer, not a party to that agreement — check Anthropic's current API data usage policy directly.

What's "adaptive thinking," and do I need to configure it?

Claude Fable 5.1 and Mythos 5.1 ship with always-on adaptive thinking, meaning the model adjusts how much reasoning it does based on the difficulty of the request, without you flagging it manually. Opus 5 has thinking on by default too. None of this requires configuration on your end through sendAI() — it's a property of the model you've selected.

The Bottom Line

If you're already calling Anthropic's API directly and starting to feel the weight of memory, retrieval, and observability piling up around it, this is the layer meant to take that weight off you. Next in this series: what DNotifier's MCP support actually does, and why the fact that Anthropic wrote the protocol matters more than you'd expect.

Explore DNotifier with Claude at dnotifier.com.