Origin UI, now coss ui, components on Base UI

Origin UI spent years as one of the larger free catalogues of copy and paste components: React fragments styled with Tailwind, no dependency to install and no account to create. If you arrived here from a year old bookmark, start with the essential fact: originui.com now redirects to coss.com/ui, and the project lives on under the name coss ui, as the official design system of Cal.com.

The change is more than a new name over an old catalogue. The technical foundation shifted, the installation path changed, the licensing layout became more nuanced, and the old collection moved to a separate address. This text sorts out what remains of the old Origin UI, what the new library is, and what to watch before pasting anything into a commercial project.

From a catalogue to a design system

The old Origin UI had a simple model: open the site, pick a button, a form field, or a table, copy the code, paste it into your project. No package in the npm registry, no updates, full ownership of the code. That model earned the project a sizeable following, and it was the reason the catalogue ended up in so many bookmarks.

Today the project's repository is cosscom/coss, its description states "formerly Origin UI" outright, it carries over ten thousand stars, and it is actively developed. Inside sit several applications at once: the coss.com landing site, the apps/ui library with the new components and documentation, and apps/origin holding the components from before the acquisition. That detail matters, because the licence depends on the directory layout, which we will return to.

The new library describes itself as a set of accessible, composable React components, built on Base UI and styled with Tailwind in its fourth version. The ownership model has not changed: the code lands in your repository and is yours from the moment you add it, updates included, because none will arrive on their own.

Installation through the shadcn CLI

The most interesting technical decision of the new incarnation is giving up a custom installer. Components are added with the command line tool known from shadcn/ui, through the @coss namespace in the registry. For a new project the documentation recommends a single initialising command:

Code

Bash

npx shadcn@latest init @coss/style

That sets up the whole kit: components, the neutral colour palette, sidebar variables and base styles, plus the Inter and Geist Mono fonts wired into the project configuration. In an existing project you add pieces selectively:

Code

Bash

npx shadcn@latest add @coss/ui
npx shadcn@latest add @coss/ui @coss/colors-neutral

The first command adds the interface primitives, meaning the button, card, avatar, dialog and the rest of the basics. The second brings just the colour tokens, if you want to build the theme your own way. Every component page in the documentation also carries a ready command for that single element, so you never have to take everything.

The manual route still exists and works exactly as it did in the Origin UI days: open the component page, copy the code from its tab, paste it into a file such as components/ui/button.tsx, and install the dependencies listed on the page. Once added, by either route, usage looks familiar to anyone who has worked with shadcn:

Code

TypeScript

import { Button } from "@/components/ui/button"

export function EnrolButton() {
  return (
    <Button type="submit" variant="default">
      Enrol now
    </Button>
  )
}

It is worth appreciating what this decision means in practice: if your team already knows the shadcn workflow, the cost of entering coss ui is close to zero, because the tooling, the file structure and the way of thinking are the same. What changes is the foundation underneath.

Base UI instead of Radix

The behaviour layer here is not Radix but Base UI, the unstyled primitives library developed by a team that includes the creators of Radix UI and people from the MUI project. It is the same change of foundation that shadcn/ui went through, so both projects now run on the same engine for accessibility, layered positioning and keyboard handling.

For you this means two things. First, the components inherit mature handling of the things a demo never shows: the focus trap in a dialog, closing on the Escape key, positioning dropdowns near a window edge. Second, code copied from coss ui and code from newer shadcn releases speak the same language, so mixing them in one project does not create two parallel worlds of behaviour.

The documentation also maintains a separate, thorough guide for migrating from shadcn/ui and Radix, describing interface differences component by component. If you have a project on Radix and are weighing a move, that document is a better starting point than comparing properties by hand.

The whole documentation is also exposed in a format for code assistants: an llms.txt index file and .md versions of every page. When working with an assistant this is a concrete convenience, because instead of feeding it screenshots of documentation you hand over an address:

Code

Bash

curl https://coss.com/ui/llms.txt

The old catalogue still exists

Library acquisitions often end with old resources disappearing and an avalanche of dead bookmarks. Here the decision went the other way: the old Origin UI collection moved wholesale to coss.com/origin and is still described as a free collection of copy and paste components built with Tailwind and React. Its categories hold between a dozen and several dozen entries each, from buttons and form fields to navigation, tables and whole dashboard fragments.

