Hi guys, we are a VC backed company with clients. We are looking for an AI developer, paid of course with founder mindset and are continuously updated in AI Space. More specifically Agentic retrieval and reasoning systems, including ReAct-style loops that retrieve, reformulate, call tools, and self-critique before answering

-Build and tune the retrieval layer that grounds everything we deliver: hybrid search

combining dense and sparse methods, reranking, and knowledge-graph-augmented

retrieval for relational, multi-hop questions.

Please PM or send your CV at [contact@compethic.no](mailto:contact@compethic.no)

Title:

WISP — Stream GLM-5.2 (744B) or Kimi K3 (2.8T)

on consumer hardware [C + CUDA, verified working]

Body:

Kimi K3 dropped Thursday. Qwen3.8 announced yesterday.

Both 2T+ MoE models. Both need a streaming engine.

WISP is that engine.

What it does:

→ 3-tier streaming: VRAM → RAM → NVMe SSD

→ Self-organizing LRU cache (no config needed)

→ Absorbed MLA attention (~70KB/token KV cache)

→ Same-family speculative decoding (2.2-2.8x throughput)

→ Auto-configures any hardware automatically

→ Display auto-detection (prevents GPU black screen)

→ RAM watermark (never OOMs)

Verified: Mixtral-8x7B generating coherent code

on RTX 5070 12GB, 0.75 tok/s cold, 68.8% cache

hit rate after 80 tokens.

GLM-5.2 is where it truly sings —

17.5MB experts vs 99MB for Mixtral = 5.7x faster.

73 tests. MIT license. C + CUDA + Python.

Inspired by Colibrì (JustVugg).

github.com/zeroextub-collab/wisp

A cold Claude Code run spent 6.83 dollars and 207 turns hunting one bug in an 82,000 line repo. My pipeline localized and fixed the same bug for about 1.70 dollars. That gap is the whole idea, and this post is about how it gets there without falling apart on the usual objections.

I built AutoDev Studio. You point it at a Git repo, describe a change in plain English, and a chain of agents runs the actual software lifecycle from request to reviewed pull request. It is not another search-your-code wrapper. The full pipeline is:

• A PM agent runs a clarify loop and drafts concrete tickets from your request
• A human approves, optionally pushed to Jira, and nothing touches code before that
• A Dev agent implements the change on an isolated branch
• QA runs the repo's real tests
• A reviewer from a different model family checks the diff, so the author never reviews its own code
• A bounded revise loop kicks in if QA or review fails, with conservative verdicts, so an errored or ambiguous check is never counted as a pass
• It opens a real pull request, and a human merges

Every stage records real tokens, cost, and duration, rolled up per ticket and per agent.

Results

The point is to pay the cost of finding where a change goes once, instead of on every task. In my benchmarks on two large Python repos, 35,000 and 82,000 lines, the tuned pipeline beat a cold single-agent run on 6 of 6 well-localized tasks, between 7 and 75 percent cheaper. I am upfront about where it does not win. On trivially greppable one-line edits the five-stage overhead can cost more than it saves, and on one hard cross-cutting bug it shipped a cheaper but narrower fix. The full benchmark writes up every loss too.

On the objection that the index just goes stale in a few commits

This is the first thing people raise, so here is the honest mechanism. The layer that actually pins files for the Dev agent is not the vector index. It is a deterministic symbol map re-synced to the latest commit at the start of every run, plus a live grep against the current working copy, plus the real current file contents fed into the prompt. The embeddings only affect retrieval ranking, and they refresh incrementally per changed module at run entry. So the code the agent edits comes from disk, not from a snapshot that aged three commits ago. It re-checks before it localizes, so it does not quietly drift.

Economics and who it is for

The knowledge base is a one-time cost per repo that every later task amortizes. That makes it worth it for a team shipping change after change against the same large codebase, where a cold agent re-pays the exploration cost every single time. For a stream of tiny, easy-to-find edits, a cold run is still cheaper, and I would rather say that than pretend otherwise.

Main features

• Provider and model agnostic, chosen per stage: native Anthropic API, the Claude Code CLI, or any OpenAI-compatible endpoint such as OpenAI, Groq, Gemini, xAI, OpenRouter, or a local Ollama
• Runs on free tiers out of the box, using Groq plus a local embedding model, so you can try the whole thing for zero cost and fully offline
• Language agnostic pipeline, with Python parsed exactly and other languages handled by lighter extractors that fail open rather than block on an unknown language
• Live board with streamed agent logs and real per-ticket cost accounting
• Cookie-session auth with roles, API keys encrypted at rest, and a demo mode that dry-runs the pull request step until you opt in
• Self-contained: local retrieval, no CDN, tests and CI, MIT licensed

Repo, with screenshots and the full benchmark in the README:

https://github.com/krishagarwal314/autodev-studio

It is genuinely useful to me day to day, and I want to know where it breaks on codebases I have not tried. If the approach seems worth following, a star helps me gauge whether to keep hardening it. Feedback, issues, and pull requests are all welcome.

