onyx

ut OpenCode does a very good job with docs. Workplace apps also have a natural structure (Slack channels about certain topics, Drive folders for teams, etc.). And since the full metadata of each document can be written to the file, the LLM can define arbitrarily complex filters. At scale, it can write and execute python to extract and filter (and even re-use the verified correct logic later). Put another way, bash + a file system provides a much more flexible and powerful interface than traditional RAG or MCP, which today’s smarter LLMs are able to take advantage of to great effect. This comes especially in handy for aggregation style questions that require considering thousands (or more) documents. Naturally, it can also create artifacts that stay up to date based on your company docs. So if you wanted “a dashboard to check realtime what % of outages were caused by each backend service” or simply “slides following XYZ format covering the topic I’m presenting at next week’s dev knowledge sharing session”, it can do that too. Craft (like the rest of Onyx) is open-source, so if you want to run it locally (or mess around with the implementation) you can. Quickstart guide: https://docs.onyx.app/deployment/getting_started/quickstart Or, you can try it on our cloud: https://cloud.onyx.app/auth/signup (all your data goes on an isolated sandbox). Either way, we’ve set up a “demo” environment that you can play with while your data gets indexed. Really curious to hear what y’all think!

e Danswer just to chat with LLMs. We’d hear, “the connectors, indexing, and search are great, but I’m going to start by connecting GPT-4o, Claude Sonnet 4, and Qwen to provide my team with a secure way to use them”. Many users would add RAG, agents, and custom tools later, but much of the usage stayed ‘basic chat’. We thought: “why would people co-opt an enterprise search when other AI chat solutions exist?” As we continued talking to users, we realized two key points: (1) just giving a company secure access to an LLM with a great UI and simple tools is a huge part of the value add of AI (2) providing this well is much harder than you might think and the bar is incredibly high Consumer products like ChatGPT and Claude already provide a great experience—and chat with AI for work is something (ideally) everyone at the company uses 10+ times per day. People expect the same snappy, simple, and intuitive UX with a full feature set. Getting hundreds of small details right to take the experience from “this works” to “this feels magical” is not easy, and nothing else in the space has managed to do it. So ~3 months ago we pivoted to Onyx, the open-source chat UI with: - (truly) world class chat UX. Usable both by a fresh college grad who grew up with AI and an industry veteran who’s using AI tools for the first time. - Support for all the common add-ons: RAG, connectors, web search, custom tools, MCP, assistants, deep research. - RBAC, SSO, permission syncing, easy on-prem hosting to make it work for larger enterprises. Through building features like deep research and code interpreter that work across model providers, we've learned a ton of non-obvious things about engineering LLMs that have been key to making Onyx work. I'd like to share two that were particularly interesting (happy to discuss more in the comments). First, context management is one of the most difficult and important things to get right. We’ve found that LLMs really struggle to remember both system prompts and previous user messages in long conversations. Even simple instructions like “ignore sources of type X” in the system prompt are very often ignored. This is exacerbated by multiple tool calls, which can often feed in huge amounts of context. We solved this problem with a “Reminder” prompt—a short 1-3 sentence blurb injected at the end of the user message that describes the non-negotiables that the LLM must abide by. Empirically, LLMs attend most to the very end of the context window, so this placement gives the highest likelihood of adherence. Second, we’ve needed to build an understanding of the “natural tendencies” of certain models when using tools, and build around them. For example, the GPT family of models are fine-tuned to use a python code interpreter that operates in a Jupyter notebook. Even if told explicitly, it refuses to add `print()` around the last line, since, in Jupyter, this last line is automatically written to stdout. Other models don’t have this strong preference, so we’ve had to design our model-agnostic code interpreter to also automatically `print()` the last bare line. So far, we’ve had a Fortune 100 team fork Onyx and provide 10k+ employees access to every model within a single interface, and create thousands of use-case specific Assistants for every department, each using the best model for the job. We’ve seen teams operating in sensitive industries completely airgap Onyx w/ locally hosted LLMs to provide a copilot that wouldn’t have been possible otherwise. If you’d like to try Onyx out, follow https://docs.onyx.app/deployment/getting_started/quickstart to get set up locally w/ Docker in <15 minutes. For our Cloud: https://www.onyx.app/. If there’s anything you'd like to see to make it a no-brainer to replace your ChatGPT Enterprise/Claude Enterprise subscription, we’d love to hear it!

ot a good project, but because there are a ton of open deep-research projects which I'm afraid will just fizzle out, and would be better if people would join forces working on those aspects they care most about (e.g. local aspect, or RAG strategies, etc) . [1] https://github.com/LearningCircuit/local-deep-research/blob/... [2] "In-Browser Graph RAG with Kuzu-WASM and WebLLM" https://news.ycombinator.com/item?id=43321523 [3] https://github.com/onyx-dot-app/onyx

o company applications like Google Drive, Salesforce, Sharepoint, GitHub, Slack, and 30+ others. For example, an engineer may want to know “What’s happening with the verification email failure?” Onyx’s AI agent would first figure out what it needs to answer this question: What is the cause of the failure, what has been done to address it, has this come up before, and what’s the latest status on the issue. The agent would run parallel searches through Confluence, email, Slack, and GitHub to get the answers to these then combine them to build a coherent overview. If the agent finds that there was a technical blocker that will delay the resolution, it will adjust mid-flight and research to get more context on the blocker. Here’s a video demo I recorded: https://www.youtube.com/watch?v=drvC0fWG4hE If you want to get started with the GitHub repo, you can check out our guides at https://docs.onyx.app. Or to play with it without needing to deploy anything, you can go to https://cloud.onyx.app/signup P.S. There’s a lot of cool technical details behind building a system like this so I’ll continue the conversation in the comments.

