I built a drop-in AI chatbot widget for React that works with any provider — here's why

Tilanga Pramith — Wed, 01 Jul 2026 09:56:12 +0000

The problem

Every time I wanted to bolt an AI chatbot onto a React app, I hit the same wall: either I locked myself into one vendor's SDK (OpenAI's widget, Anthropic's whatever-they-ship), or I built the streaming UI, the theming, the floating launcher button, and the SSE parsing again, from scratch, for the third time this year.

So I built react-agent-widget — a chat widget that doesn't care which LLM is on the other end.

npm install react-agent-widget

Quick start — 10 lines

import { AgentWidget, createHttpAdapter } from 'react-agent-widget'

const adapter = createHttpAdapter({ url: '/api/chat' })

export default function App() {
  return (
    <AgentWidget
      adapter={adapter}
      welcomeMessage="Hi! How can I help you today?"
    />
  )
}

That's it. A floating chat button shows up bottom-right, streaming responses token by token, no extra CSS files, no config.

Why "any provider" matters

Most chatbot widgets I found were tied to one API. The moment you want to switch from OpenAI to Claude, or move to Bedrock because your infra team lives on AWS, you're rewriting the integration layer. react-agent-widget ships adapters for the providers people actually use:

// OpenAI
createOpenAIAdapter({ proxyUrl: '/api/openai', model: 'gpt-4o' })

// Anthropic Claude
createAnthropicAdapter({ proxyUrl: '/api/anthropic', model: 'claude-3-5-sonnet-20241022' })

// AWS Bedrock
createBedrockAdapter({ proxyUrl: '/api/bedrock', model: 'anthropic.claude-3-5-sonnet-20241022-v2:0' })

// Azure OpenAI
createAzureOpenAIAdapter({ proxyUrl: '/api/azure', deploymentName: 'gpt-4o' })

Every adapter points at a proxy endpoint you control — your server attaches the API key, the SigV4 signature, or the managed identity. No credentials ever ship to the browser. That's a deliberate design choice, not an afterthought — I've seen too many "quick" chatbot integrations leak keys in client bundles.

What's actually in the box

Feature	Why it matters
Streaming responses	Built-in SSE parser, token-by-token rendering — no janky "wait for the whole reply" UX
Fully themeable	CSS custom properties — every color, radius, shadow, and font is overridable, no CSS-in-JS runtime
Generative UI	The agent can render actual React components (cards, forms, charts) inside the chat, not just text
Headless mode	Don't like the default UI? Use the state/streaming hooks and build your own
TypeScript-first	Full type safety across the public API
SSR-safe	No `window` access at render time — works cleanly with Next.js App Router
Lightweight	~44KB minified ESM, zero mandatory runtime deps beyond React 18

Theming without fighting CSS-in-JS

Everything is scoped behind a raw- class prefix, so it won't collide with your existing styles, and it's themed entirely through CSS variables:

:root {
  --raw-primary-color: #6366f1;
  --raw-border-radius: 12px;
  --raw-font-family: 'Inter', sans-serif;
}

No runtime style injection, no specificity wars.

Try it without installing anything

There's a live CodeSandbox demo — no API key needed, just open it and click around.

Where it's headed

This is a fresh 0.1.x release, so I'm actively hardening it — better test coverage, more generative UI examples, and I'm looking at a React Native port next since I'm already deep in that ecosystem for another project. If you try it and hit something rough, open an issue — I'm reading all of them.

If you're building anything that needs an AI chat surface in a React app and don't want to be married to one vendor's SDK, give it a spin:

npm install react-agent-widget

📦 npm
💻 GitHub
🧪 Live demo

Would genuinely love feedback — especially from anyone who's fighting the same "chatbot per vendor" problem.

DEV Community: Tilanga Pramith