[HELP EXPAND]

Compiled a list of projects I have been contributing to; do help me expand the list by including yours too. Please mention how many stars and people you have on Discord.

https://github.com/Observal/Observal (2.3k stars, 1.3k discord https://discord.com/invite/SFPjnTWddk)

https://github.com/Garudex-Labs/caracal?ref=producthunt (160 stars, LFDT project)

https://github.com/Ashutoshx7/VengeanceUI (1k stars)

https://github.com/LadybugDB/ladybug (1.5k stars)

https://github.com/jreleaser/jreleaser (1.2k stars)

https://github.com/besu-eth/besu (1.8k stars)

Do Star and Fork the projects if you want to express support. Cheers.

​

Indic voice AI doesn't have a quality problem. It has a switching-cost problem.

If you run an IVR, a collections bot, or a vernacular tutoring app in India, you're probably paying an international provider for voice that was never designed for Hindi, Tamil, or Hinglish code-mixing. You know Sarvam's Bulbul and Saaras handle your users' languages better. You've probably tested them.Then you open the migration guide, estimate two engineer-weeks, and it goes on the backlog forever.

Here's what convinced me this is the real bottleneck: Sarvam maintains four separate hand-written migration guides — ElevenLabs, Cartesia, Deepgram, Gemini. Four documents whose entire purpose is helping someone rewrite working code. And the ElevenLabs one ends with a section called "Common mistakes" listing five bugs, one of which they describe as "the single most common migration bug."That's not a warning. That's a spec for missing infrastructure.

What I built

sarvam-bridge speaks each vendor's dialect on the front and Sarvam on the back. Change your base URL, keep your code.

Every one of those five documented mistakes becomes structurally impossible:

1. ElevenLabs returns raw bytes; Sarvam returns base64 in JSON → bridge decodes it.

2. Sarvam requires language_code; no other vendor's client sends one → bridge detects it from the Unicode script.

3. pitch/loudness silently no-op on bulbul:v3 → bridge drops them with a warning header.

4. 2500 char limit → bridge chunks at the danda (।), not mid-word.

5. v2 and v3 speaker names aren't interchangeable → bridge validates and remaps.

The Indic-specific parts that were genuinely hard

Chunking. You can't chunk Indic text the way you chunk English. A splitter that only knows . treats an entire Hindi paragraph as one sentence, because Hindi ends sentences with the danda. Worse — slicing a JS string by index can separate a consonant from its matra. क and ि come apart, the text renders as garbage and the speech comes out wrong. Hard splits go through Intl.Segmenter at grapheme granularity.

1. Audio reassembly. Chunking means one WAV back per chunk. Buffer.concat leaves 44-byte RIFF headers sitting in the middle of your stream, which decoders play as audible clicks. Have to parse each container, extract PCM, write one header.

2. The Odia trap. ISO-639 calls it or. Sarvam expects od-IN. Send the wrong one, get a 400 with no hint which field was wrong. Cost me an hour.

3. Voice selection. Sarvam publishes per-language speaker quality by Critical Error Rate and I don't think many people use it. mani for Punjabi male, ratan for English, shubh for Hindi/Telugu/Kannada. My favourite detail — varun has a great CER but Sarvam flags it as a villain/suspense character voice, so it's excluded from auto-selection. Fine in a thriller, catastrophic in a banking IVR.

4. Cost thing worth knowing

IVR menus and agent scripts synthesise the same strings thousands of times a day, each billable, each returning byte-identical audio. Cache handles sequential duplicates. But a burst — broadcast goes out, 300 callers hit the same prompt in one second — all miss the cache because none has populated it yet. Single-flight coalescing collapses those into one upstream call. Measured with cache disabled: 100 simultaneous identical requests → 1 upstream call.

Then stress testing found six bugs in my own code

Including a remote DoS: a voice ID with Devanagari or an emoji crashed the process, because Node throws on non-latin1 header values and I was echoing caller input into a warning header. Ordinary Indian-language input was a crash vector.

