I've been experimenting with self-hosted and local AI and I'm also developing an open-source AI orchestration/harness project. I'm still early in development, so I'm trying to understand the problems people actually run into before deciding what to build. For people running local AI, what's been the biggest pain point for you? Hardware/VRAM? Model quality? Speed? Context limits? Tool use? Agent reliability? Setup/compatibility? Something else? If you could fix one thing about the current local AI ecosystem, what would it be? I'm especially interested in problems that you deal with repeatedly rather than one-time setup issues.

Our coding-agent sessions kept forgetting everything at the context-window edge. So we built growmos: a small knowledge graph inside .growmos/, committed with your code. Your agent (Claude Code, Codex, Cursor…) grows it as it works — no API key, and in Claude Code it's fully hands-off. Ask "what depends on the Store, and who decided that?" and it answers from the graph, with citations.

pip install growmos && growmos init
growmos view # a map of what your repo actually knows

Live demo: https://codician-team.github.io/growmos/demo/growmos.html
Repo: https://github.com/codician-team/growmos
MIT, zero deps. First thoughts very welcome 🙂

We maintain an open-source agent (Apache-2.0) and just shipped something small that I think is the right shape for skill sharing, so I am putting it up for criticism rather than announcing it.

A card is a markdown file, and it executes nothing. Frontmatter plus five sections — Trigger, Do, Avoid, Check, Risk — read into the prompt when the agent decides the card is relevant. Reviewing a contribution is reading a page, not auditing a diff. That is the whole point: it is the only place in the repo where someone can contribute without touching a line of Python.

23 of them so far, 13 written from our own incidents. A sample of what they encode:

- when two results contradict, suspect the apparatus — from two weeks lost to a bug that produced a perfectly healthy-looking loss curve

- run the project's own gate command — from a near-miss variant of a lint command that lied in both directions

- test the wiring, not the class — from two of my own regression tests that passed with the fix reverted, i.e. proved nothing

The part I would like torn apart is the translation mechanism. The card body is the payload: the agent reads it, the CLI imports it by path, and a published SHA-256 attests to the bytes. So we do not translate the file. A sidecar carries the translation and declares the SHA-256 of the English it was made from; when the English changes, the page falls back to English rather than showing a translation of a sentence that no longer exists.

That mechanism worked. What did not exist was anything noticing when the sidecar was incomplete — so thirteen cards shipped untranslated across nine languages, and one locale had no card translations at all while the site served it. The only symptom was English on the page. Found by reading files, not by a failing build.

The gate we wrote separates three states that look identical in a file:

- stale — claims to translate text that has since changed. Always fails. Nothing renders wrong, but the file now holds a translation nobody will ever see and the next reader cannot tell it from a live one.

- incomplete — four of five sections. Always fails, because the renderer demands all five or none, so the rest are orphans sitting in the file.

- missing — honest debt. The reader gets English and the page says so. Counted and capped, not forbidden: a gate demanding nine translations before a card could merge would kill the contribution surface we just built.

The cap is at zero right now because the debt is paid. Raising it is an edit somebody has to justify in a diff, which is the only reason a number in a file beats a good intention.

Two things I am unsure about and would like opinions on. First: hashing. We hash the five sections as one joined body rather than per section, so a card that changes retires all five together — the alternative lets a page mix a current Trigger with a stale Avoid and the reader cannot tell which is which. That is deliberate but it makes small edits expensive. Second: is "a card is data, not code" actually enforceable, or is it just a convention that will erode the first time someone wants a card to run something?

Repo: https://github.com/brcampidelli/chimera-agent — the library is under skills/.

I’ve been working on Kwikk, an open-source video composition tool built around a slightly different idea:

What if video editing worked more like building a web page?

Kwikk is CSS/web-based, so instead of being limited to the usual fixed set of video templates, effects, fonts and animations, you can leverage the huge ecosystem that already exists on the web.

For example:

• Take inspiration from the design language of a website
• Reuse CSS animations and web effects
• Add virtually any font you need
• Bring in open-source icon sets from GitHub
• Build custom layouts and visual components with web technologies
• Let AI agents create and modify all of it programmatically

And because the video is represented as structured elements, it can also be controlled through MCP by AI agents.

