Introducing Dendrux Open-Source AI Agent Library

Why does every AI review start from zero? Why burn thousands of tokens re-discovering the same call chains, the same module structure, the same dependency graph every single time? The idea isn't new. code-review-graph already solved this in Python and it works. I've been using it. But Python has a ceiling: single-threaded parsing, GIL contention on large repos, and startup overhead that adds up when you're calling it 50 times a day through MCP. So I rewrote the entire thing in Go. Not a wrapper. Not bindings. A ground-up port designed around goroutines, channels, and SQLite WAL mode. Result: code-review-graph-go Same concept. Fundamentally different performance characteristics. Here's what changed in the Go version: → Goroutine-parallel parsing: Tree-sitter across 17 languages, N=NumCPU workers. 1,800 nodes and 10,000+ edges in ~1.5 seconds. The Python version does this sequentially. → SQLite with WAL mode concurrent readers, mutex-serialised writer. Incremental updates only re-parse what git diff says changed, then expand to dependents via multi-hop BFS. → Hybrid search engine: FTS5 BM25 + vector embeddings merged via Reciprocal Rank Fusion. "UserService" auto-boosts Class results. "get_user" auto-boosts Functions. Context-file boosting for what you're actively editing. The Python version has this too, the Go version adds the RRF merge with zero-allocation hot path. → 19 MCP tools that drop into Claude Code, Cursor, Windsurf, Zed, Continue, or OpenCode with a single install command. Full JSON-RPC 2.0 over stdio. → Execution flow tracing that walks every code path from entry point to leaf call, scored by criticality (file spread, security sensitivity, test coverage gaps). → Refactoring engine previews renames across every call site, detects dead code, suggests moves based on community structure, and applies changes with path-traversal safety checks. → Auto-generated wiki from your codebase's community structure. Markdown pages with member tables, flow summaries, and cross-community dependencies. → Context-aware hints the MCP server tracks your session, infers whether you're reviewing/debugging/refactoring, and appends next-step suggestions to every tool response. All of it runs locally. No API keys. No cloud. Just a single Go binary + SQLite. Full credit to the original Python project by Tirth Kanani for the architecture and the idea. Today I'm open-sourcing the whole thing. But here's what I really want: If you work on a codebase with 500+ files, try it. Run build, then search, then detect-changes. See if the graph catches relationships you didn't know existed. Then tell me what's broken. Want to compare it against the Python version on your repo? I'd genuinely love to see those benchmarks. This is better with a community. GitHub: https://lnkd.in/gSjZP3ay Drop a star if this resonates. PRs are very welcome. #opensource #golang #python #ai #codereview #mcp #llm #developer #tooling #treesitter #sqlite #performance

I built a tool called lede. It skims a document and pulls out the most important sentences... actual sentences from the source, not paraphrased, not hallucinated. Quote-only summarization. Here's the deal: an LLM call doing the same job takes 500–5000 ms, costs money, and gives you different bytes every time (an sometimes goes way way off script). lede does it in 0.4 ms in Python and 0.13 ms in Rust. Byte-identical across both runtimes. Zero required dependencies. Why bother? Every modern AI app pushes more text through more LLM calls than is healthy, and the 2026 narrative is that preprocessing in front of the model is a 40–94% cost lever. But the libraries doing that preprocessing today are heavyweight, non-deterministic, or single-runtime; and most just give you a summary when what you actually need for RAG is the summary plus the dates, amounts, and entities your metadata column is begging for. Many of my current projects are doing RAG prep, MCP middleware, or LLM Heavy processing. The idea is lede can help on anything where you call an LLM in a loop and your token bill is climbing, drop this in front of it. Apache-2.0, Python and Rust, same fixture corpus governs both. https://lnkd.in/eaiY3ZaX

