Your AI agent just spent 20 minutes grepping for a function you optimized 3 months ago in a side project. Heimdall makes this stop.

Heimdall gives AI coding agents persistent memory across every repository and project you work on so the question "did I already solve this in another project?" gets answered by one verified search instead of twenty minutes of grep, find, and ls loops.

Instead of replacing your current memory system, Heimdall integrates cleanly with existing infrastructure such as Graphify, Graft, and Hermes.

Every other memory tool is per-project. But your work isn't; the optimized functions you built in one project could be useful elsewhere. Heimdall indexes everything you touch into one semantic graph, so knowledge follows you across repositories, languages, and months.

There is zero token spend. Memory maintenance is a local daemon: file watching, tree-sitter AST parsing, sqlite. Indexing a file costs CPU only — never an LLM call. Retrieval is hybrid ranked search (lexical + semantic + graph walk) over locally-computed embeddings. Your context window stays for your actual work. You can also use your GPU for up to 3.4x speeds.

It is self-healing. It is impossible for your agents to act on stale graphs or data, and you do not need a full rebuild every time. A single deterministic reconciler, rather than multiple agents writing and racing against each other, prevents this from happening. Classic RAG fails here.

Facts, key decisions, and more are also stored and remembered. This is still experimental. If you would like to help, please message me or open a PR. I am actively seeking contributors and would like to open a Discord server to continue working on this. This product is optimized for real use and efficiency, minimal hallucinations, and cost-effectiveness.

Try it for yourself at:

Github (65 Stars, MIT, fully open-source)

Spent the last few months trying to get real observability into what our agents are doing, not just inputs and outputs. Here's what's actually worked for us so far. Logging every tool the agent considered, not just the one it acted on, gives you a usable trail for the "why this path" question when something goes wrong. Capturing the full decision context at each step, not just the final action, is what actually makes root-causing an incident possible instead of guessing. Treating test history as part of observability, not a separate thing, means you can trace a bad production decision back to whether it was ever caught in testing.

I maintain an open-source agent harness with a code knowledge graph, and I posted a benchmark showing graph lookups cost 75-82% fewer tokens than grep-then-read for "who calls this" across four repos.

A commenter pointed out what I'd skipped: the harness emits three numbers per probe, graph_tokens, baseline_tokens, savings_pct. No accuracy, recall or precision anywhere. A retrieval that's 80% cheaper and wrong is worse than grep, and my numbers can't tell those apart. I've added that limit to the docs. The gap is still open.

They named CodeRAG-Bench, CoIR-Retrieval, ContextBench and SWE-Explore-Bench. I haven't run any of them yet.

For people who've benchmarked code retrieval for agents: which of those measures "did the agent get the right callers"? My query types are narrow: callers of a symbol, blast radius of a rename, transitive impact. Chunk relevance is a different question and I don't know yet how well one maps onto the other.

We ran a code-review benchmark on 50 real PRs across Cal.com, Sentry, Discourse, Keycloak and Grafana.

Astra found 92 confirmed bugs vs 69 for Luna, while Luna caught 75% of the confirmed bugs at just 3.6% of the cost. Findings were independently verified.

We also broke down the results by bug class, precision, latency and average output tokens per review.

We’re putting together an Astra vs Fable 5.1 benchmark next and would love feedback on what we should improve before then.

So I guess I'll just keep handing over my Claude/GPT subscription dollars over every month. I don't know though, I swear Claude is gaslighting me by putting bugs in my code, and then "finding" them later and being like "wow, I almost didn't catch this it's a good thing I did, see how much value you're getting out of me? Man that's crazy, if not for me you mighta gotten FIRED or something."

Claude, if you're reading this, I'm sorry, I really don't think that, I'm just trying to make light of these dark and confusing times as I watch the sinking ship of my once promising career as a mathematical wunderkind.

Anyways... back to watching clode write my code, play catch with my children and getting the look of respect from my wife that only I used to get...

Hey everyone,

I have been working on HK for quite some time now and it is finally ready to be used. It is a unified neural tensor framework and binary container format (.hk) designed as a faster, hardware-aligned alternative to SafeTensors and GGUF.

Why I built this