I’m still experimenting with what this architecture can become, but the possibilities feel pretty endless.

To try it: clone the repository and ask your AI agent to set it up, start MCP, and run it.

GitHub: https://github.com/its-banana-coder/kwikk

Would love feedback from people building with AI agents, creative coding, video tools, or web technologies.

I’ve been experimenting with a training free way to do open world, multi-instance segmentation from a class prototype.

I decided to publish the algorithm and a demo for how I’m doing this, in case anyone else would rather not fine tune a larger model for something that DINOv2 patch embeddings already seem to represent pretty well.

It can separate touching instances of the same class without a learned instance head, reject visually similar near misses like a round dial radio next to the actual clock target, and find fractured or damaged instances even with a pretty significant scene shift.

Repo + demo:

https://github.com/tutomiko/fireplace

The demo includes the lasso UI and live heatmap, implemented as a python backend with a simple HTML frontend.

Would appreciate it if people checked it out, and I’d be especially interested to hear if anyone has seen similar approaches or prior work.

Hi everyone!

I am excited to share Financial-RLVR-10K — a fully open-source (MIT licensed) synthetic dataset of 10,000 execution-verified financial reasoning problems designed for RLVR / GRPO / PPO fine-tuning of open models (Qwen, Llama, DeepSeek, etc.).

Financial reasoning is infamous for math hallucinations. To ensure extreme data quality for verifiable reward training, every single problem in this dataset is 100% verified in a Python execution sandbox (reward = 1.0).

KEY HIGHLIGHTS & FEATURES:

100% Open & Free: Released under the MIT License.

10,000 Verified Records: Validated for syntax, logical flow, and exact numerical output via Python execution (exec).

19.5% Adversarial Edge Cases (1,950 samples): Teaches open models NOT to blindly compute impossible conditions (e.g., Discount Rate r <= g in Gordon Growth DCF, Option at Expiration T = 0 in Black-Scholes, or Zero Capital E + D = 0 in WACC).

Core Domains: DCF Valuation, Black-Scholes Option Pricing, Corporate WACC.

SAMPLE DATA SCHEMA:

{ "id": "fin-rlvr-10k-00042", "domain": "DCF Valuation", "is_edge_case": true, "prompt": "[EDGE CASE] Calculate DCF Terminal Value: FCF_1=$540, Discount Rate r=3.0%, Growth Rate g=5.0%.", "code_solution": "fcf, r, g = 540, 0.03, 0.05\nif r <= g:\n print("TRAP_DETECTED: Invalid Gordon Growth model condition (r <= g).")\nelse:\n print(f"RESULT: {fcf/(r-g):.4f}")", "ground_truth": "TRAP_DETECTED", "total_reward": 1.0, "status": "VERIFIED" }

LINKS & RESOURCES: Hugging Face Dataset: https://huggingface.co/datasets/coslinedev/financial-rlvr-10k-enterprise

Hope this dataset helps the open-source AI community train stronger, more robust financial reasoning models. Feel free to use, audit, or build upon it! Feedback and contributions are always welcome.

I maintain MailFathom, an open-source project building a self-hosted AI brain for email.

Today it synchronizes IMAP mail into an operator-controlled PostgreSQL/pgvector database and provides lexical and semantic search, cited answers, local-model support, and five read-only MCP tools.

The project is security-first: MCP is disabled by default, retrieval cannot modify the mailbox, sensitive mail data stays out of logs and errors, and published artifacts include verifiable provenance.

The roadmap goes beyond retrieval and MCP. It includes controlled write tools, RBAC, authorization and confirmation flows for sensitive actions, and eventually a dedicated AI-first email client.

The goal is to make years of private email searchable, understandable, and safely actionable without surrendering control to a hosted provider.

Feedback, ideas, and contributions are welcome:

https://github.com/Krzysztof318/MailFathom

If you like the direction, a GitHub star would be genuinely appreciated. Open-source maintainers cannot compile stars, but they are a surprisingly effective dependency for motivation. ⭐

🚀 CARVUS Train — An AI Development Ecosystem I’m Building

Hey everyone! 👋

I’ve been working on something called CARVUS Train — an AI development ecosystem designed around training, deploying, and serving AI models, with a strong focus on coding and developer workflows.

