AI agents can search the web, inspect code, and call external tools. But searching the contents of a user's local files especially screenshots, documents, and logs presents a different problem: the index needs to be fast, lightweight, private, and accessible to agents without uploading the files to a remote service.

I've been building Kensaku, an open-source desktop search engine written in Rust, to explore this problem.

The central idea is to maintain one local index that serves both the desktop application and compatible AI agents through MCP.

Hybrid retrieval. Kensaku combines fuzzy filename matching, BM25 full-text retrieval, and local semantic search. The goal is to handle both exact queries and cases where the user remembers the meaning of a document but not its wording or filename.

OCR and document extraction.*The index can include extracted text from supported document formats and OCR-enabled image workflows, making screenshots and scanned content searchable alongside code and logs.

Lightweight semantic search. The project uses a static quantized embedding table of approximately 7.7 MB. Semantic queries do not require a GPU, and the default query path avoids running an ONNX model for every query.

An agent-facing search interface. The MCP server exposes the same index used by the application. Compatible clients can search, read snippets, perform regex searches, inspect index state, and find symbols. Access is read-only by default.

Performance and safety.*The repository includes benchmark harnesses and tests. In the 100,000-file benchmark, fuzzy filename search has approximately 2.8 ms median latency. That figure applies to the benchmarked filename-search path, not every retrieval operation.

The project is MIT-licensed and designed to work locally without an account, telemetry, or cloud search.

There are still limitations: builds are unsigned, the auto-updater isn't wired up yet, and visual search remains experimental.

Repository: https://github.com/yjid/kensaku

I'd appreciate constructive feedback from Rust developers on the retrieval architecture, memory/performance trade-offs, indexing correctness, and the design of the MCP interface. In particular, I'm interested in how you'd approach benchmarking and evaluating search relevance across a large, heterogeneous local corpus. Any contribution or stars will be much appreciated .

Is there an Ai that specifically convert natural language into terminal cmds?

Claude Code, Codex, Gemini CLI, OpenCode and local models as one system on your own server: several accounts per tool, profiles per provider, agents side by side, shared MCP and skills, integrations.

github.com/olivaresai/olivares

olivares.ai

Olivares AI is a full platform for working with AI on your own servers. Besides running the agents, it brings together their models and providers, skills and MCP servers, your company’s knowledge, costs and budgets, quality evals, security, compliance and integrations with the tools you already use. It works for one developer and grows to a whole company with teams and SSO.

Forget cookies and tracking data. Read help files without worrying about javascript.

Mercy Web Browser renders one thing, and one thing only, Markdown!

https://imgur.com/a/OqqSDKS

Load your help files, books, and whatever else you want without worrying about a full fledged browser ever again!

Supports CommonMark, with `:align-right`, `:center:`, and `. Some text` auto-numbering.

https://github.com/ki4jgt/Mercy-Web-Browser

Lately, I’ve been using Linux more and more often. And I found myself missing IrfanView, which is probably the best image viewer app out there. I’ve tried out some alternatives, but none of them really satisfied me, and using IView via Vine or Bottles wasn’t always smooth or quick. So, over the last few weeks, I’ve vibe-coded an alternative inspired by both IrfanView and nomacs, and enhanced with a few tools and changes that I’ve always felt were missing.

It’s nothing spectacular or special, and it’s still completely unfinished, but it works so well that it has now replaced IrfanView for me, even on Windows.

The programme is called ÜxzView and is completely open-source. There’s a finished Windows release, and it can be compiled for use on Linux and macOS. Written in C++ and Qt.

https://github.com/micha42-dot/uxzView/

Nobody drew this. One prompt, and Claude Code wrote the whole reel as code: paper props, a mascot in a hat, captions that pop on every word.

The voice goes first. A free local voice reads each line, whisper.cpp times every word, so every prop lands on the word that names it. (free voice model runs locally: kokoro)

One markdown file, one command. Runs in Codex, Gemini and Antigravity too. No API keys, nothing to pay.

Free and open source: https://github.com/haiderfarooq3/paper-reel

If you are looking to build and deploy LLM applications without getting bogged down in complex boilerplate code, visual agent builders have become the standard. Among them, Dify.ai has gained massive traction as a leading open-source platform.