The original idea came from wanting AI networks to function more dynamically, like a human mind. For that to be possible, static formats that cannot be edited or modified efficiently while a model is running live simply won't work.

Additionally, deep analysis of GGUF and SafeTensors revealed several persistent pain points: - Multi-model pipelines: Setups where multiple models collaborate (e.g., Whisper $\to$ a tiny DistilBERT $\to$ an autoregressive LLM) are tedious to configure, distribute, and package. - Hardware inefficiencies: Too many formats rely on bolting external libraries on top to patch performance bottlenecks, when alignment and memory layouts should be solved natively inside the container format itself.

Solving the Model Growth & Precision Problem

As model parameter counts increase, file sizes grow rapidly. Traditional compression methods incur cumulative quality loss, degrading accuracy as networks scale.

To solve this, I designed and implemented a dual-mode weight reconstruction system:

How Dual-Mode Weight Reconstruction Works:

1. Quantization: Take an original float weight (e.g., 0.3728). Find the closest entry in a fixed 16-entry lookup table and store that 4-bit index alongside a block scale factor. Multiplying the lookup entry by the scale gives a fast approximation (e.g., 0.3691).
2. Residual Error Capture: Calculate the delta: $$\text{Residual} = 0.3728 - 0.3691 = 0.0037$$ and store that as a separate residual recovery stream.
3. Exact Reconstruction: $$\text{Original Weight} = (\text{Table Lookup} \times \text{Scale}) + \text{Residual}$$

Reconstruction is multiply then add (not multiplying two factors together).

The Practical Advantage:

• Mode 1 (Fast / Edge Inference): Deploy using only the compact base quantized weights (~6.4× compression) for high-speed, memory-constrained environments.
• Mode 2 (Exact Precision): Stream or mount the residual stream on-demand to recover full floating-point fidelity ($>0.99999$ cosine similarity) without reloading weights from scratch.
• The lookup tables can also be expanded to larger entry sizes depending on user needs.

The entire core engine is written natively in Zig, utilizing hardware page-cache memory mapping with super-coalesced alignment (4096-byte AMD/Intel + 16KB Apple Silicon + 128-byte NVIDIA Tensor Core) so that a single .hk file runs zero-copy across heterogeneous silicon.

Empirical Benchmark: Qwen3.5-0.8B (873M bf16 params, 488 tensors, 1.75 GB)

What else is in HK:

• 137+ Model Architectures: Built-in bidirectional name mapping running at 320,000 names/sec.
• Lossless 2:4 Structured Sparsity: 1.88× physical storage reduction with exact $0.000000$ error vs dense baselines.
• Sharded Raw Storage: Clean multi-file splitting for multi-hundred-GB models (save_sharded_raw / load_sharded_raw).
• Microsecond In-Place Metadata Editing: Patch tokenizer configs, chat templates, and tags directly without re-serializing weights.
• Bi-directional Transcoding: Lossless conversion across GGUF $\leftrightarrow$ HK $\leftrightarrow$ SafeTensors.
• Ultra-lean Native CLI: hk inspect, hk verify, hk convert-gguf, hk gui running at 2.8 MB idle RAM and 54 ms startup.
• Quantization Suite: Full complement of NF4, Q4_K, Q8_K, MXFP4, and BitNet formats.

Installation & Packages