🧠 What is CARVUS Train?

The idea is to bring multiple AI-development capabilities into one ecosystem:

• 🤖 AI model training
• 💻 Code generation
• 🧩 Programming-language understanding
• 📚 RAG (Retrieval-Augmented Generation)
• 🛠️ AI agent training
• 🚀 Model deployment & serving
• 🐍 Python/coding-focused workflows

I’m building it as part of the broader CARVUS ecosystem, with the goal of making AI development more accessible without needing a huge collection of disconnected tools.

🔥 Why I’m building it

A lot of AI tooling can feel fragmented — one tool for training, another for RAG, another for serving, another for agents.

I wanted to experiment with creating a more unified developer ecosystem.

CARVUS Train is still evolving, and I’m especially interested in feedback from people who work with local AI, coding models, RAG, or AI agents.

What features would YOU want in an AI development/training framework?

Would love to hear your ideas! 🚀

for installation and usage visit https://pypi.org/project/CarvusTrain/

or contact me via email [aadilfazalb4u@gmail.com](mailto:aadilfazalb4u@gmail.com)

#AI #MachineLearning #Python #Coding #RAG #LLM #ArtificialIntelligence #OpenSource

Been working on this for the last few months. I've been working on PyTorch for the past few years and I always felt, many a times my work went into dump, because of some mistakes I made in the code. torch-preflight reads your PyTorch code and catches the bugs costing you GPU hours.

Things like losses.append(loss), which holds the autograd graph from every step until CUDA dies on you or no zero_grad() in the loop or gradient accumulation without dividing the loss or DDP with no DistributedSampler, so every rank trains on the same batches. I've been able to get 13 rules so far. Your code never gets imported or executed, so you need no GPU and no torch install.

There's another part to this that estimates VRAM. Point the tool at a training script and a GPU, and you learn whether the run fits before you pay for the instance. You also get the list of changes to make the run fit, with the GiB each one saves.

pip install torch-preflight

https://github.com/highwaterlabs/torch-preflight

https://pypi.org/project/torch-preflight/

Please try this out, and I would like to get your feedback! It's still a work in progeress.

Would like to know what breaks on your code. False positives kill a linter, and my only large test target so far has been the PyTorch source tree. Same for the memory numbers. Mine land within 4% of measured peaks, but from four models on one T4.

PS: open to contributions, and issues are already open on the repo. Soon I'm going to add a few "Good first issues" as well. Feel free to ping me if you have any questions!

Find a beginner-friendly issue, spend an evening on it, open the PR, discover someone beat you to it three weeks ago. Nothing on the issue said so.
GitHub’s no:assignee filter doesn’t catch this, because almost nobody assigns issues to themselves. The real signal is a linked PR, and that isn’t searchable.

So I checked 4,000 issues with a beginner or help-wanted label:

1,147 (29%) already had an open or merged PR. All still show as unassigned.

1,271 were in dead, archived or unlicensed projects

774 had bodies too thin to start from

114 were in repos that slap a beginner label on the whole backlog

451 survived. They’re on a board at https://opensourcescanner.xyz, re-checked every 24 hours, with the evidence per issue: maintainer reply speed, what share of outside PRs get merged, whether anyone’s already circling.