f all the boring stuff (integrating with 35+ tools, constantly keeping docs up-to-date, and handling permissions) and provide an opinionated starting point for the generic hard stuff (really good hybrid-search + factoring in metadata, recency, etc.), so that you can focus on the specific business logic of the app. Back when I was at Alation, on-call for our team could have been made so much easier by a small, custom app that auto-responded to every alert based on Confluence, Slack, and a few Drive folders. Danswer’s APIs would power the core of this, and all I’d be left with are app-specific things like routing alerts to the right team member based on the document ownership of the cited documents. For an example of what it looks like to use the APIs, check out this script here: https://github.com/danswer-ai/danswer/blob/main/examples/ass...! If you're curious what's happening under the hood, check out our docs: https://docs.danswer.dev/system_overview. Thanks, excited to hear your thoughts!

I had never used. For most projects, a simple question to ChatGPT would have solved it; but in this moment, ChatGPT was completely clueless without additional context (which I also couldn’t find). We believe that within a few years, every org will be using team-specific knowledge assistants. We also understand that teams don’t want to tell us their secrets and not every team has the budget for yet another SaaS solution, so we open-sourced the project. It is just a set of containers that can be deployed on any cloud or on-premise. All of the data is processed and persisted on that same instance. Some teams have even opted to self-host open-source LLMs to truly airgap the system. I also want to share a bit about the actual design of the system (https://docs.danswer.dev/system_overview). If you have questions about any parts of the flow such as the model choice, hyperparameters, prompting, etc. we’re happy to go into more depth in the comments. The system revolves around a custom Retrieval Augmented Generation (RAG) pipeline we’ve built. During indexing time (we pull documents from connected sources every 10 minutes), documents are chunked and indexed into hybrid keyword+vector indices (https://github.com/danswer-ai/danswer/blob/main/backend/dans...). For the vector index (which gives the system the flexibility to understand natural language queries), we use state of the art prefix-aware embedding models trained with contrastive loss. Optionally the system can be configured to go over each doc with multiple passes of different granularity to capture wide context vs fine details. We also supplement the vector search with a keyword based BM25 index + N-Grams so that the system performs well even in low data domains. Additionally we’ve added in learning from feedback and time based decay—see our custom ranking function (https://github.com/danswer-ai/danswer/blob/main/backend/dans... – this flexibility is why we love Vespa as a Vector DB). At query time, we preprocess the query with query-augmentation, contextual-rephrasing, as well as standard techniques like removing stopwords and lemmatization. Once the top documents are retrieved, we ask a smaller LLM to decide which of the chunks are “useful for answering the query” (this is something we haven’t seen much of elsewhere, but our tests have shown to be one of the biggest drivers for both precision and recall). Finally the most relevant passages are passed to the LLM along with the user query and chat history to produce the final answer. We post-process by checking guardrails and extracting citations to link the user to relevant documents. (https://github.com/danswer-ai/danswer/blob/main/backend/dans...) The Vector and Keyword indices are both stored locally and the NLP models run on the same instance (we’ve chosen ones that can run without GPU). The only exception is that the default Generative model is OpenAI’s GPT, however this can also be swapped out (https://docs.danswer.dev/gen_ai_configs/overview). We’ve seen teams use Danswer on problems like: Improving turnaround times for support by reducing time taken to find relevant documentation; Helping sales teams get customer context instantly by combing through calls and notes; Reducing lost engineering time from answering cross-team questions, building duplicate features due to inability to surface old tickets or code merges, and helping on-calls resolve critical issues faster by providing the complete history on an error in one place; Self-serving onboarding for new members who don’t know where to find information. If you’d like to play around with things locally, check out the quickstart guide here: https://docs.danswer.dev/quickstart. If you already have Docker, you should be able to get things up and running in <15 minutes. And for folks who want a zero-effort way of trying it out or don’t want to self-host, please visit our Cloud: https://www.danswer.ai/

. You can also select specific documents to chat with at any point and deselect them when you want the system to run more retrievals. You can further refine your search by applying time and source type filters. With Danswer you can also create document-sets for specific use cases. You can easily group together knowledge for different purposes like onboarding, HR answers, team specific knowledge, finance, etc. You can combine different sources at different granularities such as creating a document-set which is a combination of Slack channels + some set of Google Drive Folders + some workspaces from Confluence, etc. You get the picture. Finally, just like GPTs, you can configure custom prompts and create different assistants for varied tasks like debugging, summarizing, generating content, all while pulling in the context documents you want to include. Out of the box, Danswer comes with several pre-configured general use assistants. You can use Danswer to improve your operational efficiencies for any team that needs it. We’ve seen users use it for onboarding, customer support, cross-team communications, sales-call prep, and as an engineering assistant. We also have a Slack (https://join.slack.com/t/danswer/shared_invite/zt-1u3h3ke3b-...) and a Discord (https://discord.gg/TDJ59cGV2X) community. Always looking forward to user feedback as this helps us improve our software! See you there :)