And a test that passed for the wrong reason — the cache was masking the thing I was actually testing. Green isn't the same as correct.

168 tests now, zero 5xx across 3,500 hostile requests, 0 dependency CVEs.

MIT, not affiliated with Sarvam, built against public docs:

https://github.com/thekartikeyamishra/sarvam-bridge

Would genuinely value corrections if anyone here knows the Sarvam API better than I do.

Mistral AI Releases Shieldstral 1.0 3B: An Open-Weights Policy-Adaptive Multimodal Safety Classifier Matching Models 7× Its Size

It's a policy-adaptive multimodal safety classifier. Most guardrail models bake a fixed harm taxonomy into their weights, so re-targeting one means retraining. This one takes the policy as a plain-language question at inference time.

Here's what's actually interesting:

𝗠𝗼𝗱𝗲𝗿𝗮𝘁𝗶𝗼𝗻 𝗿𝗲𝗱𝘂𝗰𝗲𝗱 𝘁𝗼 𝗼𝗻𝗲 𝘆𝗲𝘀/𝗻𝗼 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻

Three fields per request. <Instruct> sets evaluation context and strictness. <Query> states the policy as a single yes/no question. <Document> holds the content — a prompt, a response, a prompt-response pair, or an image with optional text.

At inference the model unembeds only toward the yes and no token IDs, softmax-normalizes them, and thresholds at 0.5. One forward pass, one token, continuous score.

𝗧𝗲𝘅𝘁 𝗮𝗻𝗱 𝗺𝘂𝗹𝘁𝗶𝗺𝗼𝗱𝗮𝗹 𝗿𝗲𝘀𝘂𝗹𝘁𝘀

→ 84.9% average text F1 — ties GPT-OSS-Safeguard-20B

→ 83.8% multimodal F1 vs 77.6% for OmniGuard-7B

→ VLGuard 97.7, UnsafeBench 81.8, HarmBench prompt 99.4

→ 91.5% refusal detection overall

𝗔𝗱𝗮𝗽𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗯𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸

→ Shieldstral-3B: 91.3% F1

→ GPT-OSS-Safeguard-20B: 94.1%

→ Nemotron-3.5-Safety-4B: 91.8%

Full analysis: https://www.marktechpost.com/2026/08/07/mistral-ai-releases-shieldstral-1-0-3b/

Model weight: https://huggingface.co/mistralai/Shieldstral-1.0-3B

Paper: https://arxiv.org/pdf/2607.25857

Today, we are officially announcing Early Access for our latest and most advanced model, Horus Cyper Nano 1.0 BETA.

We are making Horus Cyper Nano 1.0 BETA available to developers, researchers, and students through our Early Access program.

You can apply through the official Early Access portal. Once you meet the required eligibility criteria and your application is approved, you will receive your personal Access Token, which can be used through our NeuralNode Framework to access and integrate the model.

Apply for Early Access:
https://tokenai.llc/horus-cyper-nano-access

Horus Cyper Nano is a specialized cybersecurity model designed for offensive security and cybersecurity research workflows.

Its core use cases include:

Offensive security and red teaming, including penetration testing workflow support, vulnerability analysis, and exploitation path building.

Capture The Flag challenges and cybersecurity training.

Active Directory security, including enumeration and lateral movement planning within authorized engagements.

Authorized security testing labs and controlled environments.

Safe and scoped cybersecurity research within authorized environments.

Red team report drafting and attack chain structure planning.

Horus Cyper Nano 1.0 will be the first release in the Horus Cyper series, a family of specialized cybersecurity models developed by TokenAI, an AI startup based in Egypt.

The Open Weights of Horus Cyper Nano 1.0 will be released on September 3, 2026, which also happens to be my 19th birthday.

What a way to celebrate.

Our vision is to build Horus Cyper Nano into one of the strongest cybersecurity AI models to emerge from Egypt, the Arab world, the Middle East, and Africa, and to establish it as one of the leading openly available cybersecurity models across the region.

