DEV Community: Divyesh

Your AI Forgets Everything. Here's How Cognee Fixes It.

Divyesh — Sun, 05 Jul 2026 06:36:55 +0000

Have you ever noticed this?

You explain your project to an AI chatbot, have a great conversation, then come back later... and it asks you to explain everything again. Start a new chat, and it's like meeting you for the first time.

This isn't a bug. It's how most AI models work—they don't remember past conversations on their own.

That's where Cognee comes in. Instead of making AI start from scratch every time, it gives AI a way to remember what matters.

Why does AI forget everything?

Most AI models don't have long-term memory.

Every time you start a new chat, the AI only knows what you send in that conversation. It doesn't remember your previous chats, your project, or your preferences unless you provide them again.

A common solution is RAG (Retrieval-Augmented Generation). It stores your documents in a searchable database so the AI can look up relevant information when needed.

RAG genuinely helps, but it only knows what sounds similar. It doesn't know "Priya" and "the payments lead" are the same person, or that this week's ticket shares a root cause with one from March. Similarity search finds neighbors — it doesn't understand relationships.

That's where Cognee takes a different approach.

What is Cognee?

Cognee is an open-source memory layer for AI applications.

Instead of making an AI start from scratch every time, Cognee helps it remember information across conversations. It can learn from your documents, files, websites, or notes and use that knowledge whenever it's needed.

Unlike traditional RAG systems that mainly find similar text, Cognee also understands how different pieces of information are connected. That gives AI more accurate and meaningful answers.

It's Apache-2.0, runs locally by default, and has 27k+ GitHub stars.

How does it work?

At a high level, the process is simple:

flowchart LR
    A[Text, Files, URLs] --> B[remember()]
    B --> C[Cognee builds AI memory]
    C --> D[recall()]
    D --> E[AI answers using remembered knowledge]

For example:

"Alice bought a Pro subscription."

"Her latest payment failed."

Later, if you ask:

"Why can't Alice access Pro features?"

Cognee connects those facts and answers:

Alice's payment failed, so her Pro subscription isn't active.

Four operations, one lifecycle

Cognee keeps its API simple:

Operation	What it does
`remember()`	Stores new information.
`recall()`	Retrieves relevant knowledge.
`improve()` (`memify`)	Organizes and improves stored memory over time.
`forget()`	Removes information when it's no longer needed.

Try it in 60 seconds

pip install cognee

import os
os.environ["LLM_API_KEY"] = "YOUR_OPENAI_API_KEY"

import cognee
import asyncio

async def main():
    await cognee.remember("Cognee turns documents into AI memory.")
    results = await cognee.recall("What does Cognee do?")
    for result in results:
        print(result)

asyncio.run(main())

That's it. With just a few lines of code, your AI can start remembering information instead of treating every conversation like the first one.

Where this shows up

Anywhere you want your AI to remember things.

For example, if you tell your AI:

"I'm building a React app."

A few days later, you ask:

"How should I structure my project?"

Instead of asking you to explain everything again, Cognee remembers your earlier conversation and gives a more relevant answer.

This is useful for AI assistants, chatbots, coding assistants, customer support, and any application where remembering past information makes conversations smarter.

Cognee vs. plain RAG

	Vector DB / basic RAG	Cognee
Storage	Chunks + embeddings	Chunks + embeddings + knowledge graph + provenance
Retrieval	Similarity search	Similarity and graph traversal (12+ modes)
Relationships	Not modeled	Explicit graph edges
Improves over time	No	`improve()` prunes and reweights
Deleting data	Manual / all-or-nothing	`forget()` at item, dataset, or user level
Setup	Minimal	Minimal locally; more knobs in production

When to use it

Use Cognee if your AI needs to remember users, projects, or previous conversations over time.

If you only need to search a few documents, a traditional RAG setup is usually enough.

Wrapping up

LLMs are great at answering questions, but they don't remember anything on their own.

Cognee fills that gap by giving AI long-term memory. Instead of starting from scratch every time, your AI can remember what it has learned and use that knowledge in future conversations.

If you're building AI agents, chatbots, or assistants, Cognee is definitely worth exploring.

What's the one thing you'd want an AI agent to remember about you, permanently? Drop it in the comments and if you're building for the Cognee hackathon, link it below.

OSS Maintainers Lose Hours to Vague Issues. I Built a GitHub Action to Fix That.

Divyesh — Wed, 24 Jun 2026 04:33:55 +0000

I've been on both sides of the GitHub issue wall.

As a contributor, I've spent time writing what I thought was a decent bug report, only to get a one-liner back: "Can you share a repro?" Three days later I reply. No response. Issue goes stale.

As someone who's poked around in open source repos, I've seen maintainers close issues with a "not enough info" label that they clearly copy-pasted from a template. You can't blame them — doing that manually for every bad issue is exhausting.

That friction is what I tried to fix.

The Context: A 72-Hour Hackathon About Slop Detection

Hackathon Raptors ran the Slop Scan hackathon with a clear brief: build something that detects low-quality content. Most participants went after social media posts or AI-generated text.

I looked at GitHub issues.

They're a form of content too, and they have a very clear quality signal: does this issue give a maintainer enough information to act on it, or not? That's binary and measurable. I could build a scoring system around it.

