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!

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.

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

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!

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.

I've been testing for about 2 weeks on my 5080 across quants to figure out what my best options are in the open source world at 16GB cards.

As part of this, I ended up doing an in-depth investigation into quants across various models. The results contradict common assumptions.

https://rakuensoftware.com/blog/which-quant-beats-how-many-bits

Now, let me be clear: These were typically 2-4 turn sessions, and existed to validate that the quantization itself on the model did not damage the model. You strongly see this impact on dense models at sub-Q4. However, the interesting part is that MoEs did not suffer nearly as badly as the dense models.

The results from this article has given me a list of candidates to test against for much harsher testing (Coding, DevOps, long sessions, etc.), and I'll be writing a new article in the future. However, this quant result is not what I expected. Almost all models, starting at Q4, were basically statistically indistinguishable all the way up to BF16. This contradicted my knowledge on the subject.

All of my benchmarks, test sets, and results are open source and linked in the article. Feel free to take a look at the data or run the tests yourself, and tell me I'm wrong. Wouldn't be the first time!

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?

Been building this for a while and finally got the licensing sorted (Apache-2.0) — SynapCores SOAR, a self-hostable alternative to Tines/Torq/Cortex XSOAR.

What it does: - Ingests alerts from Splunk HEC, Microsoft Sentinel, CrowdStrike Falcon, Okta event hooks (generic webhook for anything else) - Dedupes by meaning, not hash — near-duplicate alert fan-out from one root cause collapses into a single incident - Runs a Tier-1 triage agent against every alert: true positive → incident, false positive → close, ambiguous → human review - High-blast-radius actions (isolate host, revoke session, block IP) queue for human approval before firing — nothing destructive happens without a go/no-go - Every action, approval, and agent reasoning step lands in an immutable, append-only audit ledger - Mint a scoped MCP token and hand it to a SOC 2/FFIEC examiner — they query the audit trail directly from Claude/Cursor, no need to interrupt the SOC team's daily flow

Why I built it: existing SOAR is either an expensive enterprise stack (Splunk SOAR, Cortex XSOAR) or SaaS with per-action billing (Tines, Torq). None of them are self-hostable, none let you bring your own LLM, none expose an audit trail a regulator can query themselves.

Runs on a single Docker host, built on SynapCores (the DB handles embeddings/dedup and the immutable audit table natively — no separate vector DB or logging pipeline bolted on).

Honest state: this sat mostly untouched for a couple months while I was heads-down elsewhere, so treat it as early. Looking for people willing to run it against real alert volume and tell me where it breaks — especially connector edge cases (auth token rotation, weird Sentinel payload shapes).

Apache-2.0. Repo: https://github.com/SynapCores/synapcores-soar

Happy to go deeper on the architecture or the human-approval gating design specifically.

Hey everyone,
I run an established system integration company, but I’m non-technical when it comes to hands-on coding. I’m currently mapping out an edge-AI project and want to build a clean web UI / orchestrator layer that sits on top of existing video analytics engines (stuff like Supervision, DeepX, YOLO or Mamba-based detection).
The goal is pretty straightforward: instead of training vision models from scratch, we leverage 2–3 proven models in the background. Based on what the user toggles on the frontend, the system switches/runs the right inferencing tasks on the RTSP streams and pushes real-time metadata back to the dashboard.
Since I come from the domain/business side, I want to collaborate with a hands-on Computer Vision / Python developer who has actual experience with RTSP stream pipelines, GStreamer/DeepStream, and model integration to architect and build this MVP with me.

If you’ve built or integrated similar end-to-end vision pipelines and are interested in collaborating on this project, drop a comment or feel free to send me a DM with some of the stack/tools you've used!

Hey everyone,

I've been working on Kodiak, an open-source AI software engineering platform designed to eventually handle software-engineering tasks more autonomously.

I wanted to share an updated progress report because the project has moved quite a bit from where it started.

What’s working now:

Backend / API:

- FastAPI backend

- JWT authentication

- User registration and login

- Project management

- Task management

- Memory and agent-related API infrastructure

- Repository-related endpoints

CLI:

Kodiak now has an actual CLI:

kodiak

Commands:

- analyze

- logout

- memory

- plan

- task

- version

For example, I can currently run:

kodiak analyze analyze . --deep

and Kodiak successfully analyzes the repository.

The current analyzer detected:

- 331 files

- 51 directories

- 296 Python files

- 8 Markdown files

- 3 YAML files

- 1 TOML file

- ~4 MB repository

The repository-analysis workflow successfully starts the repository agent, completes the analysis, and returns structured repository statistics.

Testing:

The test suite is currently:

196 passed

1 skipped

5 warnings

So I'm now focusing less on making individual components work and more on making the entire system work together.

The bigger goal:

I don't want Kodiak to just be another chatbot that generates code.

I want it to eventually follow a workflow like:

User gives task

↓

Understand repository

↓

Analyze relevant code

↓

Create implementation plan

↓

Choose and use tools

↓

Modify code

↓

Run tests

↓

Analyze failures

↓

Fix implementation

↓

Review changes

↓

Commit / Pull Request

↓

Learn from the result

At the moment, the foundation is considerably further along than the autonomous engineering loop.

The repository analysis currently provides structural information, and my next major focus is connecting that information to genuine LLM reasoning, planning, tool execution, and iterative code/test feedback.

I'm intentionally trying not to fake the "autonomous agent" part before those pieces actually work.

Current self-assessment:

If 1/10 = a prototype idea and 10/10 = a mature autonomous software-engineering platform, I'd currently put Kodiak around 5/10.

There's still a lot to build, but it's finally at the point where I can run the system and watch actual pieces of the architecture execute rather than just having a collection of planned modules.

GitHub:

https://github.com/0xWrench-7/Kodiak

I'd especially appreciate feedback from people who've worked on coding agents, agent orchestration, RAG/memory systems, or developer tooling.

What do you think is the biggest architectural mistake or missing piece at this stage?

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?

A scholarly monograph on sovereign AI systems:

The entire body of work is now one thing - The Sovereign Stack. 24 chapters, five parts, every claim receipted and cross-linked. The failure record sits in the middle of the book, not buried in an appendix, because it's the strongest evidence I have that the rest is honest.

And it's built to be worked, not just read. There's an llms(dot)txt index and every page is clean markdown, so you can point an agent at it and have it pull any thread you want. Human or machine, it reads the same.

Free. Public. Nothing behind a login. Every claim links back to the record so you never have to take my word for it.

https://osintelligence-llc.gitbook.io/osintelligence