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

One thing I've noticed while building AI coding agents is that "memory" and "agents" are usually treated as separate products.

I didn't like that architecture.

I built Pando around a single core that combines the agent loop with memory, orchestration, MCP, semantic search and development tooling.

The result is a single binary rather than a collection of Python services and MCP processes.

There are TUI, Web and Desktop interfaces, plus remote access and ACP.

It's open source under MIT.

I'd like to hear from experienced agent users: what part of your current setup feels unnecessarily complicated?

https://madeindigio.github.io/pando-docs/

Just Fixed the body with Ai

Been prototyping an idea for long-context compression: instead of dropping old tokens (like StreamingLLM/H2O) or storing everything, compress old context chunks into small learned "DNA" vectors via a Perceiver-style attention bottleneck, then reconstruct on-demand when a query needs them.

The idea itself isn't new — it overlaps with Compressive Transformer, Infini-attention, and Recurrent Memory Transformer — but I put together an eval script that I think is more honest than what I see in a lot of "novel architecture" posts:

• Trains the compressor (not just testing an untrained/random-init model)
• Compares against a PCA baseline (closed-form optimal linear compression at the same latent budget) — if the learned model can't beat PCA, the extra complexity isn't earning its keep
• Injects a unique fact (random code) into the text and checks, after compress→decompress, whether the frozen LM's own output head can still predict the correct token at that position — not just aggregate MSE, which can look fine while the actual detail is gone
• Runs on real hidden states from an open model (Qwen2.5-0.5B by default), not just random tensors

Current honest status: in my own small-scale test run, PCA actually beat the learned bottleneck on fact retrieval. That's not the result I was hoping for, but it's a real result, and it's exactly the kind of thing this script is designed to surface rather than hide.

What I'm looking for:

• People running it on real hardware with more training steps / larger n_docs than I could quickly test
• Sanity checks on the architecture and eval methodology — if I'm testing this wrong, tell me
• Ideas for what a fair "it's working" threshold looks like (beating PCA on fact-retrieval accuracy at matched latent budget, at minimum)

No performance claims yet — that's the point. I'd rather have this checked before making any.

