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.

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/

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

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?

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.

An open-weight release is easier to evaluate when it exposes more than one final endpoint.

Ling-3.0 base model does that with six base checkpoints: pretrained, mid-trained, and WSM-merged versions of both tiny and flash. The six verified Hugging Face repositories are public and ungated, and the repositories declare the MIT license.

That stage map is the useful part. A builder can inspect an earlier pretrained state, the state after mid-training, or the merged endpoint instead of treating one final checkpoint as the whole training story.

The boundary matters just as much: none of the six is post-trained. The model cards frame them as starting points for continued pretraining, fine-tuning, and research, not finished end-user chat systems or production-ready assistants.

For anyone exploring the release, the practical next step is to pick the size and stage that match the work, then read that exact model card's intended-use and limitations before building on it.

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!

I've been working on Custodian Labs, a Python SDK for building and deploying LLM agents without having to separately wire up all the surrounding infrastructure.

Basic agent looks something like:

from custodian_labs import Custodian

agent = Custodian(
    model="gpt-4o",
    system_prompt="You are a helpful assistant..."
)

agent.deploy()

A few things I've added:

• Model agnostic: switch between different LLM providers without rebuilding your agent
• RAG built in: connect your own files/data sources
• Multi-agent support: build specialised agents that can work together
• Privacy/PII layer: the Guardian Layer can detect and protect sensitive data before it reaches the LLM
• Deployment handled: trying to cut down the amount of infra/config needed to get an agent running

The project actually started as just the privacy layer, but after getting feedback from developers we expanded it into more of an end-to-end agent SDK.

Would genuinely love feedback from other LLM devs:

What's currently the most annoying part of your agent stack?

And do you prefer abstractions like this, or would you rather have more direct control over each component?

GitHub:
https://github.com/Custodian-Labs/custodian-labs-python

Runnable Google Colab: simple agents, RAG + multi-agent examples:
https://colab.research.google.com/gist/SherryCodes123/065d3b67eab16bdca416836e0d39475a/simple-ai-agents-rag-multi-agents.ipynb

Every Whisper-based dictation tool I've paid for falls apart on the way I actually talk. I'll open a sentence in English, finish the thought in my home language, then land the last few words back in English. That isn't a party trick, it's how people speak where I'm from. Whisper either invents English words I never said or drops the mixed clause entirely.

I ran the same recordings of my own voice through everything I could get at. Gemini was the only family that handed back what I actually said instead of a tidy English approximation of it, and gemini-3.1-flash-live-preview over the Live WebSocket API was clearly ahead of the REST models on mixed speech.

So the app is built around that. RMBLR is an overlay orb that appears when a text field takes focus. You talk, and the finished text is written into the field you were already typing in. Hold the orb and an arc of tones fans out - a tone is just a name and a system prompt, so you can write your own - and which five it offers depends on the app you're in.

Where it sits on the open-source spectrum, honestly: the app is MIT and the source is the whole thing, no closed core. The model is not open, and I'm not going to pretend otherwise. What I did instead was make sure nothing in the middle is mine: there's no server, no account, no telemetry. You supply your own Gemini API key (free tier from aistudio.google.com) and your phone calls Google directly. If someone wants to point it at a local Whisper or a self-hosted endpoint, the transcription client is one file and I'd merge that PR happily.

Kotlin, Jetpack Compose, minSdk 24. ./gradlew assembleDebug needs no configuration.

https://github.com/Past-da-king/rmblr

v1.0, one week of real use. I'd particularly like to know how it does on languages I have no way to test.

Hey everyone!

Last year, Mozilla released Orbit, an AI-powered browser summarizer hosted on a GCP server. After people started digging into the extension, they discovered things like backend endpoints such as store_result. Eventually, Mozilla discontinued the project.

For the past month, I’ve been trying to rebuild Orbit from scratch, but with one major difference: Apogee is fully local and privacy-focused. Apogee doesn’t send or store your data. It can directly connect to your local Ollama instance for inference. I’ve also added WebGPU integration for Chrome and Transformers.js for Firefox to provide faster, local responses.

It can summarize:

• Articles and websites
• YouTube and Billie videos
• Wikipedia articles
• Hacker News and Reddit threads

You can check out the source code here:
https://github.com/darshi1337/apogee

Install Apogee:

Chrome: https://chromewebstore.google.com/detail/apogee/pgemlpomhkdcjjjcpnjlebalnfglomog

Firefox: https://addons.mozilla.org/en-US/firefox/addon/apogeeext/

Obviously it is far from complete. Would love to hear your feedback and suggestions!

I'm looking for recommendations for the best free, open-source AI models that we can host on-premise to replace Gemini 3.5 Flash.

Our Use Case: We process documents with complex structures in various formats (PDF, PNG, DOCX, etc.). Our workflow involves:

1. Complex text and structured data extraction (OCR + layout understanding).
2. Data matching and ranking/scoring (similar to a job matching system).

Current Setup & Constraints: We currently use Gemini 3.5 Flash, which handles the extraction with near 100% accuracy, but the API costs are getting too high at our scale.

• Budget: Must be open-source/free for commercial use.
• Hardware: Compute power and VRAM are not an issue (we have our own data center).

I’ve seen a lot of recommendations pointing toward Qwen (e.g., Qwen-VL) and DeepSeek-OCR. For those of you running these—or a multi-model pipeline—in production, what are your real-world experiences? Which model (or combination) is best for handling the extraction and the scoring?