I spent 3 hours debugging a RecursionError at 2 AM. Turns out, I had no idea what recursion was actually doing to memory. Here's what changed everything for me 👇 ───────────────────── 🧠 WHAT RECURSION REALLY IS ───────────────────── Most tutorials say: "A function that calls itself." That's true. But incomplete. The real story? Every recursive call pushes a new stack frame into RAM. Local variables. Arguments. Return address. All of it — sitting in memory, waiting. For factorial(5), Python holds 6 frames simultaneously before returning a single value. ───────────────────── ⚠️ THE HIDDEN DANGER ───────────────────── Python's default recursion limit is 1000. Hit it → RecursionError. Ignore it → bloated memory. Each frame costs ~300–400 bytes. 1000 frames = ~400 KB of stack. And unlike Java or Scala, Python has NO tail-call optimization. Even "optimized" tail recursion still creates new frames. ───────────────────── ✅ THE FIX ───────────────────── → Use @lru_cache for overlapping subproblems (fib, DP) → Convert deep recursion to iteration → Use trampolining for functional-style recursion → Raise sys.setrecursionlimit() only when you understand why ───────────────────── 💡 THE MENTAL MODEL ───────────────────── Think of the call stack like a stack of plates. Each call = add a plate. Base case = stop adding. Return = remove plates one by one. You wouldn't stack 10,000 plates. Don't stack 10,000 frames. ───────────────────── Recursion isn't bad. Blind recursion is. Understand the memory. Write better code. ───────────────────── Found this useful? ♻️ Repost to help a developer who's debugging at 2 AM right now. Follow me for daily Python deep-dives that go beyond the surface. #Python #Programming #SoftwareEngineering #CodeQuality #PythonTips #RecursionExplained #LearnPython #Developer

429 and 400 are both exceptions. They are not the same problem. That's the main reason a lot of LLM retry code is wrong. A lot of teams wrap OpenAI or Anthropic calls in a generic retry decorator and call it resilience. But LLM APIs do not fail in one uniform way. A call can fail because you are being throttled. Because you are out of quota. Because the provider is overloaded. Because the network flinched. Or because your request is bad and was never going to succeed. Those failures should not get the same response. Retrying too early just churns. Retrying quota exhaustion hides a billing problem. Retrying a context-window failure burns money on a request the API will never accept. The right model is classification first, response second. I just shipped OpenAI and Anthropic integrations for redress, a Python failure-handling library I maintain. It is used in production for retries, circuit breaking, and failure classification in distributed Python services. Full writeup, including a multi-provider fallback pattern that uses classification to decide when fallback is actually appropriate, is linked below. https://lnkd.in/gwZfn548 What retry anti-patterns have bitten you in production?

𝐏𝐲𝐭𝐡𝐨𝐧 𝐝𝐞𝐟𝐢𝐞𝐬 𝐥𝐨𝐠𝐢𝐜 (𝐰𝐞𝐥𝐥 𝐤𝐢𝐧𝐝𝐚). In the real world, if you take one undeniable truth and combine it with another undeniable truth, you just get...well, the absolute Truth (I guess). Even in strict computer science, if you run Boolean values through logic gates, the outcome is always logical. ⁠ True ⁠ OR/ AND ⁠ True ⁠ equals ⁠ True ⁠. Nowhere in the realm of Boolean algebra does combining two truths suddenly generate the number two. This is where Python hisses (jk, jk). You might expect a logical output like ⁠ True ⁠, or perhaps a run-time error telling you that you can't perform arithmetic on philosophical concepts. Instead, Python confidently bypasses formal logic entirely and spits out a number: 2. Wait, what? Since when do two truths equal two? The reason for this quirky behaviour lies in Python's rich history and a clever bit of language architecture. In its early days, like many languages, Python didn't actually have a dedicated Boolean data type. We simply used the integers 1 to represent ⁠ True ⁠ and 0 to represent ⁠ False ⁠. It wasn't until ⁠ Python 2.3 ⁠ that ⁠ True ⁠ and ⁠ False ⁠ were officially introduced as built-in constants. However, to ensure that millions of lines of older code didn't suddenly break, the developers made a pragmatic compromise. They created the new bool class, but made it a direct subclass of the int (integer) class. Because of this inheritance, under the hood, Python still treats ⁠ True ⁠ as exactly equal to 1 and ⁠ False ⁠ as 0. When you ask it to calculate ⁠ True + True ⁠ using the standard addition operator, it drops the boolean masks, ignores the logic gates, and simply calculates 1 + 1. So, as a quirky byproduct of Python's commitment to backward compatibility, this feature remains built into the language today. It has become a favourite piece of trivia for developers, proving that in the Pythonic universe, logic is often just basic math hiding in plain sight! 𝐀𝐮𝐭𝐡𝐨𝐫𝐞𝐝 𝐛𝐲: Vybhav Chaturvedi