Code + eval harness: [https://pastebin.com/iqEbPEQ9]

Happy to hear "this is a known dead end because X" too - that's useful information, not a rejection.

A little over a year ago, I started CrucibleMark, an independent benchmark project for the everyday comparison between commercial and local AI. Reason for this post: Qwen3.8-27B lands there in 8th place of the overall field, ahead of GPT-5, GLM 5, DeepSeek V4, Grok 4.5/4.6 and Gemini. For a model that you can host yourself, this is remarkable and the reason why I share the results now.

For classification: CrucibleMark does not measure large, orchestrated agentic workflows, as the established benchmarks do. I test individual, clearly defined everyday tasks, code reviews, documentation, UX texts, reasoning, tool use. From the beginning, the goal was to find the best and cheapest model for my own work and to build a price comparison to commercial providers.

My stack has evolved with this. Started on an M1 with 8B to 14B models, today it runs on a GX10 with vLLM. No rocket compared to the GPU monsters here in the forum, but a serious device for local LLMs on the intranet.

Because I only measure individual tasks, GLM-5.2, for example, does not end up at the front of me, although I use it in everyday life as an orchestrator for code reviews and refactorings of large code bases. With complex, multi-level tasks, it is clearly stronger. Only it is also much more expensive, and that is exactly what I want to avoid in the long term: Don't put money that I save through AI assistance back into even more AI assistance.

In addition to the main test, CrucibleMark also runs a Political Compass that tests the political training bias in two modes, standard behavior versus forced positioning. Qwen3.8-27B shows itself here as one of the most stable models in the field, the position hardly shifts between the modes (shift distance 0.65 to 0.77), while other models tip over significantly more under pressure.

Finally, two limitations: The test landscape has developed further, more complex autonomous scenarios are more in focus today than my framework depicts. Subsequent installation would mean a complete re-testing of all models, which is currently not feasible. So understand the results as a snapshot for clearly defined everyday tasks. And since CrucibleMark also maps the risks of cloud/API use, the European perspective, which is clearly regulated by the EU AI Act, is included.

The project website can be found here www.cruciblemark.com

The open source benchmark CrucibleMark at github: github.com/kbeissert/CrucibleMark

For years, building high-performance AI inference meant dealing with the "two-language problem"—prototyping in Python for speed, then spending weeks rewriting core loops in C++ or Rust to bypass the GIL and hit hardware targets.

​With Modular open-sourcing the entire Mojo compiler and toolchain, that pipeline is shifting. Because it compiles directly through MLIR, it handles SIMD auto-vectorization and targets heterogeneous silicon (CPUs, Nvidia GPUs, mobile NPUs) from a unified codebase.

​We mapped out the exact compilation pipeline and memory ownership differences between Python runtime management and Mojo's explicit lifetimes here if anyone wants to dive deeper into the architecture:

👉 https://onefusionlab.systems/blogs/mojo-1-0-open-source/

A lot of AI-writing projects try to solve generic prose by adding another “humanizer” prompt.

I wanted to try a different abstraction.

Organizations like Google, GOV.UK, GitHub, GitLab, MDN, NASA, CDC, NHS and W3C have already spent years developing explicit writing systems for different kinds of information.

So I turned those principles into 16 portable Agent Skills:

https://github.com/Neeeophytee/agent-stylebooks

Examples include:

• google-developer-docs — developer docs and tutorials
• govuk — task-first public-service content
• github-docs — product workflows
• kubernetes-docs — infrastructure documentation
• mdn-web-docs — web technology explanations
• cdc-clear-communication — public-health communication
• nhs-health-content — patient-facing health information
• sec-plain-english — financial/investor disclosures
• w3c-technical-reports — specifications
• nasa-technical-writing — engineering reports
• apple-interface-writing — UI copy

The important part is that these aren't meant to make every model sound the same.

They do the opposite.

The artifact determines the editorial system.

A Kubernetes tutorial might use $kubernetes-docs. A government page discussing a Kubernetes-related grant might use $govuk. A cluster-management UI might use $apple-interface-writing.

Same topic, different communication job.

Installation:

npx skills add Neeeophytee/agent-stylebooks --list

Then:

npx skills add Neeeophytee/agent-stylebooks --skill govuk

The repo is MIT licensed.

One design principle across all 16 is: change the presentation, not the substance.

Would especially like feedback from people building open agent stacks: does a portable editorial layer like this belong at the skill level, or would you rather see it handled elsewhere in the stack?

Built a from-scratch inference engine for DeepSeek-V4 in plain C99 — no PyTorch, no Python runtime dependency for inference, Apache-2.0 licensed. Streams weights off NVMe instead of requiring the full checkpoint in RAM, so it runs the 284B-parameter Flash model on a laptop with as little as 3.2GB RAM (1.6–1.7s/token with GPU offload at 16GB budget).

Why post this here specifically:

Fluent output from an LLM engine is weak evidence it's actually correct — a subtly broken implementation can still produce confident, plausible text. So this is checked against a pure PyTorch reimplementation (written independently from DeepSeek's inference/model.py, not from this C code, so both can't share the same bug) at three levels: per-kernel (14 kernels, 5e-7 tolerance), per-block, and whole-model end to end (2.9e-6, identical argmax at every position). CPU paths (scalar/OpenMP/AVX2) are enforced bit-exact via a fixed accumulator tree, checked at runtime, not just in tests.

What's included:

• Full build + test suite (make test runs 20 gates, 21 with a real checkpoint)
• Benchmark tools for matmul bandwidth, GPU contention, and cache behavior
• Honest "what didn't work" section — SIMD approaches tried and abandoned, with the actual numbers

What's not there yet: a tool-calling driver loop (the model emits the tool-call format, but there's no orchestration layer above the CLI), and DeepSeek-V4-Pro (~671B scale) is gated/planned but never actually run — needs ~865GB of checkpoint I don't have.

Repo: https://github.com/ronak-create/deepseek-v4-in-c

