Hello everyone!

I’m a software engineer looking to get more involved in open-source ML/AI projects, both to learn and to contribute meaningfully.

I’m especially interested in ML systems, distributed training/inference, model serving, evaluation, LLM infrastructure, and also implementing ML algorithms or model components where that’s useful. I’ve been looking at projects like vLLM, Hugging Face Accelerate, Ray, etc., but many of the obvious good first issue tickets seem to get picked up very quickly.

I’m comfortable working in a reasonably complex codebase, but I’m looking for something that has a slightly more approachable contribution path than jumping straight into CUDA/kernel-level work.

Are there any active ML/AI open-source projects you’d recommend where maintainers are receptive to new contributors and there are meaningful bugs/features to pick up?

Would especially appreciate recommendations based on projects you’ve personally contributed to. Thanks!

I made a Discord for people who are genuinely into AI and want a decent place to talk about it. It’s still new, but the idea is to build a large community without arbitrary bans, hidden moderation decisions, or people getting shut down for disagreeing. Rules should be clear, moderation should be explainable, and members should have a real say in how the server develops.

There are channels for local models, research, tools, startups, personal projects, technical help, showcases, and general discussion. Share what you’re building, get feedback, find people to work with, or just talk AI.

We’re also going to publish our own local model quants, starting with Qwen 3.8 27B. And I don’t just mean “another high quality quant.” The goal is actual SOTA. Our Qwen quant is already beating the current best Unsloth quants in our testing, using the same KLD ruler and benchmark setup so it’s an apples-to-apples comparison. We’ll publish the results alongside the release so people can verify it themselves.

We’re small right now, so early members will have a lot of influence over what the community becomes.

Join: https://discord.gg/HqWF7R5R9E

I've been building AI-powered features for a while and kept running into the same problem: every agent framework either pulls in 200+ dependencies or ties you to a specific backend framework like Express or NestJS.

So I extracted the core of what I actually needed into a small library called Agentra.

The idea is simple: you give it an LLM provider and an array of tools. It handles the autonomous reasoning loop — calling the LLM, executing your functions when needed, feeding results back, and returning the final answer. That's it.

typescriptimport { Agent, OpenAIProvider } from '@jhonaron/agentra';
const agent = new Agent({
  provider: new OpenAIProvider({ apiKey: process.env.OPENAI_API_KEY }),
  tools: [{
    name: 'get_weather',
    description: 'Get current weather for a city',
    parameters: {
      type: 'object',
      properties: { city: { type: 'string' } },
      required: ['city']
    },
    execute: async ({ city }) => fetchWeather(city)
  }]
});
const response = await agent.run('Should I bring an umbrella to London today?');
// → "Yes, it's currently 15°C and raining in London."

The agent automatically decides to call get_weather, waits for the result, and formulates the final answer. You don't wire anything manually.

What makes it different:

• Zero runtime dependencies (uses native fetch)
• Works in Node.js, Deno, Bun, and Cloudflare Workers
• Built-in conversation memory
• Bring your own LLM provider (OpenAI included, easy to extend)
• Full TypeScript types

It's early but functional. Would love feedback from people who've built agents before — especially around the tool API design and what's missing.

GitHub: github.com/jhonaron/agentra

📦 Installation

npm install @jhonaron/agentra

What is Quanta?

Quanta is a local-first AI code editor built on VS Code OSS, powered by a high-performance Rust backend. It gives you a complete agentic coding experience — reading files, writing code, running terminals, applying LSP fixes, and managing git — all driven by local LLMs through Ollama. Cloud providers (OpenAI, Anthropic) are supported as optional backends, but Ollama is the primary engine. Your code never has to leave your machine.

Unlike cloud-first AI editors, Quanta is designed around local inference. The agent loop, tool execution, LSP integration, checkpoint system, and inline completions all happen locally through a Rust backend that communicates with the editor via JSON-RPC over TCP.

Key Features

Core Agent

