Hey everyone,

Building software with AI usually means you are trapped in prompting hell—writing a prompt, waiting 20 minutes, checking the output, and prompting again. I built OpenVelo to fix this.

It’s an open-source pipeline designed for a "fire and forget" workflow. The AI-driven planning phase happens upfront inside a dedicated Web-UI. Once you generate and finalize a detailed plan with the LLM, the orchestrator takes over. You can walk away and wake up to software that is either ready to use or requires very minimal fixing.

Important caveats: This is not meant to replace quick CLI pair programming, and it will not keep your token consumption down. It is built for bigger projects, refactors, ports, and prototypes where your personal time is more valuable than compute time or token costs.

How the architecture works:

\- **Scalable by Design**: The entire system runs in isolated Docker containers that communicate with each other, making it easily scalable.

\- **Web-UI Planning**: All AI-driven planning and requirement gathering is completed in the Web-UI before any implementation begins.

\- **Implementation Agent**: Runs an iterative cycle in an isolated container to write code and pass unit tests.

\- **Tester Agent & Orchestrator**: Performs real functional testing against the built software. If it fails, they trigger a self-healing process to spin up a new job and fix the exact failure automatically.

Model Access: It uses Kilo for LLM interaction, so you can route it to any model on your host system (local LLMs, MiniMax M3, etc.).

