kite-public holds the open source front end and the data behind Kagi News

A news product built around a daily refresh

Kagi News is described as a news app for people who want a healthy news diet, developed by Kagi, and the repository holds the public files for it.

The product idea is stated in terms of restraint rather than features. The core principles are that it is updated only once per day with no endless scrolling, at 12PM UTC, that it presents facts and perspectives and is opinion-free, that there is zero tracking and zero ads, that it is pure signal with no noise, that quality comes over quantity, and that the goal is a complete news diet in five minutes.

Those principles explain the rest of the repository, including the parts that look bureaucratic until you read them. The daily refresh is why the feed catalogue is a curated list rather than a scraper, the translation of every source into one language is why a single category can mix feeds from many countries, and the opinion-free stance is why there is a media ownership dataset in the tree at all.

The project says most of what powers Kagi News is open sourced and found in this repository, and lists what that includes: the Kagi News web app, the community curated feeds, and the media information.

The audience is two-sided. There are readers, who use the hosted app at kite.kagi.com or news.kagi.com, and there are developers, who are explicitly invited to build their own front ends on top of the same data. The README goes further than a licence grant here, asking people to share what they build by editing the README file.

The repository is MIT licensed for the code and is not archived, with the last push on 2026-10-19 and no GitHub releases.

The code and the data carry different licences

Two licence badges sit at the top of the README, MIT and CC BY-NC 4.0, and they cover different things.

The code is MIT. The data is not. The documentation states that the front end uses Kagi News application data found at kite.kagi.com/kite.json, and that kite.json and the files referenced by it are licensed under a CC BY-NC licence, which means the data can be used free of charge with attribution and for non-commercial use, and that anyone who wants to license it for commercial use should get in touch through [email protected].

That split is the single most important thing to understand before building anything on this repository. A developer can fork the front end under MIT, wire it to their own back end, and ship the application. They cannot take the daily dataset and put it in a commercial product, and they cannot redistribute the data as part of a paid offering.

The separation is also visible in the repository layout. The application source is under `src/`, with `svelte.config.js` and `vite.config.ts` at the root, and the data lives in separate files that are fetched at runtime rather than bundled: `kite_feeds.json` for the community curated feeds, `core_feeds.py` for the official core feeds, `media_data.json` for the media information, and `contentFilters.json` for the personal content filters.

The content filters deserve a mention because they are a different mechanism from everything else in the tree. They are described as personal filters that let users blur or hide articles on topics they prefer not to see, and they are defined in a JSON file in the repository rather than in the user's account, which is a sign that the file is meant to be copied and edited locally.

Running the front end is a clone, an install and a dev server

The front end is a statically served application and is fully open source, so running it locally is the documented path.

# Clone the repository
git clone https://github.com/kagisearch/kite-public.git
cd kite-public

# Make sure you have the Node.js LTS version installed.
node -v

# Install dependencies
npm install

# Run development server
npm run dev

The documentation points at the Vite guide to static deployment for how a production build works, and the package manifest has a `build` script that runs `vite build` and a `preview` script that runs `vite preview`, so the same source produces a static bundle you can serve from anything.

The stack is worth noting because it explains the shape of the code. The front end is Svelte with SvelteKit, TypeScript through `tsconfig.json` and `tsconfig.svelte-check.json`, Tailwind CSS version 4 via the `@tailwindcss/vite` plugin, and Biome for formatting and linting in place of a Prettier and ESLint pair. Tests are Vitest with three separate configurations, `vitest.config.unit.ts`, `vitest.config.integration.ts` and a top level `vitest.config.ts`, and the scripts separate `test:unit`, `test:integration` and `test:all` accordingly. There is a `.lighthouserc.json` for performance checks.

Two dependencies in the manifest explain capabilities the README does not describe in detail. `dexie` is an IndexedDB wrapper, which is how a statically served application can cache the day's data locally, and the presence of `@anthropic-ai/sdk`, `@google-cloud/vertexai` and `@google/genai` in the dependency list shows that AI provider access is wired into the application, which matches the description of stories being summarised by advanced language models.

There is also a `bun.lock` in the tree even though the documented install path uses npm, and the `postinstall` script in the manifest writes a source map file into `node_modules` for the Adobe CSS tools package, which is the kind of workaround that tells you a transitive dependency ships a broken map.

kite_feeds.json is the community catalogue

Editing the community curated categories is a pull request against `kite_feeds.json`, and the file holds RSS feed URLs organised by category.

The structure is deliberately simple, a mapping from category name to a feeds array.

{
  "Category Name": {
    "feeds": [
      "https://example.com/rss-feed-1",
      "https://example.com/rss-feed-2",
      // ...
    ],
  },
}

Adding a new category has three steps: create a new object with the category name as the key, add a feeds array containing the RSS feed URLs for that category, and make sure the JSON formatting is right, with commas between objects and no trailing comma. All categories are created equal and appear as top level categories in the app.