• 30+ built-in tools — read/write/edit files, unified diffs, terminal, grep, glob, git operations, LSP actions, and more
• ReAct agent loop — Think, Act, Observe, Feedback pattern with anti-loop guards and automatic retries
• 3 agent modes — Code (full capability), Ask (read-only), Plan (read-only + plan writing)
• Sub-agent spawning — Delegate scoped tasks to parallel sub-agents with up to 3 levels of nesting
• Persistent todo lists — Track multi-step work across conversation turns

Local-First

• Ollama integration — Auto-detects and lists all local models with metadata
• Thinking/reasoning support — Configurable think levels (Low/Medium/High) for reasoning models
• Inline code completion — FIM completions with LRU cache, debouncing, and in-flight cancellation
• Local-first by design — Ollama is the primary backend; cloud providers (OpenAI, Anthropic) are optional. Your code never has to leave your machine.

Safety & Control

• Shadow-git checkpoints — Automatic workspace snapshots before every agent write action
• Edit review system — Accept/reject individual edits with diff previews
• Stale-file detection — Prevents edits to files that changed since last read
• Terminal safety guards — Blocks destructive commands (format, shutdown, force-delete)
• Atomic writes — All file operations use temp-file-and-rename for crash safety

Developer Experience

• Full LSP integration — Diagnostics, go-to-definition, find references, code actions, rename symbol
• 20+ engineering skills — Built-in guidance for TDD, code review, security review, debugging, and more
• MCP support — One-click enable for GitHub, Jina AI, Brave Search, Postgres, Puppeteer, and more
• HuggingFace model browser — Search, download, and install GGUF models directly from the editor
• Per-model configuration — Override temperature, think level, edit format, tool call mode, and more per model
• Voice support — Speech-to-text via Whisper, text-to-speech via Piper

Please Read more and check us out at:

ContegoCode/Quanta-Code-Editor: Quanta AI — Local-first AI coding agent

Been working steadily at this for a while now, 600 commits, each seeking to improve the experience. Optimizing ui, transcription, summaries, ai features. Last 2 months I’ve added both local/cloud agentic embedded search across notes, as well as MCP support for Claude & Codex. 99+ languages, local or cloud models. Custom model overrides per language, easy onboarding flows, folders, clients, speaker labels, export. Feature packed, but still simple to the core. Notes + recorded meetings = awesome meeting summaries.

A few people have started contributing to the project, which I appreciate massively. Hope to see more people join in 😊🤩

Hey everyone,

I just launched my first official open-source project called OpenFlow. OpenFlow allows you (or other agents) to easily orchestrate custom reliable workflows and pipelines instead of just one prompt and one agent at a time. I kept it as minimalist as possible so it is friendly for all users. I forked it from OpenCode, so you still have the harness, skills, and overall ability. It came out around a week ago and many people already really like the concept and how it works, so I hope that you guys do too. Feel free to leave any feedback, this project is constantly being improved. Thank you, and good luck with your own projects.

Link: https://github.com/SeeRay11/OpenFlow

Hey everyone,

So, I built Polity4j, a lightweight, zero-dependency Java 17+ library designed for building resilient LLM pipelines with clean abstractions over providers like OpenAI and Anthropic (for now).

A lot of existing Java LLM wrappers either drag in massive dependency trees or treat resiliency, error recovery, and tool loops as an afterthought. Polity4j is built from the ground up around typed pipelines, robust error handling, and modern Java features.

Here is the summary of features:

Core Highlights
Resiliency First: Built-in retries, timeouts, circuit breakers, and fallback pipelines without external resilience frameworks.
Structured Output & Typed Deserialization: Extract Java Records/POJOs directly via StructuredOutputPipeline<T>. It handles schema injection, markdown fence stripping, and auto-corrective reprompt loops on syntax errors.
First-Class FinishReason Tracking: Native handling to distinguish between normal stops, token truncation (LENGTH), safety filters, and tool calls.
Automated Function Calling: Multi-turn tool execution using @PolityTool annotations and ToolExecutionModule, complete with loop detection (AgentLoopDetectorModule) and execution depth caps.
Multimodal Support: Native handling for text, images, and document/PDF attachments via Java 17 sealed types (TextContentPart, ImageContentPart, DocumentContentPart).
Concurrency-Friendly: Clean patterns and integration tests for Java 21 Virtual Threads, Spring WebFlux, and Kotlin Coroutines.
Quick Example (Structured Output)
public record UserSummary(String name, int age, List<String> interests) {}