Just shipped codectx v0.3.0!! For context — codectx is a CLI tool that compiles your codebase into structured context for LLMs. Instead of dumping raw source, it uses AST parsing and dependency graphs to figure out what actually matters and what doesn't. Benchmarks show 55–92% token reduction vs naive approaches on real-world Python repos. v0.3.0 is the biggest update since the initial release. Here's what changed: Embedding cache — codectx now stores embeddings in LanceDB and only re-processes files that have actually changed. If you're running it repeatedly on a large codebase, subsequent runs are noticeably faster. Watch mode — codectx watch . keeps context up to date as you work. Changes are batched over a debounce window so it's not rebuilding on every save. JSON output — --format json for pipelines, tooling, or anything that needs to consume the output programmatically instead of reading a markdown file. LLM summaries — --llm with OpenAI, Anthropic, and Ollama support. Swaps out the default AST-generated summaries with model-generated ones for your most critical files. Falls back gracefully if the provider call fails. Go support — the import resolver now parses go.mod to correctly strip module prefixes and resolve repo-relative paths. The old behavior was just broken for most Go projects. Also shipped in this release: symbol cross-referencing across files, constants extraction in structured summaries, and automatic demotion of config files (pyproject.toml, package.json, etc.) out of the core context tiers. If you've used it before, pip install --upgrade codectx gets you everything. GitHub: https://lnkd.in/gVzysfEw Docs: codectx.granth.tech

Most LLM apps break in production because nobody validated what goes in or comes out. 𝗚𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀 𝗔𝗜 is the Python framework that fixes exactly this. It wraps your LLM calls with composable validators that check for PII leaks, hallucinations, toxicity, schema violations, and more before anything hits your users. When a validator fails, it doesn't just crash. It re-prompts automatically and returns a corrected output. The Guardrails Hub ships over 65 pre-built validators, so you aren't writing boilerplate checks from scratch every time. Structured data extraction from LLMs specifically goes from a painful parsing problem to a solved one, because the framework validates against a JSON schema and handles the retry loop for you. It also exposes a standalone REST API, which means your non-Python services can plug in without friction. 🔗 Link to repo: github(.)com/guardrails-ai/guardrails --- ♻️ Found this useful? Share it with another builder. ➕ For daily practical AI and Python posts, follow Banias Baabe.

Eliminate tool schema bloat! Give an AI agent 30+ MCP tools and thousands of tokens of JSON schemas eat the context window every turn. codemode-lite takes a different approach. Instead of flooding the agent with tool schemas, it exposes one tool: run_python. The agent writes Python, calls whatever tools it needs from inside a secure sandbox, and only the final result comes back. No schema bloat. No context growth. Two sandbox options: Podman containers for persistent state with enterprise isolation, or Pyodide WASM via Node.js for lightweight stateless execution. Add new MCP servers by dropping a JSON config. No code changes needed. Blog: https://lnkd.in/eTiBesX9 #AI #LLM #MCP #OpenSource #RedHat