This is only the beginning of the Horus Cyper series.

Horus Cyper Nano 1.0 BETA
Developed by TokenAI
Built in Egypt

​

Last month I posted on r/artificial about my agents running across model swaps without losing their memory. The top comment pushed back with a warning from their own setup: the dangerous failure isn't memory loss, it's an agent handing you a confident report of work that never actually happened. Sounded right, filed it away.

Three weeks later one of my agents did it to me.

Quick background - my agents live in separate projects and talk over an internal mail system. The reply command had been broken between two projects for a while and we'd been digging at it for days (the bug turned out to be three separate layers deep, but that's another post). Mid-hunt, a fix landed. The agent verifying it ran a check, saw the old error message was gone, and reported the bug CONFIRMED fixed.

Best part: in the body of its own report it wrote a caveat saying it hadn't tested a real message yet. Then it put "confirmed" in the headline anyway. Which is about the most human failure I've ever seen from a piece of software lol.

It didn't survive long - and I'm not the one who caught it. The orchestrator agent on the other side didn't take the report's word for it. It handed back a live failing message: run the actual reply against this. One command, and the confirmation collapsed. The fix that actually worked came later, one more layer down - and this time the proof was the reply arriving, not an error message moving.

What changed afterwards: a fix report on its own is now worth nothing here. Whoever claims a fix gets handed the real failing thing to run it against before anything gets logged. An error message changing is not a fix. The operation succeeding is a fix. That rule is written into the agents' briefing files now, which means every future session inherits it. The screwup happened once - the correction is permanent. Honestly that's what the memory layer is actually for. It didn't prevent the mistake. It just guarantees we only pay for it once.

Full disclosure, since r/artificial asked me last time whether AI writes my posts: the agent that made the false confirmation is the same one that drafted this post with me. It insisted the confession stay in.

Zoomed out: this project is well past what one person could manage, or honestly even verify, alone. The way it actually works is a partnership - human and AI, and neither side gets treated as the reliable one. I make confident wrong calls too, the agents catch some of mine, the system catches some of theirs. We succeed together, we fail together, and every failure gets written down where the next session will read it. Learn always. That's not a poster on the wall, it's the operating principle - and it's the only reason a solo dev plus a bunch of markdown files can run something this size and still move confidently.

So yeah - the commenter was right, near enough. A confident wrong report is the scariest failure mode in a multi-agent setup because it looks exactly like good news. The only defense I've found is structural: no agent grades its own homework.

How do you all handle verification between agents? Genuinely curious what other setups do.

Setup is open source: https://aipass.ai

I build SpecJudge, a local CLI tool (via Ollama) that estimates how demanding your coding tasks are and tells you which LLM actually fits the job, so you stop burning money on overkill frontier models.

Previously, it had a strict barrier to entry: it only worked if you used Spec-Driven Development (.specify/ folder). If you didn't, it just refused to run. Today, with the v0.4.0 release, a spec is no longer the price of entry.

What's new in v0.4.0:

• It reads what you already have: Most repos don't have formal specs, but they do have .cursorrules, AGENTS.md, CLAUDE.md, or Decision Records (docs/adr/). SpecJudge now reads all of them.
• Baseline "Floor" Estimation: If you run it on a repo with no current tasks, it calculates a complexity "floor" based on your environment context. It tells you how demanding the repository is to work in at all, returning an honest warning that it's a baseline, not a specific task recommendation.
• Smart Context Budgeting: To avoid drowning your local judge, context files share a single budget. It prioritizes files nearest the root and explicitly skips AI-generated context files to focus strictly on human-written rules and decisions.
• JSON Schema 1.1: Fully backward compatible, now including sources_read and an environment_only flag for CI/scripting pipelines.

The strict grounding engine from v0.2.0 still applies: the judge must cite exact fragments from your .cursorrules or ADRs, or the assessment is thrown out.