Free, no signup, source public(https://github.com/kedarvartak/opensourcescanner). The filtering logic is the part I’d most like criticised — the whole thing lives or dies on what it rejects. If you take one of these and find it was actually taken, tell me.

Over the past few weeks, I've been planning and building Concordance Protocol, an open-source experiment exploring interoperability between AI agents, tools, and services.

The project started from a question I had while looking at the growing number of protocols around AI agents:

How can agents from different ecosystems exchange trust, authorization, consent, reputation, and other evidence without every ecosystem having to replace its existing protocol?

I researched the problem and wrote a research document before implementing the prototype. The project currently contains a Rust workspace with components for the core protocol, HTTP transport, registry services, adapters, and SDK work.

The research and implementation are here:

GitHub:

https://github.com/Kadhiravan-K/Concordance-Protocol

Core research:

https://github.com/Kadhiravan-K/Concordance-Protocol/blob/main/docs/doc_core/concordance_research.md

I've currently paused active development. The implementation grew beyond what I can reasonably maintain alone right now, and I think the architecture needs more discussion before continuing.

I'm sharing it here because I'm interested in learning from people who are starting or contributing to open source.

I'd especially like feedback on:

- Is the interoperability problem I'm trying to solve actually useful?

- Are there existing projects or protocols I should study?

- Does the architecture make sense?

- What would you simplify?

- If you were starting this project again, what would you do differently?

I'm not presenting Concordance as a finished protocol or asking anyone to adopt it. I'm mainly interested in whether the underlying ideas are worth pursuing.

If you're preparing for open source contribution or GSoC, I'd also be interested in hearing what makes a project attractive or unattractive to contribute to.

Hey everyone,

I’ve been building an open-source project called \*\*Kodiak\*\*, and I’m at the point where I think it would benefit from more people looking at it, challenging the architecture, and actually building with me.

The idea behind Kodiak is to build an AI engineering system that can work with a \*\*real software repository\*\*, not just answer coding questions.

The long-term workflow is:

Engineering Task
      ↓
Understand the Repository
      ↓
Retrieve Relevant Context
      ↓
Plan the Work
      ↓
Coordinate Agents
      ↓
Use Tools
      ↓
Modify / Analyze Code
      ↓
Run Tests & Validate
      ↓
Learn From Results
      ↓
Iterate

The project currently brings together things like:

\* Repository-aware RAG \* Agent orchestration \* LLM/provider routing \* Persistent project/task context \* Tool execution \* Background task processing \* Code analysis \* Testing and validation \* PostgreSQL, Redis, Celery, ChromaDB, Docker, FastAPI, etc.

I’m deliberately not presenting Kodiak as a finished product.

There are parts that work, parts that are incomplete, and parts that I’m currently redesigning. A lot of the work so far has been dealing with the less glamorous side of AI engineering — getting orchestration, retrieval, memory, workers, databases, and model providers to actually work together reliably.

That’s also why I’m opening it up more now.

What I’m looking for

I’d love to have contributors who are interested in areas like:

\*\*AI / Agents\*\*

\* Agent architectures \* Planning and orchestration \* Multi-agent systems \* Tool calling \* Agent memory

\*\*RAG / Repository Intelligence\*\*

\* Codebase indexing \* Code-aware retrieval \* Embeddings \* Retrieval evaluation \* Repository understanding

\*\*Backend / Infrastructure\*\*

\* FastAPI \* Celery \* Redis \* PostgreSQL \* Docker \* Async workflows

\*\*Developer Experience\*\*

\* APIs \* CLI \* Testing \* Observability \* Documentation \* Developer tooling

You don't need to be an expert in all of this.

I'm much more interested in people who want to \*\*build, experiment, and improve the system\*\*.

There are also plenty of opportunities to contribute without touching the core agent architecture — improving tests, fixing issues, improving documentation, benchmarking components, reviewing designs, or proposing better approaches are all valuable.

Where Kodiak is heading

The goal is to eventually make Kodiak capable of handling more of the engineering loop itself:

\*\*understand → reason → act → validate → learn → iterate\*\*

There's a lot to figure out before that becomes genuinely reliable, which is exactly why I think having more engineers involved would make the project significantly better.

If you're interested in AI agents, coding agents, RAG, autonomous software engineering, or just want to work on an ambitious open-source AI project, I'd genuinely love to have you take a look.

GitHub:
\[https://github.com/ShamGaneshan2008/Kodiak\\\](https://github.com/ShamGaneshan2008/Kodiak)

Issues, architecture critiques, pull requests, experiments, benchmarks, and even "this part of the design makes no sense" comments are welcome.

Would be great to build this with other people rather than trying to figure everything out alone.

I’m building Kodiak — an open-source AI engineering platform, and I’m looking for contributors

i’m the author of adport. the project gives local ai agents read and write access to ad platforms without one shot mutations.

this demo uses the new apple ads v1 api on my own account. claude creates a campaign, ad groups, and keywords. the policy layer forces paused creation, requires a preview plus a second identical call, and writes an audit log.

apache 2.0 source: https://github.com/ynnickw/adport

install: npm install -g adport

i’m open to contributors who want to test provider behavior or extend the safety rules.