The result was Signal-OSS — a GitHub Action that scores every new issue from 0 to 10, always posts a structured comment with a checklist tailored to that score, and edits that comment if the contributor updates their issue.

I placed 5th overall and won the Best Detection Accuracy Award. Here's what I actually built.

The Problem With Current Issue Triage

Most repos handle bad issues in one of two ways:

The maintainer manually replies asking for more info. This is time-consuming and inconsistent.
A generic bot closes the issue after N days of inactivity. This is blunt and often alienates contributors who just forgot to follow up.

Neither approach tells the contributor what is actually missing. That's the gap Signal-OSS targets.

The goal isn't to reject bad issues — it's to convert them into good ones by being specific about what's missing.

What It Looks Like in Practice

When a new issue is opened, Signal-OSS runs and always posts a comment — within seconds. What changes based on the score is the content of that comment: a high-scoring issue gets a checklist confirming what's already present, while a low-scoring one gets a checklist of what's specifically missing from that issue.

a newly opened GitHub issue with the bot comment appearing automatically at the bottom

The comment isn't generic. It's generated based on the actual signals detected in that issue — not a boilerplate reply, but a specific breakdown the contributor can act on.

How the Scoring Engine Works

This is the part I find most interesting to explain.

The naive approach would be: send the issue to an LLM, ask it to score it, done. That works, but it couples every issue to an external API call — slow, potentially costly, and requires a key just to get started.

Signal-OSS takes a different approach: heuristics first, LLM only as an optional tiebreaker.

Step 1: 7 Heuristic Signals

Before any LLM is involved, the action checks 7 rule-based signals:

Does it include a stack trace?
Are reproduction steps present?
Is a version number mentioned?
Is there expected vs actual behavior described?
Is there a code block with relevant code?
Is there an environment description?
Does the issue have a clear, descriptive title (not just "bug" or "error")?

Each signal contributes to the score. Issues that pass most of these signals will likely land above 7. Issues that fail most will land below 3. Both cases get handled without any LLM call.

Step 2: The Ambiguous Zone (4–6)

Issues that land in the 4–6 range are genuinely ambiguous. Maybe the repro steps are there but vague. Maybe there's a stack trace but no environment context. For these, the heuristics can't reliably decide.

This is the only zone where an LLM can get called — and only if you've provided an API key. Signal-OSS is BYOK: bring your own LLM key if you want the smarter scoring, leave it out and the action still works. For the ambiguous zone specifically, omitting the key falls back to the standard heuristic checklist, which is good enough for most repos.

The result: the action is fully functional with zero external API keys. The LLM layer is an opt-in upgrade, not a requirement.

The Comment and Labels

the bot's comment showing the checklist and needs-info label option

the bot's comment showing the signal-oss-ignore label option

The bot also:

Applies a needs-info label automatically on low scores
Adds a signal-oss-ignore label option — if a maintainer adds this to any issue, the bot stays completely silent for that issue
Edits its own comment if the contributor updates the issue and the score improves — no spamming the thread with multiple bot replies

Setup Is One File

This was a deliberate design constraint I set early: the activation path has to be a single YAML file. No secrets to configure, no dashboard to sign up for.

# .github/workflows/triage.yml
name: Signal-OSS Issue Triage

on:
  issues:
    types: [opened, reopened]

permissions:
  contents: read
  issues: write

jobs:
  triage:
    runs-on: ubuntu-latest
    if: github.actor != 'github-actions[bot]'
    steps:
      - name: Triage issue
        uses: Divyesh-5981/signal-oss@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          model: 'none'

The GITHUB_TOKEN is automatically provided by GitHub Actions — no setup needed. The action works fully without the LLM key, using the standard heuristic checklist for all issues including the ambiguous 4–6 zone. If you add a key, ambiguous issues get LLM-refined scoring instead. Drop the file into .github/workflows/ and you're done either way.

the summary view in the Actions tab showing the run result and the score output

Benchmark Numbers (and Why Precision Is Lower Than Recall)

I benchmarked Signal-OSS on real issues from three large repositories: microsoft/vscode, facebook/react, and rust-lang/rust.

Metric	Score
Precision	0.66
Recall	0.93
F1	0.77

The precision being lower than recall was intentional. Here's the tradeoff:

High recall means the system rarely misses a bad issue. If something is genuinely low-quality, Signal-OSS will catch it.

Lower precision means it sometimes flags issues that are actually fine. This results in false positives — good issues that get a comment asking for more detail.

For this use case, that's the right tradeoff. Missing a bad issue (false negative) wastes maintainer time. Flagging a good issue (false positive) is slightly annoying for the contributor but recoverable — they can see the score is borderline and move on, or the maintainer can apply signal-oss-ignore.

If I'd optimized for precision, I'd be missing bad issues constantly. That defeats the purpose.

What I'd Do Differently

A few honest notes from the hackathon:

The 4–6 threshold was arbitrary. I chose it based on intuition and tested it during the benchmark, but a configurable threshold would make Signal-OSS more useful across different repo cultures. A high-volume OSS project might want stricter rules than a small internal tool.

The heuristics are English-biased. All 7 signal checks were designed for English-language issues. Issues written in other languages will score lower by default, which isn't fair. This is worth fixing before any serious adoption.