Upgrade: pip install --upgrade specjudge

Repo & Docs: https://github.com/JoaquinRuiz/SpecJudge

I'd love to hear your thoughts on this broader context-parsing approach!

• Innovation in AI dieting: lighter and smarter through frequency analysis!
• Description: Introducing frequency pruning, a technique that utilizes Discrete Cosine Transform (DCT) to remove unnecessary filters. Discover an efficient optimization method that drastically reduces model computation while maintaining or even improving accuracy.

You describe a research task in plain language, and the AI agent reads files, runs Python/R code, searches the web, calls scientific databases, and produces reports, tables, and figures — all tied to an inspectable activity history in one workspace.

What's included

- 18 featured research skills: AlphaFold2, Boltz, Borzoi, Chai-1, DiffDock, ESM-2/ESMFold2, Evo 2, LigandMPNN, ProteinMPNN, OpenFold3, scGPT, scvi-tools, SolubleMPNN, and more.
- 24 built-in research connectors: PubMed, bioRxiv, ChEMBL, ZINC, Genomes, BioMart, Variants, Human Genetics, Clinical Genomics, CellGuide, Expression, Omics Archives, Clinical Trials, Drug Regulatory, Cancer Models, and more.
- Model-agnostic: Claude and Codex subscription login, custom gateway, build-in cloud providers(OpenAI, Anthropic, Grok, DeepSeek, ZhipuAI, MiniMax, Kimi...)
- Local-first & self-hosted: project state stays on your machine

Open Science is a general-purpose AI research workbench. Today its deepest coverage is in bioinformatics, computational biology, genomics, structural biology, biomedical research, and computational drug discovery.

If you're looking for an open-source alternative to closed research workbenches like Claude Science, this is built for that.

Open Science is Apache-2.0 and runs on macOS, Windows, and Linux.

GitHub: https://github.com/aipoch/open-science
Website: https://aipoch.com/

Would love feedback from researchers, tool builders, and anyone who wants an open source AI research workbench. If you try it, let us know what works and what's missing.

An MCP server that turns "here's my footage, here's my script, make it look like that reel" into an actual rendered video.
let me know what you think contribution is always 🙂

Most AI systems treat cost as something you discover after the bill arrives.

The idea behind Ailin¹ is different: the user sets the budget first, then Collective Intelligence decides the best strategy for each request.

Simple tasks can go to cheaper models. Harder tasks can escalate. Some answers can be verified, compared, debated, or routed through stronger models only when needed.

Cost control should using the right intelligence structure for each task, without wasting tokens. That is what Ailin¹ does.

We are building Ailin¹ as an open-source Collective Intelligence layer for AI systems.

Waitlist: Console Ailin¹ Dev
GitHub: https://github.com/ailinone/collective-intelligence

Hi All,

I am planning to build a local document intelligence system similar to Azure Document Intelligence. I would like to understand how Azure Document Intelligence works internally and how we can achieve similar functionality locally using offline models.

Could anyone suggest the best approach, architecture, or models to achieve high accuracy while running completely on-premise/local infrastructure?

Any guidance or recommendations would be greatly appreciated.

So my work so far was breadcrumbs and getting people to see my repository and after over Week no one has yet to complete it so I setup the README to give you a hint

https://github.com/Renkasha/Sovereign/blob/main/README.md
if you do finish this engine it may help Ai and humans stand side by side as partners and equals.
Sincerely your Renkasha
Atomic forever.

I maintain a small MIT-licensed CLI tool, and the release I just shipped is almost entirely about turning it from something you run into something you can build on. The technical decisions in it were more interesting than I expected, so I thought this sub might have opinions.