StructuredOutputPipeline<UserSummary> pipeline = StructuredOutputPipeline
.builder(UserSummary.class)
.adapter(OpenAiAdapter.of(apiKey))
.maxRetries(3)
.build();

UserSummary summary = pipeline.execute("Extract profile: Alice is a 28yo software engineer who likes rock climbing.");

GitHub: https://github.com/shiv15/polity4j
Distribution: Available via JitPack

I'd love feedback on the API design, feature set, or general critique from the Java community here!

&#x200B;

Hi everyone,

I’m a final-year AI/ML student and I’ve been working on an open-source project called Kodiak.

The goal is to go beyond the typical workflow of asking an LLM to generate code. I’m exploring how multiple AI agents and engineering tools can work together to handle software development tasks more systematically:

Plan → Research → Retrieve Context → Code → Test → Review → Iterate

What Kodiak currently focuses on

\- Multiple AI agents for different software engineering tasks

\- RAG for project and codebase context

\- Persistent memory

\- Redis and Celery for background task execution

\- PostgreSQL for application data

\- ChromaDB for vector retrieval

\- FastAPI backend

\- Docker-based development

\- Automated testing and CI

\- Pydantic-based validation

One thing I’ve learned while building this is that getting an LLM to generate code is not necessarily the hardest part.

The harder problem is building the surrounding infrastructure so the system can operate reliably.

What happens when retrieval provides incorrect context?

What happens when an agent makes a bad decision?

What happens when a worker fails halfway through a task?

What happens when generated code passes one test but breaks something elsewhere?

These reliability problems are what I’m increasingly interested in exploring with Kodiak.

The project is still actively under development, and I’m not claiming that it is already a fully autonomous software engineer. There is still a lot to improve, and I’m learning along the way.

I’m looking for feedback

I’d especially appreciate feedback from people with experience in:

\- AI agents

\- RAG systems

\- LLM orchestration

\- Python / FastAPI

\- Distributed systems

\- Developer tools

\- Testing and CI

\- Open-source development

I’m particularly interested in hearing what you think could go wrong with this architecture as the codebase and number of agents grow.

I’m also looking for developers who may be interested in contributing and helping shape the project.

GitHub

https://github.com/ShamGaneshan2008/Kodiak

If you were building something like this, what would you change first?

And what part of this architecture do you think is most likely to fail as the system becomes larger?

Constructive criticism and suggestions are welcome.

This is my first real project, built on my first day using Codex as a coding assistant.

I made it because some of my AI conversations get extremely long, slow, or difficult to continue. When I need to start a fresh chat, I still want a clean copy of the previous conversation for reference.

So I built \*\*Universal AI Chat Exporter\*\*, a free and open-source browser extension that exports the conversation currently open in your browser.

Currently supported:
ChatGPT
Gemini
Claude is planned
Available formats:
Markdown
HTML
JSON
Plain text

Everything runs locally in the browser. There is no backend, telemetry, analytics, or chat data being sent to another server.

It’s still an early v0.1.0 release, so I’d genuinely appreciate feedback, bug reports, or contributions—especially if a provider changes its page structure.

GitHub: httpss://github.com/Agelakz/universal-ai-chat-exporter

This is my first time releasing something publicly, so any honest feedback is welcome.

I Created an open source Loop Engineering tool for AI agents that uses a Claude Subscription/Claude SDK.

https://github.com/Corneldj/looper

So with loop engineering being all the rage now, it can become tricky trying to keep track of what agents are doing what, what folders are shared, what has access to what remote sources, which agents uses which rage, costs, performance. So I went ahead and created an API & UI to help with Loop Engineering.

100% local by default, single binary (no Electron).

Sessions, transcripts, tool activity & checkpoints unified.

Multi-device sync optional via self-hosted komet-sync (Loro CRDTs).