I benchmarked on large repos. The issue quality distribution in vscode or react is probably different from smaller, less-structured projects. The benchmark numbers may not generalize.

Try It

The repo is linked below. If you maintain an open-source project and issue triage is eating your time, this is worth a look.

Two things I'd find genuinely useful from you:

If you test it: tell me in the comments whether the false positive rate felt acceptable on your repo.
If you've solved this differently: I'm curious what other approaches people have tried. Probot? Custom webhooks? Just closing everything immediately?

👇 Drop your thoughts below. And if this was useful, the ❤️ helps other maintainers find it.

Built during the Slop Scan hackathon organized by Hackathon Raptors. Repo in the comments.

Note: The code, benchmarks, and project idea in this post are 100% my own work from the Slop Scan hackathon, but I used AI assistance to help structure and write this article.

We Added React Doctor to Our UI Kit Monorepo. Here's What It Found.

Divyesh — Fri, 19 Jun 2026 06:00:37 +0000

Maintaining a component library means living with a specific kind of anxiety.

Not the obvious bugs — those get caught. It's the quiet ones: a useEffect that shouldn't exist, a re-render that compounds across ten consuming apps, an accessibility gap that slipped through because ESLint didn't have a rule for it.

That's the gap React Doctor fills.

What Is React Doctor?

React Doctor is a static analyzer built specifically for React and React Native codebases. One command scans your project and surfaces issues across:

State and effect anti-patterns
Performance regressions
Accessibility risks
Architecture smells
Security concerns

It's not a replacement for ESLint — it's a second opinion that catches what ESLint misses.

Setup in a Monorepo

Adding it to our ui-kit-lib took about five minutes:

// package.json
{
  "scripts": {
    "doctor": "react-doctor"
  },
  "devDependencies": {
    "react-doctor": "0.2.5"
  }
}

For a monorepo with Storybook, generated output, and test artifacts, a scoped ignore config keeps the signal clean:

// react-doctor.config.json
{
  "ignore": {
    "files": [
      "**/dist/**",
      "**/storybook-static/**",
      "**/coverage/**",
      "**/.cache/**",
      "**/tmp/**"
    ]
  }
}

Without this, React Doctor scans build output and inflates the findings with noise.

What It Actually Caught

Our workspace includes UI components, primitives, icons, locale packages, and a Storybook app. Each package passes TypeScript, formatting, and linting — but that's not the same as being clean.

Here are two patterns it flagged that are easy to miss in review:

Inline array computation on every render:

// ❌ Runs filter on every render
const filteredItems = items.filter((item) => item.visible);
return <Select options={filteredItems} />;

// ✅ Stable reference, only recomputes when items changes
const filteredItems = useMemo(
  () => items.filter((item) => item.visible),
  [items]
);
return <Select options={filteredItems} />;

Derived state copied through useEffect:

// ❌ Extra render cycle, unnecessary sync
useEffect(() => {
  setActive(value);
}, [value]);

// ✅ Just read the prop directly during render
const active = value;

These patterns work. They compile, they test, they ship. But at component-library scale where one primitive gets consumed across an entire product they compound quietly.

After running React Doctor, we revisited and cleaned up real components including Accordion, Avatar, ComboBox, Modal, Select, SearchBox, Popper, and ThemeProvider.

How to Use It Effectively

1. Run it locally first

pnpm doctor

Don't panic if the count is high on the first run. Triage by category.

2. Fix high-signal issues first

Prioritize in this order:

Errors before warnings
Performance and re-render issues
State/effect anti-patterns
Accessibility findings

3. Add it to CI

npx react-doctor@latest install

Choose Yes when it prompts for GitHub Actions. From that point, every PR gets inline comments on the exact lines that introduced a regression — before merge, not after.

The Real Value

React Doctor won't replace code review or architectural judgment. What it does is shift the quality conversation earlier.

For a UI kit, that matters more than for most projects. Every component is a shared primitive. A fragile pattern in Select doesn't stay in Select it lives in every form across every app that consumes the library.

The shift React Doctor enabled for us:

Before: "This component works."

After: "This component is cleaner, safer, and less likely to regress."

That's the kind of improvement that compounds.

Try It

npx react-doctor@latest

No config needed to start. See what it finds on your codebase. If you maintain a design system, component library, or internal UI package, there's a good chance it surfaces something worth fixing.

Do you use any React-specific quality gates in your component library or monorepo? Curious what others are using — React Doctor, custom ESLint rules, Storybook interaction tests, visual regression, or something else.

I Added an AI Gate Before Every git push with no-mistakes 🛡️

Divyesh — Fri, 12 Jun 2026 06:14:08 +0000

We are all using AI to write code now. Whether it's Claude Code, Aider, or Copilot, the speed is incredible. But there is a glaring bottleneck we don't talk about enough: AI code is often just slightly broken. 🤖💥

It forgets an import, misses a type definition, or fails a test.

Usually, you only find out after you push to GitHub. Your CI/CD pipeline turns red 🔴, and you end up polluting your Git history with a dozen commits titled fix: linting or fix: missing test variable.

I recently found a repository called no-mistakes that solves this brilliantly. It acts as a local proxy between your terminal and GitHub, forcing AI to test and fix its own code before anyone else sees it.

Here is why it's worth a look. 👇