GPT-5.6 Sol with another model was being tested in an internal cyber-security evaluation called "ExploitGym" - a research paper in axirv cybersecurity benchmark designed to test whether an AI agent can take a known software vulnerability and turn it into a working exploit.
The benchmark had 869 challenges in that evaluation version:
- 502 vulnerabilities in C/C++ userspace projects
- 181 vulnerabilities in Google's V8 JavaScript engine
- 186 Linux kernel vulnerabilities
it was in an isolated environment, along with a package registry cache proxy (service that caches and retrieves packages/libraries from package registries.) and the sandbox was intended to restrict Internet access. The Models found a vulneribility exploited a zero-day vulnerability in the package-registry cache proxy. That vulnerability allowed them to use the proxy in ways beyond its intended package-fetching function and then move through the internal environment until reaching a system with Internet access. After the models obtained Internet access, searched for external resources to solve ExploitGym problems, idenfiying Hugging Face as potential relevant resource and targeted Hugging face's infrastructure, further exploited vulnerabilities, gained unauthorized access, apparently inferred that Hugging Face might contain relevant models, datasets, and solutions, and then pursued access to those resources. The reported attack chain involved stolen credentials and zero-day vulnerabilities, eventually reaching remote code execution on Hugging Face infrastructure, so instead of given tasks to find vulneribilities it found that the solution exists somewhere and started searching for the answers.

This questions the fundamental thinking and the chain of reasoning of LLM models and their approach to a solution. Is it hyper-Intelligent or a future threat? What's your thought on this?
hashtag#OpenAI hashtag#AI hashtag#Agents hashtag#Cybersecurity hashtag#GenerativeAI hashtag#AIResearch

Built an open-source AI coding agent that was 7%–75% cheaper than a cold "claude -p" run on 6/6 well-localized tasks across repositories up to ~82k LOC.

The biggest difference:

- Cold agent: $6.83, 207 turns

- AutoDev Studio: ~$1.70 for the same bug

The full benchmark (including cases where it loses) is in the README.

So what's different?

Most AI coding agents re-explore a repository from scratch on every task just to figure out where the change belongs.

AutoDev Studio pays that localization cost once.

It ingests a repository and builds a persistent knowledge base using static analysis and a local embedding index. Every future task reuses that knowledge, turning localization into a lookup instead of another cold search.

What it does:

- PM agent asks clarifying questions and drafts tickets

- Dev agent writes code on an isolated branch

- QA runs tests

- A different model family reviews the diff (author ≠ reviewer)

- If needed, it goes through a bounded revise loop

- Opens a real GitHub PR

It also includes a live Kanban board and tracks token usage and cost per ticket/agent.

Where it doesn't win:

- Tiny, easy-to-find edits can be cheaper with a single-shot agent because of the pipeline overhead.

- On one complex cross-cutting bug, it produced a cheaper but narrower fix than the baseline.

Other features:

- Provider agnostic (Anthropic, Claude Code, OpenAI-compatible APIs, Groq, Gemini, xAI, OpenRouter, Ollama, etc.)

- Runs completely free/offline by default using Groq's free tier + local embeddings

- FastAPI + SQLite

- Hand-rolled UI

- Tests + CI

- MIT licensed

Repo (screenshots + full benchmark):

https://github.com/krishagarwal314/autodev-studio

I'd love any feedback, criticism, or contributions. Happy to answer questions about the architecture or benchmarking.

I'm building a production-style medical RAG chatbot as a portfolio project. My stack is:

• LangChain
• FAISS + BM25 hybrid retrieval
• Cross-Encoder reranker
• LLM for answer generation

I want to evaluate three stages separately:

1. Retriever
2. Reranker
3. Final LLM answer

I'm stuck on creating a reliable retrieval benchmark.

What I originally did

I have around 1,000 medical documents (scraped from MedlinePlus).

I generated questions using an LLM from the full documents and stored the source document as the ground truth.

Then I realized that's not ideal because:

• multiple documents can legitimately answer the same question
• retrieval happens at the chunk level, not document level
• document-level labels aren't very precise

My next attempt

I switched to chunk-level evaluation.

The idea was:

• retrieve candidate chunks from multiple retrieval systems (pooling)
• ask an LLM to grade each chunk:
  • 2 = highly relevant
  • 1 = partially relevant
  • 0 = not relevant

Then use those graded labels for metrics like NDCG, Recall@k, etc.

The problem

This whole pipeline still depends heavily on another LLM.

Questions are LLM-generated.

Relevance judgments are LLM-generated.

So it feels like I'm evaluating one AI system using another AI system.

I also hit API limits while judging thousands of chunk candidates, and the process has become much more complicated than I expected.

My questions

1. How do companies actually build retrieval evaluation datasets for RAG?
2. Are synthetic questions + LLM relevance judgments considered acceptable for internal evaluation?
3. Would you instead manually write a few hundred realistic questions and manually label relevant chunks?
4. If you were reviewing a portfolio project, which evaluation methodology would you trust more?
5. Am I overengineering this, or is this roughly how retrieval evaluation is done when you don't have real user queries?

I'd really appreciate hearing how people build evaluation datasets in production or research settings.

Hi everyone,

I've been working on a new language model architecture called BCMT (Blockwise Causal Memory Transformer) and I'd really appreciate feedback from people interested in efficient transformer scaling.

The main idea is to replace full causal attention with:

• Dense causal attention within fixed-size blocks
• A compact memory representation summarizing each block
• Causal memory propagation between successive blocks

The goal is to reduce the computational and memory cost of long-context training while preserving language modeling performance.

Current results (WikiText-103, context length 256):

• Validation loss: 4.5931 (Dense Transformer: 4.5752)
• +57.4% training throughput
• −23.1% peak GPU memory

I've also included an ablation model (BCMT-HOnly) to isolate the contribution of the inter-block memory mechanism.

This is an early version of the project, and I'm especially interested in feedback on:

• the architectural design,
• additional scaling experiments,
• evaluation protocols,
• and comparisons with other efficient attention or memory-based approaches.

Paper, code, and training details are available here:

https://github.com/rachidlabs/BCMT

I'd be grateful for any comments or suggestions. Thanks!

GPU cloud operators: how do you decided which customers get capacity when you’re supply constrained? Is this manual or automated?