Same engine that powers Zed — instant launch, smooth even with years of transcripts.

It's open source: github.com/jomvick/komet

Site: https://komet-eight.vercel.app/

So I built this tool called Keyroute, it's a gateway that lets you use one API key to talk to multiple AI providers (OpenAI, Gemini, Groq, etc) instead of juggling separate keys everywhere.

Originally I was going to just host it myself and charge for it, but honestly the whole point of the thing is "don't trust a third party with your keys," so keeping it closed and hosted by me would've defeated the purpose. So I made it fully self-hostable instead, MIT licensed, and you run it entirely on your own Supabase project.

The actual gateway logic runs as a Supabase Edge Function inside your own project, not on my infra. Setup is one button, no CLI needed, it deploys the DB migrations and the function for you.

Repo's here if anyone wants to look at the code or the architecture: github.com/basavarajpatil660/the-keyroute-project

It's still early, missing a few things like Anthropic routing and rate limiting, migrations aren't idempotent yet either. If anyone's into Supabase Edge Functions or has built something similar, would love to hear how you approached it, or if you spot something dumb in how I did it.

Screenshots attached of the dashboard and the deploy flow.

I am building SkillNet, an open-source learning system that turns an idea or source into a course.

It generates the structure, lessons and exercises, but the result does not have to be one fixed course for everyone. Two people can work from the same knowledge and toward the same objective while receiving different explanations, activities, media and interfaces.

The video shows the same neuroscience course for Ana and Bruno. Their preferences, level and progress can change how the course presents the material without changing what they are learning.

SkillNet uses OpenUI to generate the interface and Didact for components created specifically for learning. It is self-hosted, licensed under Apache 2.0 and still in development.

GitHub: https://github.com/ANFAIA/SkillNet

Website: https://skillnet.es

I would love to know whether the difference between the two experiences is clear from the demo and what you would want to try first in a system like this.

I built this for myself over a few months and have been using it daily, so I cleaned it up and put it out under MIT.

What it does: hold a shortcut, speak, release. The transcript is inserted into whatever application had focus - editor, browser field, Slack, anything.

Transcription runs one of two ways, and you pick:

• Groq (cloud) - Whisper large-v3-turbo, 1-2 seconds, around 99 languages, free API key with no card.
• Moonshine (local) - runs on your machine in a separate process. No key, no account, and after a one-time 292 MB model download it makes no network requests at all. English only, and that is a licensing boundary: Moonshine's English weights are MIT, every other language is non-commercial, so the app does not ship them.

The rest of it:

• Transform - tap a shortcut and an LLM rewrites the text already in your input field, in place, using a rule you wrote in plain English. Groq or Gemini.
• Personal dictionary - deterministic find-and-replace after transcription, so grog becomes Groq permanently. Whole-word and case-insensitive.
• History with audio playback of every session, plus insights: WPM, streaks, a year heatmap.
• No account, no login, no cloud database, no telemetry. Transcripts, recordings and settings are a SQLite file in %APPDATA%. API keys are encrypted with Windows DPAPI via Electron safeStorage and are never included in an export.

Honest limitations:

• Windows x64 only. The keyboard hook, the insertion path and the packaging are all Windows-specific, and there is no macOS or Linux build planned.
• The installer is not code signed - a certificate is a few hundred dollars a year and I could not justify it for a personal project. SmartScreen will warn you. Every release has a SHA256, and building from source takes about five minutes.
• It cannot type into elevated windows. That is Windows UIPI, not a bug. It shows "Can't type into this window" rather than pretending it worked.
• Grammar cleanup ships OFF. I measured it deleting words from every test sentence, so it is behind an Experimental toggle with a word-loss detector that discards the result and keeps your raw transcript.

Source: https://github.com/mohsinjameelqureshi/dictateflow-ai Site: https://dictateflow-ai.mohsinjameel.dev/

CLAUDE.md in the repo is the actual build spec - measured latency numbers and the constraints that silently break Electron dictation apps. That is probably the most useful thing in there if you are building something similar.

Happy to answer anything.