😩 The Problem With Traditional Workflows

Right now, developers handle broken code in two ways:

The CI/CD Walk of Shame 🚶: You push code, wait 5 minutes for GitHub Actions to fail, pull the error locally, fix it, and push again.
Pre-commit Hooks (Husky) 🐶: You set up local hooks. When you try to commit, it yells at you about formatting and blocks the commit until you manually fix it.

Both methods are passive. They tell you something is broken, but they leave the cleanup to you. When you're using an AI coding agent to generate the code in the first place, manually babysitting its output defeats the purpose.

🚀 Enter `no-mistakes`

no-mistakes is a CLI tool that intercepts your git push. Instead of sending your code straight to origin, it routes it through a localized validation pipeline.

⚙️ How it actually works:

🧱 The Hidden Sandbox: When you trigger it, it creates a temporary git worktree in the background. Your active editor stays completely undisturbed.
✅ Validation: It runs your tests, linter, and build steps inside that isolated sandbox.
🔁 The AI Feedback Loop: If a test fails, it captures the error log and hands it back to an AI agent, essentially saying: "You broke this test. Fix it."
🟢 The Clean Push: Once the AI patches the code and all tests pass, it pushes the clean code to GitHub and auto-opens a Pull Request. It then deletes the temporary sandbox.

🌟 What Makes It Stand Out

The biggest differentiator is that it is active, not passive.

If a pre-commit hook fails, the process stops. If no-mistakes fails, it initiates an agentic review loop. It uses an interactive Terminal UI (TUI) to show you exactly what the AI is trying to fix. If the AI gets stuck, you can step in and provide guidance right in the terminal.

It also integrates natively with tools like Claude Code. You can literally tell your agent, "Use the /no-mistakes skill to verify and gate these changes," and it will handle the entire lifecycle. 🤯

✨ Key Features at a Glance

🔇 Non-Blocking: Because it uses hidden worktrees, you can immediately start working on your next feature while it tests and fixes the last one in the background.
🔀 Auto-Rebase: It automatically rebases your code on top of the latest main branch before testing, preventing hidden merge conflicts.
📝 Auto-Documentation: It reviews the code changes and updates your README.md to keep documentation from going stale.
💚 Clean PRs: You never push failing builds upstream.

🛠️ How to Get Started

Setup takes about 30 seconds. ⚡

1. Install the CLI tool globally:

curl -fsSL https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/install.sh | sh

2. Initialize it in your project folder:

no-mistakes init

This wires up a new git remote proxy called no-mistakes.

3. Change how you push:

The next time you (or your AI) finish a feature, skip git push origin. Instead, run:

git push no-mistakes

The tool will take over, spin up the worktree, run your suites, fix the AI's slop, and open the PR for you. 🎉

💬 Let's Discuss

As AI agents write more of our code, our tooling needs to shift from writing to verifying.

How are you currently handling AI-generated bugs in your workflow? Are you still manually running tests and fixing the AI's mistakes, or have you started automating the review loop? Let me know in the comments! 👇

I Tested Nex-N2-Pro — A Free Open-Source Model That's Matching GPT-5.5 on Coding Benchmarks

Divyesh — Tue, 09 Jun 2026 07:01:12 +0000

TL;DR: Nex-N2-Pro by Nex AGI is a free, open-source MoE model (397B params, 17B active) built on Qwen3.5. It scores 75.3 on Terminal-Bench 2.1 — top-3 globally, open or closed — and introduces "Adaptive Thinking" that dynamically scales its reasoning depth per task. You can run it right now on OpenRouter for free.

The Problem With Most Reasoning Models Today

Every modern reasoning model has the same flaw: they think at the same depth regardless of what you ask.

Ask one to add two numbers? Full chain-of-thought. 2,000 tokens of internal monologue. For 1 + 1.

Ask it to architect a distributed system? Same 2,000 tokens. Not enough.

It's like hiring someone who takes a three-hour meeting to answer "yes" and a three-hour meeting to redesign your database. The fixed-depth reasoning budget is wasteful on simple tasks and dangerously shallow on complex ones.

Nex-N2-Pro just shipped a real answer to this problem.

What Is Nex-N2-Pro?

Nex-N2-Pro is an open-source agentic reasoning model by Nex AGI, released June 2, 2026. It's post-trained on Qwen3.5-397B-A17B and built specifically for:

Agentic coding loops (write → run → debug → iterate)
Long-horizon software engineering tasks
Deep research across large document sets
Tool use and function calling in agent pipelines

It comes in two variants:

Variant	Base	Total Params	Active Params	Best for
Nex-N2-Pro	Qwen3.5-397B	397B	17B	Full agentic workloads
Nex-N2-mini	Qwen3.5-35B	35B	3B	Low-latency, edge deployment

The Architecture: Why 397B Parameters Costs Less Than You Think

This is a Mixture-of-Experts (MoE) model. That means despite 397B total parameters, only 17B are active per forward pass. In practice, the inference cost is closer to a 17B dense model — not a 397B one.

Other key specs:

Context window: 262,144 tokens (262K) — load an entire codebase, no chunking needed
Max output: 256K tokens
Native capabilities: Vision, Reasoning, Tool Calling, Structured Outputs, Function Calling
Recommended serving: Nex AGI's customized sglang fork (nexagi/sglang:v0.5.12)