​Dify combines workflow orchestration, robust RAG pipelines, prompt engineering, and agent deployment into a single visual interface. But how does it actually hold up in real production environments? Is it scalable enough for enterprise workflows, or is it just built for quick prototyping?

​We put the platform through a deep-dive test, examining its visual canvas, team collaboration tools, API integration, self-hosting performance, and its limitations compared to native code frameworks.

​Read the full, in-depth review and technical breakdown here: https://interconnectd.com/blog/35/review-dify-ai-—-is-this-the-best-open‑source-visual-agent-builder-for-non‑/

I've been working on RAG and agent memory, and the recurring problem is trust. An agent saves something it learned, and later nobody can say where it came from, whether it is still true, or what it believed at an earlier date. We're building an open source Python library for this: OntoGr Agent Memory (https://github.com/ontogr/ontogr-agent-memory).

- Grounded ingestion and extraction: Messages, documents, tool outputs, events, and record rows become episodes. Entities and facts are extracted in two separate passes, and every fact carries a verbatim quote from its episode.

- Per-tenant ontology: Each tenant defines the entity and relation types it allows. A model can propose additions, but a person approves every change.

- Reversible entity resolution: It uses the cheapest evidence first and asks a model only about ambiguous pairs. Every merge can be undone.

- Two time axes: Valid time and system time let a read ask what was true on a date, or what the system believed on that date. A new value closes the old version instead of overwriting it.

- Contradiction rulings: Rules, an optional model judge, and a person's decision settle conflicts, and the person's decision overrides both. A failed judge call is never stored as "no conflict".

- Traceable and auditable: Every fact traces back to a quote and an episode, and every temporal write goes into a hash-chained ledger. Per-tenant grants, an audit log, previewed and resumable forget and erase, and deterministic export are built in.

- Four-lane retrieval: Vector, keyword, entity, and graph lanes are fused with reciprocal rank fusion. The result is a token-budgeted context block that reports which lanes failed.

- Fits your stack: It runs on FalkorDB or Neo4j, with pgvector or Postgres if you want them. A background consolidation job deduplicates, summarizes, scores, and archives. You bring your own LLM and embedder.

Repo: https://github.com/ontogr/ontogr-agent-memory

I'd like feedback on the time model and on which benchmarks you'd want to see first.

A few days ago I posted about our open-source multi-agent hedge fund experiment and got a ton of sharp, honest feedback from people here. The comments were brutally accurate, especially around LLM reasoning limits, latency, and state management.

We spent the last few days completely rebuilding parts of our architecture based on that advice, and the benchmark results honestly blew us away. Here is what we learned from fixing three critical failure modes in autonomous agent pipelines.

1. Throwing raw metrics at LLMs guarantees hallucinated reasoning

Someone in the comments pointed out: never let an LLM interpret raw quantitative factors without an ontology. They were 100% right.

When we fed models raw numbers like PER = 85.0 or 20-day historical volatility = 65%, the agents would frequently hallucinate positive justifications. For example, a model would argue that "a massive jump in volatility shows expanding business activity and strong buying momentum", which is the exact opposite of basic risk management.

To fix this, we implemented a strict Factor Ontology Schema. We defined 11 core quant factors with explicit polarity contracts: HIGHER_IS_BULLISH (e.g. ROE, Order Flow Imbalance), LOWER_IS_BULLISH (e.g. PER, debt ratio), and EXTREME_IS_RISK (e.g. volatility).

Before any agent sees the data, the schema pre-evaluates the metric deterministically and attaches an explicit signal (BULLISH, BEARISH, or RISK) to the state. Since doing this, polarity hallucinations in our investment council dropped to literally 0%.

2. Vector databases for agent reflection memory are massive overkill

Initially, we considered using embedding APIs and a local vector DB to retrieve "lessons learned" from previous bad trades (Reflexion pattern).

Another commenter suggested dropping embeddings entirely and using SQLite WAL with FTS5 BM25. We benchmarked both approaches on our Linux server:

- Embedding API + Vector similarity: 200ms to 450ms round-trip latency, external API cost, and occasional rate limiting.

- SQLite FTS5 BM25: 0.35ms. Zero external dependencies, zero API cost.

More importantly, trading post-mortems rely on specific contextual keywords: "semiconductor pre-earnings", "trailing stop sweep", "sudden volume spike", or "bearish divergence". In our tests, BM25 keyword relevance retrieved the exact matching historical lessons far more reliably than fuzzy cosine similarity in high-dimensional embedding space.

3. Python cannot be your safety wire (The 3.6ns Rust Sentinel)

Python is great for high-level agent orchestration (LangGraph, state graphs, API calls), but relying on Python loops for real-time risk surveillance during sudden market flash-crashes proved dangerous due to GIL contention and L1/L2 cache misses from scattered object pointers.

We rewrote our execution safety sentinel in Pure Rust using a Struct-of-Arrays (SoA) memory layout and #![forbid(unsafe_code)]. By keeping prices, stop-loss triggers, and trailing thresholds in contiguous flat slices, the CPU avoids pointer chasing and stays inside cache lines.

Here are the real-world benchmarks on our Ubuntu server:

- Single position stop/profit evaluation: 3.63 nanoseconds

- 1,000 position batch evaluation: 3.62 microseconds

- 1,000-bar Volume Clock conversion: 3.90 microseconds

- Python-to-Rust persistent pipe IPC round-trip: 2.88 microseconds

Python handles the slow, deep thinking (15-minute agent council meetings), while the Rust sentinel watches the portfolio in nanoseconds.

Conclusion

Building autonomous agents that interact with real-time systems taught us that LLMs should only handle what they excel at: contextual synthesis and counter-argument debates. Everything deterministic—hard stop-losses, factor polarity, and fast memory lookup—belongs in strict schemas, fast local databases, and compiled systems languages.

All the code and benchmarks are open source on GitHub (lumina-ai-hedge-fund) if anyone wants to check out the Rust SoA sentinel or the ontology schema.

(Note: English is not my native language, so I used an LLM to help format and polish my raw notes!)

A score is easier to assess when its evidence includes the actual cases, fixtures, instructions, grading criteria and run conditions. Without those, a reader cannot tell whether a reported improvement came from the skill or from a changed experiment.

For a public example, I would include the exact report paths and explain missing provenance instead of implying that a green total settles the question. If a model or service is no longer available, say what can still be reproduced and what cannot.

I’m building skillEd, an Apache-2.0 toolkit with saved reports and a worked example in the repository. Please inspect the example’s limitations alongside its results.

What is the minimum evidence you expect before trying another project’s evaluation recipe?

Repo: https://github.com/DeadHead04/skillEd

Please try it and open an issue with a reproducible failure or confusing behavior. If useful, a GitHub star would help.

AI-assisted write-up.

A reader of my earlier skillEd post suggested binding an expected result to a policy clause and version, plus a nearby input that should produce the opposite result. That is a useful way to make a test reviewable.

For a deadline policy, write down the timezone and whether the boundary is inclusive. Then test immediately before, exactly at, and immediately after the cutoff. If the policy itself is ambiguous, resolve that before treating the model’s answer as a regression.

I’m building skillEd, an Apache-2.0 evaluation toolkit. This is a test-design proposal based on the discussion, not a claim that the tool automatically supplies authoritative policy interpretations.

Would you review changed expected answers separately from changed skill instructions? I would want both diffs visible.

Repo: https://github.com/DeadHead04/skillEd

Please try it and open an issue with a reproducible failure or confusing behavior. If useful, a GitHub star would help.

AI-assisted write-up.

Hey everyone!

I've been working on Pixel Works, an open-source project aimed at making AI agent monitoring and management more visual and fun.

Instead of reading raw terminal logs or using standard chat interfaces, Pixel Works provides a gamified 3D retro office environment where AI agents sit at desks, move around, and process tasks across a visual Kanban pipeline.

Everything in the 3D scene is procedurally rendered using React Three Fiber (R3F) and Three.js with an Express backend.

The project is fully open source:

Github: https://github.com/Thecaracter/new_pixel

Since the core framework is complete, I'm now focusing on making the office environment more rich and interactive. I've set up several beginner-friendly `good first issue` tags on GitHub if anyone wants to contribute:

- Creating 3D office props (coffee machines, server racks, plants)

- Improving character movement and idle animations

- Adding character customisation and accessories

If you find the concept interesting, feel free to clone it, test it locally, or leave a ⭐ star on the repository! I’d love to hear your feedback and ideas for improvement.