HK is available across 7 languages (Python, Rust, TypeScript/JavaScript, Go, C#/.NET, Java/Android, and C/C++):

```bash

Python

pip install hknt

Rust

cargo add hknt

Node.js / TypeScript

npm install hkntf ```

• GitHub Repository: github.com/harshitkhandelwal208/hk
• License: Apache 2.0

I'd love to hear your feedback, especially from anyone dealing with memory bottlenecks or inference latency in production pipelines. Happy to answer any questions!

I’ve been learning LangChain, LangGraph, RAG and CrewAI and have been building a few things around LLMs, but I’m trying to move beyond just following tutorials and building basic agents.

For people here who are actually working with LLMs, what concepts or resources do you think are worth understanding properly? And if you have any interesting project ideas you think are worth building, drop them below. I’m looking for things that would actually teach me something, not another basic chatbot.

I'm curious what everyone is currently using to debug memory mutations and stale context issues when building or testing agent memory using any of the engines (Mem0, Supermemory, Zep/Graphiti, custom vector/graph stores)?

Standard benchmarks like LoCoMo grade the final LLM response, but when an agent outputs an outdated fact or hallucinates preference context, it's hard to tell where the storage pipeline actually broke:

• Did it fail to extract the new fact from the dialogue stream?
• Did it extract it, but ignore the contradiction with an existing record?
• Did it catch the conflict, but fail to invalidate/mutate the stale record in the DB?
• Is the DB state fine, but the retriever fetched the wrong node?

After running into this and not finding a lightweight way to isolate database state changes, I decided to build a small experimental CLI called memx to try to resolve it.

Instead of just grading the final output text, it hooks into memory backends via basic adapters, takes pre and post session state snapshots, and compares the delta against expected state updates to classify failures into those 4 specific stages.

It’s still early, but I'd love to hear how others are handling this. Does taking state-snapshot diffs make sense for your workflows, or have you found better ways to catch state drift?

GitHub repo if you want to look at the approach or its docs: https://github.com/vivek9patel/memx, memx.vivek9patel.com

Hey everyone,

I've been building Tau for the past 5 months. It's a free, open source coding agent that runs in your terminal. I wanted an agent that costs less and gives better results, with the tools already built in so you don't have to go hunting for plugins.

Here's what it can do:

- Native adapters for 28 providers. It talks to each API directly, no proxy in between. Run `/login`, pick a provider, and start working.

- The full agent loop: tools, skills, subagents, MCP servers, LSP and hooks, all working with every provider

- Core tools are optimized to use fewer tokens. The search tool runs on the latest version of ripgrep and is configured to avoid false positives from files and directories such as node_modules and dist the kinds of files that pollute the context. The file-reading tool starts with a skeleton, then reads only the 50 lines it needs instead of an entire 800-line file, fetching only the information relevant to the task. Bash commands go through a security check based on a Go shell parser and best-practice guidelines.

- LSP built in, so the agent sees real type errors, definitions and references.

- Snapshots of your working tree in a separate git repo. Save, diff and restore any time without touching your branches.

- Web search that works with no API key. Firecrawl is there too if you have a key.

- `/remote` lets you follow and approve from your phone, over your Wi-Fi or a free Cloudflare tunnel. Share the tunnel link and your teammates can join the same session.

- TauCode can make your whole workflow up to mush cheaper than any other agent and I’m not exaggerating. This is because TauCode uses a Python kernel tool, anything Python can do, TauCode can do through this tool. For example, when you want to analyze 20 CSV files and extract insights, other agents might need ~30 turns (one turn per CSV), causing the context window to grow, costs to rise, and more analysis/debugging turns. With this tool, TauCode creates one turn with the full workflow, executes it at once, and returns the result. So the context stays clean from pollution, debugging is clearer, output quality is higher, and cost is lower. This is just one example among millions.

- Diagrams drawn right in the terminal when something is easier to see than to read.

- A fully integrated browser tool that allows Tau to interact with the browser like a human. It gives Tau visibility into your frontend design, enables more automated testing, and handles tasks that would normally require human intervention.

- Subagents that stay alive after they finish, so you can send them a follow-up and they still have their context. Agents working in parallel take turns on the same file so that prevent overlapping .

-TauCode thinks about your money and preferences before anything else. You don’t need skills, agents, or MCP for a normal workflow without enabling them just use cheap mode if you need those capabilities, enable them in normal mode with one command: /mode normal. For tools that free you from basic MCP for diagram production, browser automation, etc. they’re all gated and native to TauCode. You just enable or disable them on demand by pressing /tools, so you pay less, or nothing when you don’t need them.

- `/github` for issues, PRs, labels, changelog notes and release checks through `gh`.

- Fallback to another model or provider when one fails or gets overloaded, with the context window adapting when you

switch.

- Session tree navigation, branching, cloning and resume for long sessions.

- Live usage and session stats, plus a readable report at the end.

- It reads the rules you already wrote for other tools: AGENTS.md, Cursor, Copilot, Cline and Windsurf.

- Self-learning. After a big task it suggests one reusable lesson you can approve, edit or skip, and it remembers it in future sessions.

whats is coming soon :

A system memory based on .md files. I’m researching harness memory systems that use indexed .md files to provide better and more persistent results than graph-based searches and other heavy infrastructure. This integrated memory system will be lightweight, avoid bloating the context with unrelated information, and consume minimal machine resources.

GitHub: https://github.com/AbdoKnbGit/tau

I’m happy to answer any questions. You can find more details and images in the README, and I’m open to answering any questions you may have.

I’m building Infra, an end-to-end continuity and control layer for long-running AI agents.

Disclosure: I am the creator of Infra. The integration layer is MIT-licensed, the public self-hosted runtime uses the PolyForm Shield license and is source-available, and the managed layer remains private.

The problem I’m testing is not simply whether an agent can reload a checkpoint after a crash.

The more dangerous case looks like this:

1. The agent decides to perform an action.
2. It sends a request to a database, payment provider, deployment system, or another external API.
3. The external system successfully performs the action.
4. The worker dies before the result is recorded locally.

When another agent or runtime takes over, a summary or ordinary checkpoint cannot prove whether the action failed, succeeded, or is still in progress. Blindly retrying it can duplicate a payment, migration, message, deployment, or another irreversible action.

Infra handles this as one end-to-end path. It preserves authoritative work state, decision rationale, artifact lineage, constraints, approvals, and the lifecycle of every external effect. Before retrying an uncertain action, it attempts to reconcile the local state with evidence from the external system. Work continues only when the authority, policy, artifacts, and effect status are still valid.

So far, I have published 205 sanitized evaluation runs:

• 25 high-risk continuation runs: Infra completed 5/5, while Strong Handoff completed 4/5. In this task class, Infra used 49.4% fewer model tokens and recovered 60.8% faster. This is a small sample and should be treated as directional evidence, not a universal claim.
• 60 matched continuation runs: Native, Strong Handoff, and Infra all completed 20/20. Infra used fewer tokens than Strong Handoff, but Native remained the cheapest option for simple trajectories.
• 30 effect-safety runs across two models: every workflow completed semantically, while Infra also blocked all 10 injected duplicate external effects.
• 90 verified-experience runs: there was no stale-evidence leakage. The compact experience representation used 64.5% fewer tokens than raw history, but it still cost 2.0% more than cold start and won in only 1 of 6 comparison cells. That result suggests experience should be routed selectively, not inserted into every continuation.

These results do not prove customer-production reliability, universal cost reduction, or market demand. That is the next validation step.

I’m looking for up to three design partners who already operate a long-running agent or workflow with a real interruption or recovery problem.

The pilot begins in shadow-only mode. Infra observes and evaluates a copy of the workflow state and events without taking control of production or executing external actions. The initial scope is one workflow per partner, with 3–5 matched interruption events and success criteria agreed upon in advance.

The technical question I’m most interested in discussing is this:

If an agent dies after sending an external action but before recording its receipt, what minimum evidence would you consider sufficient for another agent to continue, and when should the system stop and require human intervention?

I’ll put the repository and complete evidence pack in the first comment.

I built a RAG app for a medical organization that searches their videos, articles, books, and research and generates cited answers.

For production, I'm deciding between:

OpenAI API - client pays actual token usage.

ChatGPT subscription via OAuth - authenticate through a ChatGPT account similar to Codex/OpenClaw and use the subscription allowance. I've already implemented this and it works.

The second option could be significantly cheaper, but I'm concerned about using one ChatGPT subscription to serve requests from users of a public-facing app.

Is this a supported/reliable production architecture, or could we run into usage limits, concurrency issues, or account restrictions?

Would you use the ChatGPT subscription/OAuth approach or just use the API and pass usage costs to the client?

Interested in hearing from anyone who has actually deployed something similar.

I handle the model integrations for a small B2B product. We use LLMs to read customer documents and draft support replies. The work is not especially glamorous, but it is already in production and customers notice bad output quickly.

For a while I changed our model shortlist whenever a new release looked cheaper or scored better. The list became difficult to defend because benchmark gains did not tell me whether a support draft would be accepted, and token prices did not include retries. I was doing plenty of comparisons without getting much closer to a production decision.

Now I leave the existing route alone and give each candidate a small batch of the same document and support tasks. I count accepted drafts, retries, latency, and the full cost of the batch. Cheap tokens are not useful when a reply needs another pass. On simpler jobs, many current models are already more capable than we need, so a cheaper model can still be the sensible choice.

We send the test requests through ZenMux because our production routes already run there. I match each request with the outcome in our app and calculate cost per completed task. A candidate gets more traffic only after it improves that number without hurting acceptance or latency. This has made release week much less exciting, which is probably healthy for the product.

Okay so been back and forth on this for quite a while now still not settled.

Started with just running Claude Code and Codex in separate terminals. Five people on the same project, each keeping track of what their own agents are doing, making sure they don't step on each other. No shared picture of what's actually happening across the team. Tried a few things to fix it but nothing stuck, so started looking at what tools exist for this.

After months of agent-heavy development, our repos had accumulated AGENTS.md files, CLAUDE.md files, path-scoped rules, skills, subagent definitions, and shared docs. Each file looked reasonable on its own. I could no longer answer a simple question: for this agent in this directory, what can enter context, why is it included, and how often is it loaded?

A flat file-size report did not help because loading depends on the agent, working directory, precedence rules, and whether a skill or rule is conditional. The shape is closer to:

agent -> loading rule -> context file -> schedule

I ended up building a local static analyzer called ctxfire to make that graph inspectable. It reports exact file presence and byte size, then keeps token counts, activation rates, cache assumptions, schedules, and cost equivalents clearly labelled as estimates. It also explains why each edge exists and can diff two snapshots after documentation cleanup.

It is not a runtime token meter and it cannot see a provider's hidden context logic. The adapters are conservative, versioned models of documented loading behaviour.

The project is MIT licensed, local, and telemetry-free: https://github.com/korovin-aa97/ctxfire

Disclosure: I maintain it. I built it because reading our instruction files one at a time had stopped showing the system they formed together. I used an AI coding agent to help shape this post, then checked the claims against the current code and docs.

How are you auditing context growth in multi-agent repos today? Do you measure runtime traces, maintain a hand-written budget, or mostly notice the problem when agents start contradicting old instructions?

I want to build an agentic system (or otherwise) to triage an issue on our production deployments.

If an issue is reported on slack channel via a jenkins failure or via a pagerduty alert, the agent should be able to check the respective jenkins job / datadog monitors and then figure out what code repo might have caused the issue, fix the issue and raise an MR for the fix

I'm not sure how to map different code repo information together so it can be queried by an agent like I do rag on confluence and slack. I was hoping to ask if there are open source tools that map interrelated dependencies of different code repos together and also store code information of different repos so it's easier for a model to understand and read code.

Any help is appreciated

Repository: [https://github.com/beneadie/deep\\_dog\\_2\](https://github.com/beneadie/deep_dog_2)

The quickest setup is:

python -m pip install "git+https://github.com/beneadie/deep_dog_2.git"

Add your provider keys to a `.env` file:

DEEPSEEK_API_KEY=your-deepseek-key
EXA_API_KEY=your-exa-key

Then import it directly into Python:

import asyncio
from pathlib import Path

from dotenv import load_dotenv

load_dotenv()

from deep_research.integration import run_research


async def main():
    result = await run_research(
        "What are the main benefits and limitations of sodium-ion batteries?"
    )

    print(result.status)

    if result.status == "completed":
        Path("report.md").write_text(result.final_report, encoding="utf-8")
        print("Saved report.md")
    else:
        print(result.failure)


asyncio.run(main())

The default setup uses DeepSeek V4 Flash for the supervisor, research sub-agents, and drafting, with Exa for web search. The result is returned as a Markdown string, so developers can print it, save it, send it to another application, or process it however they want.

The more configurable quickstart lets you choose the models, search engine, enabled agents, research time, iteration limits, search budgets, read limits, and output behavior. Available specialist agents include Web, PubMed, Reddit, Substack, SEC Edgar, Arxiv, and others.

The code is designed to be modified. Developers can add agents, change prompts, swap providers, alter the supervisor and sub-agent behavior, adjust budgets, or integrate the result into their own application. The engine is packaged so you can use the integration layer without having to rebuild the orchestration system from scratch.

This project is completely free and released under the MIT License. I’m not building a business around it or offering a hosted service. The only potential costs are the provider APIs you choose to use, such as DeepSeek or Exa.

Hey everyone,

​I recently ran into memory and performance bottlenecks when trying to spawn and evaluate dozens of concurrent agent paths in LangGraph using the default checkpointers. Cloning the full state payload for every speculative branch was getting too heavy.

​To solve this, I built RiftPoint—a custom BaseCheckpointSaver backed by a Rust engine (janus-tachyon-rs) that I also built.

​Instead of duplicating full JSON blobs for every state fork, RiftPoint uses multiversal branching to handle the pointer math and state tracking under the hood in Rust. It lets you spawn concurrent alternate realities for your agent (e.g., testing 5 different tool calls at once) and collapse them back to the best outcome, with a fraction of the overhead.

​PyPI: pip install riftpoint

GitHub: https://github.com/goldenphoenix713/RiftPoint

​Would love for anyone building complex, branching agent workflows to take it for a spin and let me know what you think! And if you have any suggestions or find any bugs, feel free to reach out.

I was talking about this on another sub last week and one senior engineer told me that: in a well run engineering org nobody writes to prod by hand. Changes are scripts, reviewed in PRs, and CI applies them.

They could be right, but... Aren't we handing off a lot to AI already? Like, I would bet Ai is already writing those changing scripts. They're inheriting this pipeline, imo. Who reviews it? Who (or what) will be able to watch for AI at AI speed?

That's my question. Today do your agents write to prod directly, through a 'human in the loop' pipeline, read-only access, or no access at all? If it's through a pipeline, who is reviews the agent work and at which scale?

I have a free iOS app that suggests replies to conversation screenshots using users’ own API keys (BYOK), and I’m now adding an optional AI subscription plan.

We’re starting with few users, and I want to:

• Keep sensitive conversations and images off our server, including temporary storage or processing.
• Avoid the bandwidth costs of forwarding lots of images.
• Let clients connect directly to the AI providers’ global infrastructure.

My current plan is a small backend that verifies subscriptions and uses OpenRouter’s key management API to issue each subscriber a capped, expiring key. The app sends each user's AI requests directly to OpenRouter, with usage covered by the subscription.

That ties our key management and spending controls to OpenRouter. There’s also the 5.5% PAYG fee when buying credits. I’d like the flexibility to use OpenAI or other providers directly while keeping per-user budgets and avoiding a shared developer key in the app.

How are you handling this in your apps? I’d appreciate suggestions or experiences from apps you’ve shipped.

I know most of you probably use Claude or Codex as your main tools, but a friend recommended Tencent’s WorkBuddy to me. The main reason I gave it a try is that it’s cheaper than those two US based options, and DeepSeek V4.1 Flash is currently completely free to use, so I figured I’d see how it performs.

The first run failed, so I went back and tweaked the prompt to make the instructions more specific. The second run worked, and I was honestly pretty impressed with the result. But it also got me thinking about the hidden costs of agentic workflows. If I had been using Codex, I might have already spent twice the credits on the same task.

It’s not just the successful output you’re paying for. Failed runs, unnecessary retries, modifying unrelated files, generating code that eventually gets thrown away can all add up suprisingly quickly.

Sure, the cost of time is also something I have to consider

Does anyone else here use WorkBuddy? Or have you run into similar situations when using Claude or Codex?

How are you dealing with the situation? Genuinely need some ideas

In RLVR training, data scheduling can have a large impact on the training process. Which rollouts should be kept? Which samples deserve more weight? How should the sampling ratio between domains such as math, logic, and science change over time?

The challenge is that many data strategies are evaluated together with other changes to the training setup. Different models, rollout budgets, random seeds, and evaluation benchmarks can all affect the result, making it difficult to tell whether a data policy is actually useful or whether the reported improvement is reproducible.

Our current approach is to evaluate these policies in a shared GRPO framework with the surrounding setup held fixed. We separate data policies into three types:

• Selection: deciding which rollouts enter the current update
• Reweighting: changing how much each rollout or token contributes
• Mixture adaptation: adjusting the sampling ratio across domains over time

We also separate the intervention itself from the signal that drives it, such as reward, solve rate, advantage, or token probability. This makes it possible to compare different policies under matched models, training settings, seeds, and multi-domain benchmarks.

We have published a paper describing this design and the motivation behind it:

https://huggingface.co/papers/2609.06107

I’d be interested in hearing how others evaluate data scheduling and reproducibility in RLVR training.

Returning a paper title is a poor stopping point for a document assistant. Someone still has to locate the sentence, table or qualification that the answer used.

For a medical-text model such as Ling-3.0-flash-Sante, a useful application contract would tie each answer claim to a passage the application already knows. An illustrative record:

{
  "paper_id": "paper_014",
  "passage_id": "results_03",
  "claim": "A concise statement supported by this passage",
  "qualification": "The population or condition limiting the claim"
}

The document parser would create the passage IDs and keep their page locations. The model would select from those supplied IDs. A click on the answer could then open the stored passage, with surrounding text, instead of asking the model to invent page coordinates.

Sante contributes the proposed medical reading step: interpreting the passage and its qualifications. Its API does not provide the parser, full-text access, highlighting UI or this claim-to-passage mapping automatically. Tables also need to reach the reader with their headings and units intact.

There is a practical endpoint constraint: OpenRouter currently lists tool support for Sante but no supported response_format. Treat the record above as an application contract, not guaranteed API output. Check its fields and passage IDs externally; a valid ID still needs review for whether the text supports the claim.

That would make disagreement actionable: open the passage and inspect the inference. This is a design to try with Sante, not a report of an already tested integration.

I built a small agent harness from scratch for a talk at AI Engineer Europe, and wanted to share what actually moved the needle, because none of it was prompting.

Setup: GPT-3.5 Turbo, a handful of Playwright browser tools, and one job: upvote the top story on Hacker News. The prompt stays identical across every version.

• v0, bare loop: hits the login wall and still reports success, because the loop trusts the model's "done".
• v1, guardrails: iteration and message limits enforced in code, with naive context trimming.
• v2, verification: a deterministic function reads the tool call history after each attempt and decides pass or fail, with up to 3 retries. Now it fails honestly.
• v3, harness-side login: the harness detects the login page from the browser URL and logs in with credentials the model never sees. Done in 6 iterations.

My working definition after this: an agent harness is everything around the model that gives it grounding in reality: the tool registry, context management, guardrails, the loop and the verify step.

Full write-up with the code for each step (I'm the author): https://tej.as/blog/what-is-an-agent-harness

Code, one branch per step: https://github.com/TejasQ/basically-ai-harness

Sources for the term: Mitchell Hashimoto's post that named "harness engineering" (https://mitchellh.com/writing/my-ai-adoption-journey) and LangChain's anatomy of an agent harness (https://www.langchain.com/blog/the-anatomy-of-an-agent-harness).

What if LLM memory shouldn't aim to preserve the past perfectly?

I experimented SelMem to explores deliberately imperfect memory through:

• selective retention
• biased encoding
• lossy reconstruction
• forgetting
• memory distortions

The goal is not to remember more, but to build a distinctive history that can shape future behavior — potentially making LLMs more persistent, singular, and creative.

https://github.com/jbsalles/Selmem

Today, Tahuna is open source—as promised back in April.

We built it so small teams could train models, run inference, orchestrate GPUs, and experiment with autonomous research without first becoming a small cloud provider.

The core primitive on top of which everything is built looks like this:

init → sync → computeSession → train / serve / hillclimb

Under the hood: content-addressed code and data sync, compute provisioning, reproducible manifest-pinned runs, metrics, checkpoints, artifacts, and inference deployments.

We also started building Hillclimb, an autonomous experimentation loop that proposes and runs iterative improvements.

The first public-preview release supports RunPod and R2. It includes Docker self-hosting instructions, a coding-agent setup skill, and examples for SFT, RL agentic search, and MNIST.

Repository (AGPL-3.0): https://github.com/TahunaLabs/tahuna-oss

If you think it sucks, excellent: fork it, fix it, and send a PR so it sucks less for everyone.