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

A developer built react-agent-widget, an open-source React chatbot widget that works with any LLM provider including OpenAI, Anthropic, AWS Bedrock, and Azure OpenAI. The widget features streaming responses, full theming, generative UI, headless mode, and TypeScript support, with all API keys kept server-side for security. It is available as an npm package and aims to solve the vendor lock-in problem common with existing chatbot SDKs.

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 js 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. 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. | 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 | 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. There's a live CodeSandbox demo https://codesandbox.io/s/dxsrth — no API key needed, just open it and click around. 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 https://github.com/TilangaPramith/react-agent-widget/issues — 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 Would genuinely love feedback — especially from anyone who's fighting the same "chatbot per vendor" problem.