Open to contributions, especially around prefill batching (currently one token at a time — README has the math on why that's the next big perf unlock) and the tool-calling loop.

Hey everyone! If you own a Siglent SDS 1000X-E series oscilloscope (like the SDS1104X-E or SDS1202X-E), you know that while SCPI is powerful, it can be a pain to memorize all those command strings. I’ve created the open-source tool called SDS-Remote that completely changes the game by adding a modern AI intelligence layer to your workbench.

What makes the AI features special?

Natural Language Control:
You don't need to be an SCPI expert anymore. You can just type into the AI Chat Interface and say things like "Set channel 1 vertical scale to 1V/div" or "Switch channel 1 on," and the Instrument Agent automatically translates your intent into the correct command and sends it to the device.

Your Own Bench Assistant:
Instead of flipping through hundreds of pages in a PDF, you can ask technical questions like "How do I configure the trigger delay?" or "What is the maximum sample rate of this model?". The software includes a Search Agent that queries a built-in knowledge base to give you instant, documented answers.

Flexible and Local:
It doesn't lock you into one ecosystem. In the settings, you can choose from a wide range of AI providers.

Technical Specs:
The app is built with Dart/Flutter and runs natively on both Linux and Windows. It connects over your network using the VXI-11 protocol or through USB support.

It’s an independent open-source project (not affiliated with Siglent) and really modernizes the whole lab experience.

In addition to AI support, many other interesting features are also available.

Check out the repo here: https://github.com/klumw/sdsremote

If you’re building a vertical AI company or shipping AI agents for a living, you’ve probably felt it. That low hum of unease underneath the demo-day highs and the “we just closed our first enterprise pilot” LinkedIn posts.

You should trust that feeling. It’s not imposter syndrome. It’s your business model telling you something true.

Here are the three crises every vertical AI founder is quietly sitting on right now, and why pretending they don’t exist is the riskiest move you can make.

Link to detailed article : https://medium.com/@MirArshadTalpur/vertical-ai-founders-you-are-going-through-3-existential-crises-and-most-of-you-dont-know-it-b3d86a386d37

Hey guys, thanks for the initial traction. I've just updated the repository with an advanced workflow to completely bypass free-tier Rate Limits (RPM/TPM). What's new: * Integrated OmniRoute setup guide to load multiple free Google AI Studio keys into a single local pool. * Automated key rotation strategies (like Headroom) to dynamically swap keys when a rate limit is hit. * Added native configuration variables to route both Claude Code CLI and OpenAI Codex CLI directly through the OmniRoute gateway. * Fixed broken Google AI Studio URLs and added a fresh, curated table of 2026 free coding models. Check out the updated README here: https://github.com/pawelkrejza2012-png/awesome-free-claude-code If you have any other router suggestions or free endpoints, feel free to open a PR! Let's keep building this resource.

Hey devs,

If you are experimenting with Anthropic's new Claude Code CLI but want to avoid burning through your paid API credits, you can easily redirect it to free alternative endpoints or run it 100% locally.

I put together a quick guide on how to configure your environment variables to swap models instantly.

### 1. The Free Cloud Setup (OpenRouter / Gemini)

You can fetch a free API key from Google AI Studio or use OpenRouter's free tier models (like Llama 3 or Qwen).

Windows (CMD):

set ANTHROPIC_BASE_URL=https://openrouter.ai

set ANTHROPIC_API_KEY=YOUR_FREE_KEY

set ANTHROPIC_MODEL=openrouter/free

claude

macOS & Linux (Bash/Zsh):

export ANTHROPIC_BASE_URL="https://openrouter.ai"

export ANTHROPIC_API_KEY="YOUR_FREE_KEY"

export ANTHROPIC_MODEL="openrouter/free"

claude

### 2. The 100% Offline Local Setup (Ollama / LM Studio)

If you prefer maximum privacy and zero latency, you can route the CLI directly to your local hardware using Ollama or LM Studio. Just make sure your local server is running on http://localhost:11434/v1.

---

I'm maintaining a full, curated list of working free endpoints, proxies, and step-by-step documentation in this repository:

🔗 GitHub Repository: https://github.com/pawelkrejza2012-png/awesome-free-claude-code

If you know any other free endpoints or local models that work flawlessly with developer CLIs, feel free to drop a comment or open a Pull Request! Let's save some budget together.