The suggested kinds of category are local news at city or state level, regional news at country or region level, and topical news such as health, machine learning or aviation.

The guidelines for what may go into a feed are the substantive part. Kagi News does not scrape websites and only uses publicly available RSS feeds, and a feed should be checked to be working with recent, daily content, and the sources should be high quality, with an explicit instruction not to use low quality, gossip or SEO content.

The rule about languages is the one that will trip up a first-time contributor. Feeds can be in any language, because Kagi News translates all content automatically, so a single category can and should contain feeds in multiple languages, and separate categories for the same topic in different languages are explicitly discouraged, with the example given being a country split by language. The `source_language` field in `kite_feeds.json` is set to the language used by the majority of feeds in that category, and the documentation says its exact value is not critical.

Twenty five feeds is the price of a new category

The rule that decides whether a contribution appears in the app is a threshold, and it is stated in bold in the documentation. At least 25 feeds are required for a category in order to surface it in Kagi News, and the reason given is to make sure the quality of events covered in the app is maintained, with more high quality feeds for a category meaning better coverage.

Twenty five feeds is a lot to gather for a narrow topic, and that is the point. A category with three feeds would produce a thin daily edition, and a thin daily edition is exactly what the product is designed to avoid. The threshold turns a category from a list of links into a survey of a subject.

It also means a contributor cannot test a new idea and see it live. The pull request that adds a category will be merged into the data and the category will not appear in the app until it has enough feeds behind it. A pull request that adds five feeds to an existing large category is therefore more immediately useful than one that proposes a new topic from scratch.

The official core feeds are handled separately and more generously. They live in `core_feeds.py`, they are described as fully open source, and they cover the essential categories, with World News, Business, Technology, Science, Sports, Culture and Politics named, and many more specialised topics besides. They are primarily maintained by the Kagi team for quality and consistency, but they are open to community pull requests suggesting improvements or additions.

The combination is the point the documentation makes at the end of that section. The core feeds and the community curated feeds together ensure coverage is comprehensive and diverse, drawing on multiple perspectives rather than one editorial line.

Media ownership data is part of the product

The `media_data.json` file exists to show additional information about the sources of information in the app, and the initial content comes from statemediamonitor.com, with the classification methodology explained on that site.

The README invites contributions for both privately owned and state funded media organisations, and asks that the sources of information be added in the pull request. So the file is a data set of ownership and funding classifications rather than a preferences list.

This is the part of the project with a design principle behind it. The stated principle is facts and perspectives, opinion-free, and a reader who is served stories from twenty five sources in a category has no way to know who owns them or who funds them. Publishing that classification alongside the stories is the mechanism that lets a reader apply their own judgement about a source, and it is a differentiator from a reader that gives you an opinion column with no label.

It also creates a real maintenance obligation. Ownership changes, outlets close, and a static file has to be updated by hand, through pull requests, by people willing to do the research. The README does not describe an automated process for it.

The repository also carries a `scripts/` directory and a `.env` and `.env.development` pair, which is where the environment-specific configuration for the front end lives, and the `static/` directory holds the static assets that ship with the application.

Where this front end is the wrong choice

The limitations follow directly from the product model, and they are worth stating before anyone builds on it.

The first is the daily refresh. An application that updates once a day at 12PM UTC is excellent for someone who wants a settled edition of the news and useless for someone who needs to know about something happening now. There is no live tail, and there is no way to make it live without building a different product, because the summarisation and the curation are done for the day's batch.

The second is the licence on the data. MIT for the code is genuinely permissive and lets you ship a commercial front end, but the CC BY-NC terms on the dataset mean the content itself cannot go into a commercial product without arranging a licence with Kagi. For a hobbyist project that is a non-issue. For a company building a news product, it is the whole decision.

The third is that the data is RSS only. The documentation is explicit that Kagi News does not scrape websites and uses only publicly available RSS feeds, which means a source without a feed is invisible, and a source that stops publishing its feed disappears without warning. The 25 feed threshold partly compensates by spreading across many sources, but it does not remove the dependency on each one keeping its feed alive.

The alternative approach, and the difference in approach is real, is to run your own reader over your own feed list and accept the endless scroll and the ads, or to use an existing feed reader with rules and filters. Kagi News is a different product, one that has made editorial decisions on your behalf, and the appeal of that is exactly the same thing that limits it, because a once-a-day, opinion-free, translation-ready, ownership-labelled edition cannot also be real time.

Editorial conclusion

kite-public suits a developer who wants to build an alternative reader on top of Kagi News data, or a team that wants a daily, opinion free, ad free news surface and is willing to run the front end themselves. It is the wrong choice for a product that needs the data commercially, since the data is CC BY-NC, and the wrong choice for anyone who wants a continuously updated feed, because the whole design is one refresh a day. Check first which licence covers the part you want to use, because the code and the data are under different terms, and read the twenty five feed rule before adding a category.

Frequently asked questions

Official sources

1. Issues
2. kagisearch/kite-public on GitHub
3. License: MIT
4. Project website
5. README