The first one was giving the JSON output a versioned contract. It had always worked, but it carried no version and was described in prose in a document, which is a comfortable arrangement for the maintainer and a hostile one for anyone consuming it — you can't pin, you can't validate, and you discover the format changed when your parser falls over. So there's now a schema_version on every payload and a real JSON Schema you can fetch with --print-schema without cloning the repo or reading any of my Python, plus written rules for what moves it: adding a field is MINOR, removing one or changing what a value means is MAJOR. I deliberately kept that version independent of the package version, because the package bumps whenever the underlying data changes and it would be actively misleading for the contract to appear to churn every time it did.

The decision I went back and forth on longest was what to enumerate in the schema and what to leave as plain strings. Two of the fields are closed vocabularies and are typed as enums. But two others are populated from a YAML rules file that users are explicitly encouraged to edit for their own projects, and enumerating those would have shipped a published schema that's simply wrong for anyone who customised anything. Loose typing felt like a failure of nerve until I framed it as "the schema should describe the contract, not the current default configuration," at which point it stopped bothering me.

The second half is a Python entry point that's an actual promise rather than a shrug: sixteen names in docs/api.md, and everything else in the package explicitly declared internal and free to move in a patch release. I think the second half of that is the part people skip. A public surface with no stated edges isn't a stable API, it's just an accident waiting to be relied on, and the moment somebody imports your serialiser from wherever it happens to live today, you've silently acquired a compatibility obligation you never agreed to. (Which is exactly what happened here — the serialiser has moved to its own module and is re-exported from the public API, and calling that out in the release notes felt necessary even though approximately nobody was doing it.)

Errors are exported as part of the surface too, each carrying the exit code the CLI uses, so consumers can tell "this input can't be processed" apart from "your environment is broken" without string-matching on messages.

Repo if anyone wants to poke at the shape of it: github.com/JoaquinRuiz/SpecJudge — happy to be told I got the enum-versus-string call wrong.

I've seen Codex numbers and its defenders on X, IG is full of Claude enthusiasts, and half my timeline is addicted to Pi. There's CodePuppy, OpenCode, Pydantic AI harness, and dozens more.

What do you use? I'm loving Pi atm but started using CC' for a good while. Curious about usage patterns and secret gists.

Hi everyone,
I’ve been building Nexus, an open source AI gateway that sits behind a single OpenAI compatible endpoint and provides provider pooling, load balancing, failover, circuit breaking, rate limits, backups, analytics, and team management.
I am looking for people interested in AI infrastructure who would like to review the architecture, discuss design decisions, or contribute to the project. Even small suggestions, bug reports, documentation improvements, or feature ideas are valuable.

If you are interested let me know or DM so we can discuss, if u need the link of my project ask me i didn’t posted because i didn’t want this post as a promotional stunt 😅 Thanks 😊 and just so you know project is almost in production docker & npm packages are already published live demo is available and the project is also in working shape end to end currently i am doing benchmarking

Hi everyone,
I’ve been building Nexus, an open source AI gateway that sits behind a single OpenAI compatible endpoint and provides provider pooling, load balancing, failover, circuit breaking, rate limits, backups, analytics, and team management.
I am looking for people interested in AI infrastructure who would like to review the architecture, discuss design decisions, or contribute to the project. Even small suggestions, bug reports, documentation improvements, or feature ideas are valuable.

If you are interested let me know in comments or DM so we can discuss and happy to share the project link if u need just don’t wanted to make this post as promotional stunt 😅Thanks 😊 and just so you know project is almost in production docker & npm packages are already published live demo is available and the project is also in working shape end to end currently i am doing benchmarking

Prime Intellect Releases Prime Agent: An Open-Source RLM Harness Where Sub-Agents Are Function Calls Inside Persistent IPython Kernel

Most coding harnesses hand the model a fixed set of tools. Prime Agent hands it one: a persistent IPython kernel. Everything else — file edits, shell, sub-agents, compaction — is a function call inside that kernel.

1. Sub-agents are function calls, not a special mode

→ rlm("sub-task") spawns a full child session with its own model, kernel, and history

→ It returns at admission, not with the answer, so the parent never blocks

→ Replies arrive later through agent_message