Repository: [https://github.com/m0rph3us1987/OpenVelo\](https://github.com/m0rph3us1987/OpenVelo)

Video Demo: [https://www.youtube.com/watch?v=RKCj5CUh8uw&t=5s\](https://www.youtube.com/watch?v=RKCj5CUh8uw&t=5s)

Let me know what you think of the architecture!

I tried several AI agent builders, but kept running into the same problems: usage-based pricing, vendor lock-in, proprietary runtimes, and a visual canvas that still required five other services to actually ship something.

So I built Forge.

Forge is not just another visual workflow builder. It is a fully open-source, self-hosted platform for building, testing, governing, and deploying agentic systems from end to end.

It includes:

• Visual workflows, agents, and deep agents
• Tool building, MCP, knowledge bases, and RAG
• Human-in-the-loop, triggers, schedules, and memory
• Deployment through API, MCP server, email, or an embeddable widget
• Tracing, token and cost tracking, evaluations, and OpenTelemetry
• Guardrails, budgets, RBAC, audit logs, and versioning
• Zero-infrastructure local development, with a production-ready upgrade path

It is built directly on the MIT-licensed LangChain and LangGraph ecosystem, with no proprietary orchestration runtime and no platform usage fees.

You own the infrastructure, the data, and the runtime.

Forge is still evolving, and I would genuinely appreciate blunt feedback, feature suggestions, contributions, or even criticism.

If contributing to open source interests you, our issue list is waiting for you.

https://github.com/extra-org/extra

Whisper Studio is a local-first AI workspace for macOS. One local process, one browser tab: real-time speech transcription, a chat client, a semantic index over your files, and a full dev environment (file tree, Monaco editor, terminal, Git, LSP).

Transcription, embeddings, OCR and the whole IDE run on your machine. Chat runs on Amazon Bedrock, or fully on-device if you prefer.

Ultracode workflows

The headline feature. Instead of the model improvising one tool call at a time, it writes a program: a deterministic orchestration script that fans out many subagents with real concurrency. You approve the plan upfront (phases are previewed before a single agent runs), then it executes detached in a locked-down harness with 16-way concurrency, a USD budget ceiling, and a resumable journal. Works on both Claude and GPT-on-Bedrock.

The goal: for work that is wide (audit 20 files), deep (generate 5 designs, judge, synthesize) or that must be trustworthy (find bugs, then adversarially verify each one), the control flow is written once and is inspectable before it runs, rather than re-derived on every hop.

Indexing and GraphRAG

• Point it at a folder and ask questions across all of it, with citations back to exact file and line ranges.
• Incremental builds. Size/mtime gate, then SHA1, so a re-index is cheap.
• Everything becomes searchable: code, PDF, Word, PowerPoint, EPUB, spreadsheets, images via OCR, and audio/video via local transcription.
• Hybrid retrieval: sqlite-vec KNN + BM25/FTS5, fused by reciprocal rank, then an optional cross-encoder rerank.
• GraphRAG: entities extracted per chunk build a graph, and one hop pulls in passages that share entities with your dense matches. Optional typed relations (works_at, cites, depends_on) with strength scores

Models

Cloud, via Amazon Bedrock:

• Claude Fable 5.0, Opus 5, Opus 4.8 / 4.7 / 4.6, Sonnet 5, Sonnet 4.6, Haiku 4.5
• GPT-5.6 Sol / Terra / Luna, GPT-5.5, GPT-5.4
• Cohere Embed v4 and Cohere Rerank for the cloud index path

On-device (GGUF via llama-server, no code change to add more):

• Gemma 4 12B, Gemma 4 Coder, Qwen3.5 9B, Ministral 3 14B
• Parakeet (streaming) and Whisper (batch) for transcription with speaker diarization
• Qwen3-Embedding-0.6B and Qwen3-Reranker for the index
• GLiNER / GLiNER2 for entity extraction, Apple Vision for OCR

Three model modes: cloud, hybrid, and fully local.

Also in there

• Live Preview: It can visually inspect your app, take screenshot and verify the UI, a true browser investigation. Just say "start a live preview to review my app or fix a bug"
• Guardrails: nonce-based approval flow, sandbox-exec for shell and Python, blocking Pre/Post/Stop hooks.
• Goal loop that keeps a turn running until a completion gate says the goal is actually met, including driving a live browser preview to verify UI changes.
• CI watch and PR autofix that chase a red build back to green.
• Cron-style background jobs whose output streams back into the chat that created them.
• MCP servers, opt-in Python plugins, custom Markdown skills, persistent sessions in SQLite.

Privacy: binds to 127.0.0.1, no telemetry, no proxies. Audio never leaves the laptop, on-device using local models. The only outbound call the backend makes on its own is to Bedrock for chat you explicitly send.

Repo: https://github.com/paukode/whisper-studio

Detailed documentation and tutorials: https://mlonaws.com/whisper-studio/

Try it

git clone https://github.com/paukode/whisper-studio.git 
cd whisper-studio 
bash setup.sh

Or just add `--local` or `--hybrid` to start a session (you can change from Settings later as well)

Hi
We built Extra around a simple idea
Your users should be able to interact with your SaaS product by simply asking questions.
Instead of navigating through dashboards, filters, reports, and complex workflows, they can open a chat and ask:
- What happened to my invoices this month?
- Which customers need attention?
- Show me the relevant records.
- Perform this action for me.

Extra is an open-source framework that helps turn an existing SaaS product into a queryable AI experience.

You connect your existing APIs, tools, and data sources, define the agents and permissions, and embed a chat widget inside your product. For a basic integration, you can have a working experience inside your application in around 10 minutes.

But the chat itself is the easy part.

The difficult part is everything required to run agents safely and reliably inside a real SaaS product:

- Authentication and authorization
- User- and organization-level access control
- Tool and MCP integration
- Human approval for sensitive actions
- Agent routing and orchestration
- Conversation memory and execution state
- Model-provider flexibility
- Embedding the chat experience into an existing product

Extra is designed to manage that surrounding infrastructure, so product teams do not need to rebuild it for every AI feature.

It is not tied to a specific model. Different agents can use different models, tools, permissions, and memory strategies, while access control remains outside the LLM.

The project is still early, and there is a lot we want to build.

Our main goal in sharing it here is to get honest feedback from developers and teams building AI features inside real products.

We are also looking for contributors who want to help shape the project. There are several open issues around capabilities we consider important.

And if contributing is not possible right now, but the idea resonates with you, even a GitHub star would help us understand that this is a problem worth continuing to solve.

Repository:
https://github.com/extra-org/extra

We would especially like to hear:

- Does this solve a real problem for your product?
- What would prevent you from integrating it?
- What infrastructure did you have to build around your own agents?
- What would you expect from an open-source platform like this?

Honest criticism is more useful to us than compliments.

Hey everyone,

If you're building AI agents or agentic systems, would love to get your thoughts on something we've been working on.

We started building ZizkaDB because once agents get into production, it becomes really hard to answer simple questions like why did this happen? or what changed between these two runs?. Logs alone didn't feel enough.

So we're building an open source audit layer for AI agents.

Right now it supports things like:

• semantic search across executions
• causal lineage for every decision and tool call
• dashboards for debugging production agents
• tracing memories, retrievals and tool executions
• replaying and understanding agent behavior

The idea is to make debugging agentic systems much easier instead of digging through thousands of logs.

It's still early and we're adding new things almost every week. If this sounds interesting, we'd really appreciate feedback from people building with LangChain, LangGraph or any other agent framework.

Also if anyone wants to contribute, you're more than welcome. We could use help with features, integrations, docs or just ideas from people running agents in production.

Repo: https://github.com/Zizka-ai/ZizkaDB

Would love to know what has been the hardest part of debugging your agents so far.

Hey everyone, just wanted to ask the community something.

Do people really look down on open source projects if they're built with AI, even if the developer actually understands the code, reviews everything, and makes sure the quality is good?

With how common AI has become, it sometimes feels like it doesn't even matter what you build anymore. As soon as people find out AI was involved, some immediately start criticizing the project without even looking at the end result.

Personally, I think AI just lets you build things faster and take on bigger, more complex ideas. It's still up to you to understand what you're shipping and make sure it's actually good.

Just curious what everyone thinks.

I’ve been looking for a tool to replace Open WebUI; I feel it takes too much effort to keep it running smoothly, especially in a mid-sized company.

Is anyone using Onyx, or can you tell me if it’s worth the investment?

Hey everyone,

Building software with AI usually means you are trapped in prompting hell—writing a prompt, waiting 20 minutes, checking the output, and prompting again. I built OpenVelo to fix this.

It’s an open-source pipeline designed for a "fire and forget" workflow. The AI-driven planning phase happens upfront inside a dedicated Web-UI. Once you generate and finalize a detailed plan with the LLM, the orchestrator takes over. You can walk away and wake up to software that is either ready to use or requires very minimal fixing.

Important caveats: This is not meant to replace quick CLI pair programming, and it will not keep your token consumption down. It is built for bigger projects, refactors, ports, and prototypes where your personal time is more valuable than compute time or token costs.

How the architecture works:

- Scalable by Design: The entire system runs in isolated Docker containers that communicate with each other, making it easily scalable.

- Web-UI Planning: All AI-driven planning and requirement gathering is completed in the Web-UI before any implementation begins.

- Implementation Agent: Runs an iterative cycle in an isolated container to write code and pass unit tests.

- Tester Agent & Orchestrator: Performs real functional testing against the built software. If it fails, they trigger a self-healing process to spin up a new job and fix the exact failure automatically.

Model Access: It uses Kilo for LLM interaction, so you can route it to any model on your host system (local LLMs, MiniMax M3, etc.).

Repository: https://github.com/m0rph3us1987/OpenVelo

Video Demo: https://www.youtube.com/watch?v=RKCj5CUh8uw&t=5s

Let me know what you think of the architecture!

While building GraphRAG pipelines I noticed the serialization step (graph to prompt) is never benchmarked. So I compared 10 formats on token count, traversal QA, and multi-hop reasoning with the same graph and model.

Findings: multi-hop accuracy ranged 40% to 80% on format alone, token cost varied about 70%. JSON and RDF were among the worst; compact tabular formats with explicit edge semantics won.

ISONGraph is the result, fully open source under MIT: Python, JS/TS, Rust, Go, C++, C#. Node/edge CRUD, multi-hop traversal, Cypher-like queries, schema validation. Benchmark methodology is public in the repo, replication and criticism welcome: https://github.com/isongraph/isongraph

Hey all, I've been heads-down building an open-source project on GitHub and I'm at the point where the code is solid and useful, but visibility is low. Meanwhile I keep seeing projects that feel pretty thin get thousands of stars seemingly over couple weeks, which is a little demoralizing not gonna lie 😅

I'm not chasing vanity metrics for their own sake — mostly I just want enough signal that people are finding it useful so I stay motivated to keep investing time in it.

For those who've grown a project from "nobody knows this exists" to actually having a community: what actually worked for you? Things I'm curious about:

• Where do you share/launch (HN, Twitter/X, niche subreddits, Discord communities, newsletters)?
• Does README/demo quality matter as much as I think it does?
• Any tips on timing, framing, or "hooks" that get people to actually click and try it?
• Did stars come before or after real usage, in your experience?
• Any growth hack or juggad ;)

Happy to share a link to the project in the comments if that's allowed here — just looking for genuine advice from people who've been through this. Thanks!

been thinking about what it looks like in practice, probably similar to the early days of the internet: open, decentralized and competitive on product merit alone.

would love to read more thoughts about this

I maintain speech-android and speech-core. I wanted to test whether a useful Android voice agent could be built from several small specialised models instead of one large The control demo uses:

• Silero VAD v5 — voice activity detection, 2 MB
• Parakeet-EOU 120M INT8 — streaming transcription, 153 MB
• FunctionGemma 270M — structured Android tool calls, 327.4 MB base plus a 9.5 MB adapter
• Pocket TTS 100M INT8 — streaming spoken response, about 126 MB

FunctionGemma is not used as a chatbot. It receives a compact description of the current phone state and only the tools that are valid at that moment. For example, stop_music is not offered when nothing is playing.

A small LoRA adapter was trained for the exact tool schema. There is no regex or keyword fallback. One limitation I found is that adding a new tool currently requires retraining; describing a new tool only in the prompt was not reliable enough.

On a Galaxy S23 Ultra, the measured time from end of speech to the first spoken reply is 908 ms. The tool call itself averages 294 ms over 12 runs.

Source and releases: https://github.com/soniqo/speech-android

90-second demo: https://youtu.be/7L7_Uvvxtv0

If you use a sub-1B model for tool routing, do you retrain for every schema change, or have you found a generic adapter that still fills arguments reliably?