Deep Chat: a web component for wiring an AI chat UI to any model API

The gap Deep Chat fills between a model API and a rendered conversation

Calling a model API is a few lines of code. Building the thing around it is not. You need a scroll container that behaves when messages stream in, an input that grows, file and image attachments, a microphone button, a loading indicator, markdown and code rendering, and a way to swap the backing service without rewriting the view. Deep Chat packages that surface as a custom element you drop into markup.

The intended user is a front-end or full-stack developer adding a chat panel to a product that already exists. The component is framework-agnostic: the README lists support for all major UI frameworks, and a separate deep-chat-react package exists for React projects. It is not aimed at people who want a chatbot they can configure without writing code. There is no hosted backend here, and the README points at server template examples rather than a managed service.

How the request property, interceptors and directConnection move a message

The component owns the conversation state and the rendering. Everything about the network call is configuration. The primary mechanism is the request property, which takes the API details of the service you want to talk to. The README gives this example:

<deep-chat request='{"url":"https://service.com/chat"}'/>

The service on the other end has to accept the request and response formats Deep Chat uses. That is the real integration cost: the component does not adapt itself to an arbitrary API, the API has to meet it, or you have to bridge the difference. The README offers two bridges. Interceptor properties augment the objects being transferred, so you can reshape a payload on the way out or a response on the way in. A handler function takes over the request code entirely, which is the escape hatch when neither the default format nor an interceptor is enough.

The second path is directConnection, which calls popular AI APIs from the browser without your own server in the middle. The README shows `directConnection='{"openAI":true}'` and an object form where a key can be supplied. Release 2.5.0 added Requesty, LiteLLM and Dify to this list, and the README claims more than 20 supported APIs. The trade-off is structural, not incidental: a browser-side connection means the credential travels through the client, and the README does not present a mechanism that hides it. Treat directConnection as a fit for local prototypes, internal tools, or providers where you are comfortable with that exposure, and use request plus your own endpoint for anything public.

Streaming is handled at the connection layer rather than the view. The 2.2.0 notes mention connecting to Readable Stream APIs, and a response is allowed to contain multiple messages. Speech has its own path: the OpenAI Realtime API integration arrived in 2.2.0 for speech-to-speech, alongside the speech-to-text input and text-to-speech output features listed in the main feature set.

Installing deep-chat and sending a first message

Install from npm. Use the plain package for framework-agnostic setups and the React package when you are in a React app.

npm install deep-chat

npm install deep-chat-react

Then place the element in your markup. The README shows the minimal form as an empty tag, and notes that the exact syntax depends on your framework, with a frameworks examples page linked from the README.

<deep-chat></deep-chat>

At this point you should see the chat interface render, but sending a message will not reach a model until you configure a connection. The smallest real setup points request at an endpoint you control. The README's example uses a placeholder URL, so substitute your own service address.

<deep-chat request='{"url":"https://service.com/chat"}'/>

Your service must speak the request and response formats described in the Connect section of the documentation. The repository includes example-servers for this purpose, and the README links to server templates. If you would rather test against a provider without writing a server, the directConnection form is shorter, but read the credential caveat above first. The README also points at an llms.txt file for configuring the component with a code assistant, which is a reasonable way to get a starting configuration if you would rather not read the property list.

Where Deep Chat is the wrong choice

The component assumes a browser. If your chat needs to run in a terminal, in a backend job, or inside a native mobile shell, nothing in the repository addresses that, and the README's feature list is entirely about a rendered interface.

The second limitation is the contract with your service. The README states plainly that the service will need to handle the request and response formats used in Deep Chat. If your existing API returns a shape the component does not expect, you are writing an interceptor or a handler, and at that point you are maintaining adaptation code that has nothing to do with your product. Teams with a strongly opinionated internal chat protocol may find the handler path easier than fighting the default format, but it is still work.

The third is scope. Deep Chat is a UI component with connection plumbing. Conversation history, retrieval, moderation, rate limiting and cost accounting are not in the README's feature list. The browserStorage feature stores messages locally in the browser, which the 2.2.2 notes describe as a way to avoid a backend message integration, but local storage is not a durable server-side record. If you need conversations to survive a device change or to be auditable, that is yours to build.

Deep Chat versus a framework-native chat library

The closest category is a chat component built for one framework, such as a React-only chat kit. The difference is where the abstraction sits. A framework-native library can lean on that framework's state primitives, hooks and rendering model, and often ships opinionated patterns for streaming and message state. Deep Chat goes the other way: it is a custom element with a framework-agnostic core, and the deep-chat-react package is the React binding rather than a rewrite. That buys you portability across the frameworks the README lists, and it costs you idiomatic integration. In React you are configuring a custom element through properties and JSON strings, as the README examples show, rather than composing hooks.

The other comparison the search results invite is Deep Chat against ChatGPT itself. They are not substitutes. ChatGPT is a hosted product with a model, memory and a subscription behind it. Deep Chat is the front end that calls a model, and the billing, hosting and data handling belong to whichever provider you point it at.

Licence, release cadence and what an upgrade costs you

The repository is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are preserved. That is a permissive starting point, and it is worth reading the LICENSE file in the repository root rather than taking a summary as authoritative. Nothing in the repository suggests any additional terms, but licensing questions about your own distribution belong with your legal team, not with this article.

On maintenance: the repository is not archived, and the last push was on 2026-09-14. Releases have been frequent enough to matter for planning. 2.5.1 landed on 2026-08-27, 2.5.0 on 2026-07-19, and 2.4.2 on 2026-01-31. Each of those notes names concrete additions, which means the surface you configure does grow over time. The 2.5.0 notes added three new directConnection providers; the 2.4.0 notes added scrollButton, hiddenMessages and upwardsMode. Upgrades are therefore not purely internal. Budget for re-reading the release notes before bumping a minor version, and pin the version in your lockfile if you are not prepared to retest the connection path.

There is one deprecation to plan around. The 2.5.1 release is titled "Deprecating OpenAI Assistants API", so any project currently built on that integration has a migration ahead of it. The release notes are the place to confirm the replacement path.

Editorial conclusion

Adopt Deep Chat if you need a chat surface in an existing web app and you already have, or are willing to build, the endpoint that talks to a model. Skip it if you want a hosted chatbot, a knowledge base, or anything that works without a browser, because the repository ships a component and example servers, not a service. Before committing, verify two things in your own environment: whether you can accept the API key exposure that directConnection implies, and whether your backend can emit the response and stream shapes the Connect documentation defines. The 2.5.1 release notes deprecate the OpenAI Assistants API path, so check that your chosen integration is not the one being retired.

Frequently asked questions

Official sources

1. License: MIT
2. OvidijusParsiunas/deep-chat on GitHub
3. Project website
4. README
5. Releases