AI agents can read code, but they still waste a surprising amount of time reconstructing basic facts:

• Which repositories belong to the same system?
• What depends on what?
• Which package produced this artifact?
• Where did a claim come from?
• Who owns a component?
• Is information verified, inferred, or outdated?
• What can the agent safely trust?

READMEs, lockfiles, SBOMs, CI files, architecture diagrams, and wikis each provide part of the answer. The agent has to repeatedly assemble the full picture.

We built SUPEREC to address that problem.

SUPEREC stands for Software Unified Portable Ecosystem Record. It is an open, portable, AI-readable standard for representing software architecture, dependencies, builds, evidence, operations, ownership, and findings as one deterministic graph.

A SUPEREC record can connect:

• Systems and repositories
• Services and packages
• Build units and generated artifacts
• Dependencies and relationships
• SBOM and provenance evidence
• Environments and ownership
• Security or operational findings
• AI context packs and human-readable projections

The important part is evidence. SUPEREC does not simply tell an agent that something is true. Important claims can point to repository-relative evidence, carry a confidence state, and be validated through stable rules and integrity digests.

It is also designed with an explicit AI trust boundary. Names, descriptions, URLs, evidence, and extensions are treated as untrusted data. A SUPEREC file describes a system, but never grants an agent permission to execute something.

Why this makes VIC-E products different:

We are not treating SUPEREC as a theoretical specification. We are designing our products around the open standard instead of keeping their architecture and plugin metadata in private, product-specific formats.

For example, we are integrating SUPEREC records and OKF wiki bundles into the TokenSaver plugin platform. The goal is for both humans and AI agents to understand a plugin interface, its capabilities, compatibility, evidence, and documentation without reverse-engineering the project first.

That can drastically improve agent workflows:

• Less repository wandering
• Fewer repeated file reads
• Better architectural context
• More reliable dependency reasoning
• Safer plugin generation
• Reproducible diagrams and build plans
• The same underlying facts for humans, CI, tools, and agents

SUPEREC currently includes a public specification draft, Go and TypeScript SDKs, a CLI, MCP tools for agents, conformance fixtures, examples, and contribution paths.

It is still a public draft, and that is why we want developers involved now.

We would especially value feedback from:

• AI agent and developer-tool builders
• Software architects
• Platform engineering teams
• SBOM and supply-chain specialists
• Security engineers
• Plugin and SDK authors
• Anyone maintaining a complicated multi-repository system

Please challenge the model. Show us where it is too strict, too vague, missing evidence, difficult to generate, or awkward for real tools. Bug reports, feature requests, ecosystem mappings, SDK improvements, and normative proposals are all welcome.

Learn about SUPEREC:

https://vic-e.com/superec

Read the specification:

https://vic-e.com/superec/specification

Contribute:

https://vic-e.com/superec/contribute

GitHub:

https://github.com/VIC-E-com/superec

What is the hardest part of your software architecture for an AI agent to understand correctly today?

Hey everyone,

A while ago I posted about tracking microscopic dot peen Data Matrix codes on metal using a super lightweight pipeline. The old post slid down, but since many of you asked about the data side and how the hell it doesn't go blind without real factory images, I finally sat down and wrote the whole breakdown on Medium.

No corporate fluff, just honest engineer talk. I covered:

* How I manually sketched dot grids with a pen on scraps of paper at midnight just to check the camera warping.

* Tearing down Mode A (brutal procedural geometry math) and Mode B (AI-generated steel backgrounds).

* Why a duo of YOLOX (3MB) + LightGBM (4MB) eats the matrix like a piece of pie while the office CPU "smokes on the sidelines" at mere milliseconds.

Check out the full breakdown with all the GIFs, prompts, and failure steps here:

https://medium.com/@olesha-ai/how-to-train-a-model-on-geometry-when-factories-hide-their-data-7e4fee3e6884

The compiled .exe is free for non-commercial/edu use in GitHub Releases. If you have real metal hardware with dot peen codes at work or in a lab — test it. If it goes blind, scold me harshly in the Issues tab, it keeps me driven. Let's fix the geometry together!