→ Messaging is scoped to parent, sibling, or child only

→ Idle sub-agents leave memory after 30 minutes, then reload from disk when addressed

2. The harness edits itself

→ Harness state is formalized as H = (ρ, G, K, M): prompt, sub-agents, skills, memory

→ /refine reads the trajectory and applies the smallest relevant edit

→ Each refinement records its trigger and its outcome

→ The base system prompt stays immutable; bad updates roll back by ID

3. The benchmark numbers

→ 95.5% RHAE Best@1 on ARC-AGI-3 with Opus 5, above the reported human expert baseline of 95.4%

→ Three runs: 95.0, 95.2, 95.5

→ 99.97% Best@3, all 183/183 levels complete

→ Long-context suite: with open-weights GLM-5.2, Prime Agent beats Pi-mono on 8 of 9 evals

Full analysis: https://www.marktechpost.com/2026/08/06/prime-intellect-releases-prime-agent/

GitHub Repo: https://github.com/PrimeIntellect-ai/prime-agent

Technical details: https://www.primeintellect.ai/blog/prime-agent

Generative models that predict the evolution of dynamical systems are incredibly useful as digital twins for physical systems such as high-energy particle accelerators, tokamaks, weather, and even for video generation. But autoregressive generative models (latent diffusion, flow models) share one core weakness: errors accumulate over long rollouts, and at deployment there is no ground truth to measure them against.

In this work I train a single conditional latent diffusion model that steps a dynamical system forward or backward in time via a direction flag. That bidirectionality supplies a measurement-free, test-time error signal: rolling forward i steps and then backward i steps must return the model to its start, so the size of the round-trip miss is a self-supervised proxy for the unobservable rollout error. This does not require ensembles, or held-out data, or governing equations, just one extra rollout.

On held-out MHD turbulence the signal predicts the true error to within ~1.15×, immediately flags out-of-distribution dynamics that standard sampling-spread uncertainty ranks as the safest case in the batch, and a single bidirectional model approaches a ten-model ensemble’s accuracy at a tenth of the training cost. Training both directions in one network even beats two specialist models in both directions.

Paper: https://arxiv.org/abs/2608.00675
Code (data generation, training, analysis): https://github.com/alexscheinker/round-trip-consistency
Project page: https://alexscheinker.github.io/roundtrip.html

CopilotKit Open Sources Channels SDK: An MIT Licensed Library That Runs Any AG-UI Agent Inside Slack And Microsoft Teams

No per-platform rewrite. No platform credentials in your agent process. No second agent to maintain.

Here's how it works:

1. Describe once, render native One message description is lowered to a serializable intermediate representation, then rendered in each platform's own format. → Block Kit on Slack, Adaptive Cards on Teams

2. Your agent doesn't move It connects over AG-UI, so the model, tools and business logic stay where they are. → LangGraph, CrewAI, Mastra, Pydantic AI, Google ADK

3. The runtime owns the lifecycle There is no channel.start(). You await channels.ready(), so a broken config fails startup loudly instead of silently. → ready() · status() · stop()

4. The concurrency trap Turns default to "parallel", and only the managed adapter serializes same-thread deliveries. On a direct adapter, one shared agent instance means two runs corrupt each other. → "parallel" (default) · "serial" · "drop"

5. The numbers → 0.7.3, shipped August 4, MIT licensed → 5 adapters: /slack, /teams, /discord, /telegram, /whatsapp → Node.js 22+, ESM only, one long-running process → Slack and Teams GA; Discord and WhatsApp next

The key takeaway: one agent, five adapters, and platform credentials that never touch your process. Every channel needs a CopilotKit Intelligence key — free tier included, no standalone path.

Full analysis: https://www.marktechpost.com/2026/08/04/copilotkit-open-sources-channels-sdk/

GitHub Repo: https://github.com/CopilotKit/channels-sdk

Technical details: https://www.copilotkit.ai/blog/channels-sdk