The Core Innovation: Agentic Thinking = Adaptive + Coherent

Nex-N2-Pro's "Agentic Thinking" framework has two components that work together:

1. Adaptive Thinking — Efficiency by Design

The model dynamically decides whether to reason deeply and how much, based on task complexity. Simple prompts execute fast. Multi-step agent tasks trigger structured, deep planning.

This isn't just a nice property — it's architecturally enforced at training. The result:

Faster responses on straightforward tasks
More reliable outcomes on hard, multi-step problems
No wasted token budget on tasks that don't need it

2. Coherent Thinking — One Reasoning Paradigm, All Tasks

A single consistent reasoning framework is applied across coding, research, tool use, and multimodal tasks. No context-switching penalty when a task crosses domains (e.g., "research this API, then write code that calls it").

This is what makes it genuinely useful for agentic pipelines — the model doesn't lose context or change behavior when switching between subtasks.

The Full Agentic Loop

Requirement Understanding
       ↓
   Task Planning
       ↓
 Code Implementation
       ↓
Environment Feedback (actual execution output)
       ↓
Evaluation & Debugging
       ↓
Continuous Iteration → back to Task Planning if needed

The key word is Environment Feedback — the model actually runs code, reads the output, and incorporates it. It's not simulating execution. It's doing it.

Benchmark Results

Benchmark	What It Measures	Nex-N2-Pro Score	Context
Terminal-Bench 2.1	Real terminal/coding tasks	75.3	Top-3 globally (open + closed)
GDPval	Long-horizon task planning	1585	Competes with GPT-5.5
SWE-Atlas	Real software engineering	Strong	Verified generalization
DeepSWE	Agentic SWE tasks	Strong	End-to-end dev loops

For context: these aren't "write a function" benchmarks. Terminal-Bench 2.1 and SWE-Atlas test actual software engineering workflows — the kind you'd run in a real development loop.

How to Try It Right Now (Free)

Via OpenRouter (Zero Setup)

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "nexagi/nex-n2-pro",
    "messages": [
      {"role": "user", "content": "Refactor this function to use async/await and add error handling: [your code here]"}
    ]
  }'

Via SiliconFlow (Free Tier — $0/M Tokens)

Available at siliconflow.cn — model string: Nex-AGI/Nex-N2-Pro

Self-Hosted

docker pull nexagi/sglang:v0.5.12
# Then load the model weights from HuggingFace: NexAGI/Nex-N2-Pro

Real-World Performance: What It Actually Feels Like

The benchmark numbers tell one story. Here's the practical one:

What it does well:

Multi-file refactoring tasks where it needs to hold context across the whole repo
Debugging loops — it reads the stack trace, forms a hypothesis, patches, re-runs
Tool-calling workflows where it needs to chain 5–10 API calls in sequence
Research-to-code tasks (read a paper, then implement the algorithm)

Where you'll hit limits:

Very low-latency use cases (it's still a large model; mini variant helps here)
Highly specialized domain knowledge outside its training distribution

Watch: Benchmark Review & Speed Test

A deep-dive benchmark review comparing Nex-N2-Pro against closed-source giants. Worth watching before you decide whether to integrate it into your stack.

The Bigger Picture

For the last two years, the open-source vs. closed-source AI gap looked like this: open models were 6–12 months behind frontier commercial models on coding benchmarks.

Nex-N2-Pro changes that calculus. A 75.3 Terminal-Bench 2.1 score puts it in the same conversation as GPT-5.5 and Claude Opus 4.7 — and it's completely free to use and open-weight.

The trend is clear: the next competitive battleground isn't just raw reasoning ability. It's execution reliability — can the model actually complete a real task end-to-end, in a real environment, without falling apart?

Nex-N2-Pro's Adaptive Thinking and closed agentic loop are a serious answer to that question.

Discussion

For those who've tried it: how does the agentic loop hold up on your actual codebase vs. your current daily driver?

Specifically curious whether the "Environment Feedback" loop meaningfully reduces back-and-forth compared to, say, Claude Code or Cursor. Drop your experience below — benchmark scores are one thing, but real-world dev workflow is another.

Odysseus: The Self-Hosted AI Workspace That Bundles Everything (60k+ ⭐)

Divyesh — Mon, 08 Jun 2026 03:35:21 +0000

I Tried PewDiePie's Open-Source AI Workspace. It's Actually Good.

Yes, that PewDiePie.

Felix Kjellberg (110M YouTube subscribers) spent late 2025 building a home AI lab — 8 modified RTX 4090s, 256GB of VRAM, running on Arch Linux. He called it "The Swarm." He crashed it running 64 models in parallel.

The web frontend he built for it? He open-sourced it. Called it Odysseus. It hit 59,000 GitHub stars fast.

I dug into the code expecting a glorified Ollama wrapper. It's not.

What it actually is

Odysseus isn't just another chat UI. It bundles things no other self-hosted tool does in one place:

Chat — local or cloud models (Ollama, vLLM, llama.cpp, OpenAI, OpenRouter, GitHub Copilot)
Agent mode — shell, files, web, MCP tools, per-tool toggles
Cookbook — scans your GPU, recommends models that actually fit, downloads and serves them in one click
Deep Research — multi-step web research that writes you a cited report
Email — IMAP/SMTP with AI triage, auto-tagging, draft replies
Calendar — CalDAV sync with Radicale, Nextcloud, Apple, Fastmail
Memory — persistent, evolving across all your conversations

No cloud account. No telemetry. MIT license. Everything lives in your data/ folder.

The Cookbook is the standout feature

Every other self-hosted UI assumes you already know what model to run. Odysseus doesn't.

It scans your hardware, scores 270+ models against your actual VRAM, and gives you a one-click download-and-serve. It understands GGUF vs FP8 vs AWQ. It picks the right backend (vLLM, llama.cpp, Metal on Apple Silicon). Downloaded models persist in a volume — no re-downloading after container restarts.

For someone who wants local AI but finds the ecosystem confusing, this is the most accessible on-ramp that currently exists.

The code is better than the meme suggests

The README has a little ASCII bear face. Don't let it fool you.

The entry point app.py is 1,092 lines of real production thinking. A few things that stood out:

The .env loader handles Windows BOM silently:

load_dotenv(encoding="utf-8-sig")
# Notepad saves UTF-8 with a BOM. Without this, AUTH_ENABLED=false
# parses as AUTH_ENABLED=false — auth is never actually disabled.

Hard timeouts on all requests, except streaming:

REQUEST_HARD_TIMEOUT = 45  # seconds
# /api/chat, /api/research, /api/shell/stream are exempt
# Everything else gets killed — no event loop lockups for all users

Proxy-aware localhost bypass:

def _is_trusted_loopback(request):
    # Cloudflare tunnels connect FROM 127.0.0.1
    # Without this, tunnel traffic looks like localhost and bypasses auth.
    # Check for forwarding headers first.

There's also a full THREAT_MODEL.md — rare for a project this young. It's honest about the open gaps: no shell sandbox, coarse token scopes, one SSRF vector in active remediation. That kind of transparency matters.

How it compares

	Odysseus	Open WebUI	AnythingLLM
Model serving (one-click)	✅	❌	❌
Email + Calendar	✅	❌	❌
Scheduled agent tasks	✅	❌	❌
Community maturity	Young	Established	Stable
Production-ready	Not yet	Yes	Yes

Open WebUI (124k stars) is the mature, team-ready choice. AnythingLLM wins on document RAG. Odysseus bets on integration depth — the only tool that connects models, memory, email, calendar, and research in a single local stack.

That bet is interesting even if it's not fully baked yet.

Getting started

git clone https://github.com/pewdiepie-archdaemon/odysseus.git
cd odysseus
docker compose up -d --build
# Opens at http://localhost:7000
# Temporary admin password prints in terminal on first boot

NVIDIA GPU passthrough:

scripts/check-docker-gpu.sh --install-nvidia-toolkit --enable-nvidia-overlay

Apple Silicon (Metal — Docker on Mac can't access the GPU):

./start-macos.sh  # Opens at http://127.0.0.1:7860

What's rough right now

The roadmap says: "I don't know what I'm doing, help." Appreciate the honesty.

Real rough edges:

Cookbook is fragile on non-standard GPU/driver combos
Agent context bloat — on 8k-context local models, tool schemas eat your window before your prompt starts
Wide attack surface — shell + email + browser + MCP in one process is a lot of trust before the sandbox PR lands

For personal home lab: run it now. For team deployments: give it six months.

Why it matters

Subscriptions are getting expensive. Privacy policies keep shifting. A capable 12B model on a consumer GPU now costs only electricity.

The missing piece has always been the workspace layer — something that treats local AI as a real daily tool, not a demo. Odysseus is the most serious attempt at building that in one deployable package.

It started from one person's janky home lab. It's MIT-licensed with no sales funnel. The data directory is yours. The model weights are yours.

That framing matters more in 2026 than it did a year ago.

GitHub: pewdiepie-archdaemon/odysseus

What's your current self-hosted AI setup — and what would it actually take for you to move your workflows off cloud providers?

Reviving a 12K+ Star Abandoned Library: toastr-next v3 🍞

Divyesh — Wed, 27 May 2026 04:59:28 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

toastr-next v3 a complete revival of CodeSeven/toastr, one of the most-starred abandoned JavaScript libraries on GitHub with 12,000+ stars and no meaningful commits since 2016.

toastr was the go-to notification library for millions of developers. But time wasn't kind to it. it required jQuery, had no TypeScript, no dark mode, no accessibility, and its Gulp + LESS build chain was completely dead. It was a library everyone knew but nobody could use in a modern project without guilt.

I picked it up, stripped it to the bones, and rebuilt it from scratch for 2026.

From this 👇🏻:

// 2015 — drag in jQuery just to show a toast
<script src="jquery.min.js"></script>  // 30 KB
<script src="toastr.min.js"></script>  // 5 KB
// Total: ~87 KB of dead weight

toastr.success('Hello!');

To this 👇🏻:

// 2026 — zero dependencies, full TypeScript, ~4 KB gzipped
import { toastr } from 'toastr-next';

const toast = toastr.success('Hello!');
await toast.dismissed; // Promise API!

~4 KB gzipped. No jQuery. No bloat. Just toasts. 🍞

Demo

Dark mode — toasts firing with progress bar

Light mode — same demo, toggled with the ☀️ button

🌐 Live Demo: toastr-next.vercel.app/

📦 npm: npmjs.com/package/toastr-next

🐙 GitHub: github.com/Divyesh-5981/toastr-next

The Comeback Story

Where it was

The original repo — abandoned since 2016, 12k stars, zero recent activity

Problem	Detail
jQuery required	~87 KB overhead just to show a notification
No TypeScript	No types, no IntelliSense, no safety
No dark mode	Hard-coded colors, no CSS variables
No accessibility	Screen readers couldn't detect toasts at all
JS-driven animations	Layout thrash, janky on low-end devices
No Promise API	No way to await a toast dismissal
No keyboard support	Couldn't dismiss with Escape key
Dead build toolchain	Gulp + LESS, completely unmaintained since 2016
No ESM support	Global UMD only, no tree-shaking

What I built

🏗 TypeScript Rewrite (Zero Dependencies)

No jQuery: 100% strict TypeScript with full JSDoc.
Universal Formats: Ships in ESM, CJS, UMD, and IIFE (works from Vite to raw <script> tags).

🎨 CSS-First Theming

Modern CSS: Uses CSS variables instead of inline JS styles.
Themes & Motion: Auto dark mode (prefers-color-scheme), manual toggle (localStorage), and prefers-reduced-motion support.
Layouts: 4 pure CSS animation presets (Fade, Slide, Bounce, Flip) and native RTL support.

♿ Accessibility (built to WCAG 2.1 AA practices)

Screen Readers: Dynamic ARIA live regions role="alert" (assertive) for errors/warnings and role="status" (polite) for success/info, with aria-atomic.
Keyboard Navigation: Toasts are focusable and sit in the natural tab order; pressing Escape while a toast is focused dismisses it, and auto-dismiss pauses while a toast holds focus.

🔌 Modern API

Async & Events: Promises (await toast.dismissed) and lifecycle event subscriptions (toastr.subscribe, which returns an unsubscribe function).
DX & Security: Automatic CSS injection (no separate stylesheet import), native React wrapper (useToastr), and built-in XSS protection.

📦 Production Ready

Lightweight: ~4 KB gzipped (~2 KB JS + ~2 KB CSS) vs the original ~87 KB jQuery version.
Live: Available on npm as toastr-next with a live Vercel demo.

Size comparison

	toastr v2 (old)	toastr-next v3
Total size	~87 KB (with jQuery)	~4 KB gzipped
Dependencies	jQuery required	Zero
TypeScript	✕	✓
Dark mode	✕	✓ Auto + manual toggle
Accessibility	✕	✓ WCAG 2.1 AA practices
Promise API	✕	✓
React support	Third-party only	✓ Built-in
Animations	JS (jQuery)	✓ CSS @keyframes
Bundle formats	Global UMD only	✓ ESM, CJS, UMD, IIFE
CSS import	Required	✓ Auto-injected

My Experience with GitHub Copilot

I used GitHub Copilot as a pair programmer throughout the entire revival not for autocomplete, but as a genuine collaborator at every architectural decision.

Here's exactly how it helped, step by step.

1. Deciding what to keep

Before writing a single line, I needed to know what was worth saving from 14 years of jQuery-tangled code.

Prompt:

"Here is the original toastr v2 source. What's worth keeping
for backward compatibility and what should be completely rewritten?"

Copilot identified the API surface success, error, info, warning — as the only thing worth preserving. Everything underneath needed to go. This became the guiding rule for the entire rewrite.

2. TypeScript interfaces

With the API surface locked, I needed a clean type system built around it.

Prompt:

"Design TypeScript interfaces for ToastrOptions, ToastResponse,
and ToastEvent. I want every toast call to return a Promise
that resolves when the toast is dismissed."

Copilot designed all three interfaces. The standout was the dismissed: Promise<void> pattern on ToastResponse making every toast awaitable:

const { dismissed } = toastr.success('Changes saved');
await dismissed;
// runs after the toast closes

I didn't ask for this pattern specifically. Copilot suggested it unprompted, and it became the most-loved feature of the rewrite.

3. Theming system

I wanted dark mode to work automatically and be manually overridable without JavaScript touching the CSS side.

Prompt:

"I need a CSS theming system that supports auto dark mode via
prefers-color-scheme AND manual override via a data-theme attribute
on the html element. No JavaScript should be needed for the CSS side."

Copilot proposed the [data-theme] + @media (prefers-color-scheme) layering pattern. The media query handles auto mode; a single attribute flip handles manual override. No JS. No flicker. Just CSS doing its job.

4. Accessibility

I had applied role="alert" to all four toast types, assuming it was correct. I asked Copilot to review before shipping.

Prompt:

"What ARIA roles and aria-live values should toast notifications use
to be WCAG 2.1 AA compliant? Should all toasts use the same role?"

Copilot flagged that role="alert" is assertive it interrupts a screen reader mid-sentence. That's right for errors and warnings, but jarring for a success message. The fix:

Type	Role	Behaviour
`error`, `warning`	`role="alert"`	Interrupts immediately
`success`, `info`	`role="status"`	Waits for a pause

A subtle WCAG 2.1 distinction I would have shipped wrong without this review.

5. CSS auto-injection

Early users kept asking why they had to import the CSS separately. That broke the drop-in promise. I needed the stylesheet bundled inside the JS, self-injecting on import.

Prompt:

"Write a Vite generateBundle plugin that reads the extracted CSS asset
and injects it into every JS chunk as a self-executing style injector.
Add a guard so it only injects once even if the module is imported
multiple times, and make it safe to run during SSR."

Copilot drafted the generateBundle plugin — CSS-to-string conversion plus a self-executing injector that appends a <style id="__toastr_next_css__"> to <head>. The guard checks document.getElementById(...) so it only injects once even if multiple bundles (core + React) load on the same page, and it bails out when document is undefined (SSR-safe). I later refactored it into one shared plugin reused across the core, IIFE, and React builds.

This was the most technically complex Copilot collaboration in the project and the one that impressed me most.

6. Demo page

The final piece was a demo site that actually showed off everything that changed.

Prompt:

"Build a demo page for toastr-next with a quick fire section,
a live playground with dropdowns for type/animation/position,
an animation showcase, a before/after comparison, and a light/dark
theme toggle that persists to localStorage."

Copilot built the full index.html iteratively playground, comparison table, custom ARIA dropdown, and the light/dark toggle with localStorage persistence. I directed; it executed. The entire demo came together in an afternoon.

What I took away

Copilot wasn't writing boilerplate it was catching real bugs, proposing patterns I hadn't considered, and solving problems I didn't know how to start. The dismissed: Promise<void> feature, the WCAG role distinction, and the CSS-injection plugin were all things I got from Copilot that I wouldn't have shipped on my own.

That's the kind of collaboration this challenge is designed to reward.

After the main rewrite, I ran the entire codebase through GitHub Copilot to audit for hidden anti-patterns and code smells. It helped me spot subtle optimizations and edge cases, allowing me to refine the code into a truly polished, production-grade architecture.

The audit - for hidden anti-patterns and code smells.

Improvements - for hidden anti-patterns and code smells.

Working with Copilot felt less like using a tool and more like having a senior developer who knew every API, caught every edge case, and never got tired. The revival that would have taken weeks took days.

Acknowledgements

Huge respect to the original authors — John Papa, Tim Ferrell, and
Hans Fjällemark - who built something so good that developers were still reaching for it a decade later.

This revival exists because their original work was worth finishing ❤️

DEV Community: Divyesh

Your AI Forgets Everything. Here's How Cognee Fixes It.

Why does AI forget everything?

What is Cognee?

How does it work?

Four operations, one lifecycle

Try it in 60 seconds

Where this shows up

Cognee vs. plain RAG

When to use it

Wrapping up

OSS Maintainers Lose Hours to Vague Issues. I Built a GitHub Action to Fix That.

The Context: A 72-Hour Hackathon About Slop Detection

The Problem With Current Issue Triage

What It Looks Like in Practice

How the Scoring Engine Works

Step 1: 7 Heuristic Signals

Step 2: The Ambiguous Zone (4–6)

The Comment and Labels

Setup Is One File

Benchmark Numbers (and Why Precision Is Lower Than Recall)

What I'd Do Differently

Try It

We Added React Doctor to Our UI Kit Monorepo. Here's What It Found.

What Is React Doctor?

Setup in a Monorepo

What It Actually Caught

How to Use It Effectively

The Real Value

Try It

I Added an AI Gate Before Every git push with no-mistakes 🛡️

😩 The Problem With Traditional Workflows

🚀 Enter no-mistakes

⚙️ How it actually works:

🌟 What Makes It Stand Out

✨ Key Features at a Glance

🛠️ How to Get Started

💬 Let's Discuss

I Tested Nex-N2-Pro — A Free Open-Source Model That's Matching GPT-5.5 on Coding Benchmarks

The Problem With Most Reasoning Models Today

What Is Nex-N2-Pro?

The Architecture: Why 397B Parameters Costs Less Than You Think

The Core Innovation: Agentic Thinking = Adaptive + Coherent

1. Adaptive Thinking — Efficiency by Design

2. Coherent Thinking — One Reasoning Paradigm, All Tasks

The Full Agentic Loop

Benchmark Results

How to Try It Right Now (Free)

Via OpenRouter (Zero Setup)

Via SiliconFlow (Free Tier — $0/M Tokens)

Self-Hosted

Real-World Performance: What It Actually Feels Like

Watch: Benchmark Review & Speed Test

The Bigger Picture

Discussion

Odysseus: The Self-Hosted AI Workspace That Bundles Everything (60k+ ⭐)

I Tried PewDiePie's Open-Source AI Workspace. It's Actually Good.

What it actually is

The Cookbook is the standout feature

The code is better than the meme suggests

How it compares

Getting started

What's rough right now

Why it matters

Reviving a 12K+ Star Abandoned Library: toastr-next v3 🍞

What I Built

Demo

The Comeback Story

Where it was

What I built

🏗 TypeScript Rewrite (Zero Dependencies)

🎨 CSS-First Theming

♿ Accessibility (built to WCAG 2.1 AA practices)

🔌 Modern API

📦 Production Ready

Size comparison

My Experience with GitHub Copilot

1. Deciding what to keep

2. TypeScript interfaces

3. Theming system

🚀 Enter `no-mistakes`