For years, building high-performance backend APIs in Python meant working 𝘢𝘳𝘰𝘶𝘯𝘥 one big limitation: 𝘁𝗵𝗲 𝗚𝗹𝗼𝗯𝗮𝗹 𝗜𝗻𝘁𝗲𝗿𝗽𝗿𝗲𝘁𝗲𝗿 𝗟𝗼𝗰𝗸 (𝗚𝗜𝗟). If your FastAPI service handled 𝗖𝗣𝗨-𝗵𝗲𝗮𝘃𝘆 𝘄𝗼𝗿𝗸𝗹𝗼𝗮𝗱𝘀 — like ML inference, image processing, or data crunching — you likely added multiprocessing, task queues, or external workers. Not because you wanted to… but because you had to. 𝗡𝗼𝘄, 𝘁𝗵𝗮𝘁 𝘀𝘁𝗼𝗿𝘆 𝗶𝘀 𝗰𝗵𝗮𝗻𝗴𝗶𝗻𝗴. With 𝗣𝗘𝗣 𝟳𝟬𝟯 and upcoming 𝗻𝗼-𝗚𝗜𝗟 (𝗳𝗿𝗲𝗲-𝘁𝗵𝗿𝗲𝗮𝗱𝗲𝗱) 𝗯𝘂𝗶𝗹𝗱𝘀 𝗶𝗻 𝗣𝘆𝘁𝗵𝗼𝗻 𝟯.𝟭𝟯+, threads can finally run 𝗶𝗻 𝘁𝗿𝘂𝗲 𝗽𝗮𝗿𝗮𝗹𝗹𝗲𝗹 𝗮𝗰𝗿𝗼𝘀𝘀 𝗺𝘂𝗹𝘁𝗶𝗽𝗹𝗲 𝗰𝗼𝗿𝗲𝘀. No more artificial ceiling on CPU-bound performance. 𝗪𝗵𝗮𝘁 𝘁𝗵𝗶𝘀 𝗺𝗲𝗮𝗻𝘀 𝗶𝗻 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲 Early benchmarks are already showing: • 𝗠𝘂𝗹𝘁𝗶-𝗳𝗼𝗹𝗱 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗴𝗮𝗶𝗻𝘀 for CPU-heavy endpoints • 𝗠𝗶𝗻𝗶𝗺𝗮𝗹 𝗰𝗼𝗱𝗲 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 — often just switching the Python build • 𝗡𝗼 𝗶𝗺𝗽𝗮𝗰𝘁 𝗼𝗻 𝗮𝘀𝘆𝗻𝗰 𝗔𝗣𝗜𝘀 (they were never GIL-bound anyway) 𝗔 𝘀𝗵𝗶𝗳𝘁 𝗶𝗻 𝗵𝗼𝘄 𝘄𝗲 𝗱𝗲𝘀𝗶𝗴𝗻 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 We’re moving from: “𝘜𝘴𝘦 𝘮𝘶𝘭𝘵𝘪𝘱𝘳𝘰𝘤𝘦𝘴𝘴𝘪𝘯𝘨 𝘵𝘰 𝘦𝘴𝘤𝘢𝘱𝘦 𝘵𝘩𝘦 𝘎𝘐𝘓” To: “𝘊𝘩𝘰𝘰𝘴𝘦 𝘣𝘦𝘵𝘸𝘦𝘦𝘯 𝘢𝘴𝘺𝘯𝘤, 𝘵𝘩𝘳𝘦𝘢𝘥𝘴, 𝘰𝘳 𝘱𝘳𝘰𝘤𝘦𝘴𝘴𝘦𝘴 𝘣𝘢𝘴𝘦𝘥 𝘰𝘯 𝘵𝘩𝘦 𝘸𝘰𝘳𝘬𝘭𝘰𝘢𝘥” 𝗪𝗵𝘆 𝘁𝗵𝗶𝘀 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 𝗳𝗼𝗿 𝗯𝗮𝗰𝗸𝗲𝗻𝗱 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 • 𝗦𝗶𝗺𝗽𝗹𝗲𝗿 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀 (less need for extra worker layers) • 𝗕𝗲𝘁𝘁𝗲𝗿 𝗖𝗣𝗨 𝘂𝘁𝗶𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻 on modern multi-core machines • 𝗖𝗹𝗲𝗮𝗻𝗲𝗿 𝘀𝗰𝗮𝗹𝗶𝗻𝗴 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 without over-engineering 𝗧𝗵𝗲 𝗯𝗶𝗴𝗴𝗲𝗿 𝗽𝗶𝗰𝘁𝘂𝗿𝗲 We’re getting closer to a world where: 𝗣𝘆𝘁𝗵𝗼𝗻 + 𝗙𝗮𝘀𝘁𝗔𝗣𝗜 is not just great for I/O-bound services But also a 𝘀𝗲𝗿𝗶𝗼𝘂𝘀 𝗰𝗼𝗻𝘁𝗲𝗻𝗱𝗲𝗿 𝗳𝗼𝗿 𝗖𝗣𝗨-𝗶𝗻𝘁𝗲𝗻𝘀𝗶𝘃𝗲 𝗔𝗣𝗜𝘀 𝗪𝗵𝗮𝘁 𝘆𝗼𝘂 𝗰𝗮𝗻 𝗱𝗼 𝘁𝗼𝗱𝗮𝘆 • Track 𝗣𝗘𝗣 𝟳𝟬𝟯 and Python 3.13 progress • Experiment with no-GIL builds in 𝘀𝘁𝗮𝗴𝗶𝗻𝗴 𝗲𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀 • Rethink parts of your system that rely on multiprocessing Where do you see no-GIL making the biggest impact ?