The distinction between the old and the new collection is practical rather than historical. The old catalogue is fragments to paste: quick, numerous, with no guarantee of coherent behaviour between them, because they were written as independent pieces. The new library is a coherent system: fewer entries, but a shared behavioural foundation, shared tokens and predictable composition. For a prototype or a single page section the old collection can still be faster. For an application meant to grow for years, the new one is the safer choice.

There is also a third option that is easy to forget: the two collections can be combined, because they stand on the same Tailwind. A fragment from the old catalogue pasted next to components of the new library does not clash in styling; it only needs manual care over colour and spacing consistency.

Licensing deserves attention

Here lies the most important change for commercial projects and the only place where the new incarnation is less obvious than the old one. The cosscom/coss repository uses mixed licensing: the default licence of the whole is AGPL version three, while the apps/origin and apps/ui directories, precisely the ones holding the component code of the old and the new collection, remain under MIT.

In practice this means: the component code you copy into your project is MIT and free for commercial use without obligations. But if you reach into the repository for anything outside those two directories, say fragments of the landing site or the infrastructure, you step onto AGPL ground, and that is a licence many companies keep on their banned list, because for network services it requires releasing your code.

The practical rule is simple: copy through the CLI or from the documentation pages rather than from arbitrary repository files, and in an audit point to the source directory. The project publishes the details in the repository's licensing file, so an auditor has somewhere to look. This is a rare arrangement among component libraries and easy to miss, given that the README opens with the words "open source".

coss ui against the alternatives

Option	Form	Behaviour foundation	Pick it when
coss ui	Code copied into your repository, shadcn CLI	Base UI	A coherent system, the familiar shadcn flow, a finished theme
shadcn/ui	Code copied into your repository	Base UI	The largest community and registry ecosystem
Radix UI directly	Dependency from npm, unstyled	Its own	You write all the styles yourself
HeroUI	Dependency from npm, styled	React Aria	A finished look without copying files
The old origin catalogue	Fragments to paste	Varies per fragment	Quick prototypes, single sections

The nearest neighbour is naturally shadcn/ui, and choosing between them rarely comes down to technology, since the foundation is shared. Softer things decide: coss ui gives you a polished theme with fonts and a palette from the start, shadcn gives a larger ecosystem and more ready examples around the web. With Tailwind in its fourth version both work the same way.

A separate category is community catalogues such as Uiverse, where elements come from hundreds of authors. There you take a single visual effect; here you take a system whose elements are designed to work together.

Common mistakes

The first mistake is treating old guides as current. Materials about Origin UI from before the change describe a site whose layout and addresses no longer exist, and partly also components that look different in the new collection. Before implementing anything from a guide, check that its examples match the current documentation.

The second is copying from the repository instead of the documentation. The licensing layout described above means two files sitting near each other in the same repository can carry different licences. The path through the CLI and the component pages keeps you on the MIT side.

The third is mixing foundations without realising it. If your project already holds components on Radix, adding elements on Base UI will work, but dialogs and dropdowns from the two worlds can differ in behavioural details, nested layers for instance. The migration guide exists precisely so you cross in one direction rather than living in both at once.

The fourth is assuming updates will arrive on their own. The copying model means a bug fix in the library will not reach your project until you add the component again. After a longer break it pays to compare your files with the current version, especially for components tied to accessibility.

FAQ

Does Origin UI still exist?

Not as a separate project, but nothing has disappeared. The originui.com address redirects to coss.com/ui, the project's new home. The old component catalogue lives in full at coss.com/origin and remains free, with its code sitting in the repository's apps/origin directory under the MIT licence.

What does coss ui cost?

Nothing. Both the new library and the old catalogue are free, and the component code is MIT licensed, with no paid tier. The project is maintained as Cal.com's design system, so its funding model does not rest on selling components.

How does it differ from shadcn/ui?

Less than the separate name suggests: the same copying model, the same CLI and the same Base UI foundation. The differences sit in the finishing layer: coss ui delivers a complete theme with palette and fonts in one command, shadcn a larger ecosystem. You can use both in one project, since they install through the same registry mechanism.

Can I use the components in a commercial project?

Yes, the component code is MIT. Just mind the boundaries: the repository's default licence is AGPL and covers everything outside the apps/origin and apps/ui directories. Copy through the CLI or from the documentation and you stay on the safe side.

Do I need Tailwind version four?

Yes, the components are written for the current Tailwind version and the documentation lists it as a prerequisite. A project on an older version needs the Tailwind migration first, which is separate work with pitfalls of its own.

Current components and guides live in the coss ui documentation, and the old collection sits at coss.com/origin.