Is self-hosted Hindsight a good fit for a small homelab, or am I using it incorrectly?

[sergiopadure]

Hi, and thank you for building Hindsight.

I run Hindsight at home for a small set of coding projects. I have used it for a few weeks. My model spend is now approaching a thousand euros.

Before I stop using it, I want to explain what I did and what I measured. I hope that you can help me understand the results.

I am sharing this because I hope that I have missed something in my configuration. I would prefer to learn that my configuration is wrong than leave a good tool.

I have two main questions:

• Are there important controls that I have missed?
• Is Hindsight designed for more data and a larger budget than a typical homelab has?

These costs are trivial for a company. They are significant for one person, especially because my results have been mediocre.

My setup

• Hindsight server 0.9.2, self-hosted with Docker on one machine.
• The machine has 16 cores, about 60 GB of RAM, and an NVMe disk.
• Postgres 17 with the pgvector image for storage.
• The coding-agents plugin, connected to my agent sessions for automatic memory reads and writes.
• A handful of code repositories as memory banks.
• One large memory bank of past chat transcripts.

How much data I have

This part puzzles me because my source data is small:

• About 4,400 source documents in total.
• Most documents are chat transcripts.
• A few dozen documents contain Git history.
• 47 knowledge pages.
• About 77,000 memory units.
• About 72,000 entities.
• About 5.7 million memory links.
• About 1.5 million entity co-occurrences.
• About 7.3 GB of database storage.

A few thousand documents produced a graph with millions of edges and a database larger than 7 GB. This result surprised me.

The source material feels suitable for a home system. The resulting graph behaves like a much larger collection.

What it cost

The costs came from three main areas:

• The first document ingest. This was the largest cost by a wide margin.
• The automatic reflect operation at the start of each session.
• Normal search and retrieval.

I never started reflect by hand. It still became the second-largest cost, and one model route used all its available credits.

My total model spend for Hindsight is now approaching a thousand euros. With automatic reflect and reranking enabled, the ongoing cost was roughly ten to fifteen euros each day.

That amount is significant for a small home dataset with only a few thousand documents. It is harder to justify because the results have been mediocre.

What I tried

I made these changes in this order:

• I increased the container shared-memory size twice after actual out-of-disk errors during writes.
• I first increased it from 64 MB.
• I later increased it from 2 GB to 4 GB.
• I tuned Postgres for the host, including shared buffers, cache size, and work memory.
• I reduced the worker count and connection pool after the pool blocked even the administrator connection.
• I disabled model thinking for the write and consolidation steps.
• My measurements showed that thinking increased usage and latency without better recall.
• I increased the reflect timeout from 300 seconds to 600 seconds because calls timed out.
• I tried several model routes for reflect and consolidation.
• These routes included a native fast provider, an auto-router, my own key for the fast provider, and cheaper general routes.
• I repeatedly hit rate limits when writes, consolidation, and reflect ran at the same time.
• I temporarily moved consolidation to a fast model.
• On the cheaper route, each consolidation call took 15 to 30 minutes.
• On the fast model, the same backlog cleared in hours.
• I changed the local reranker to the voyageai/rerank-2.5-lite one on openrouter
• I finally disabled automatic reflect after I understood the cost.

What I measured for quality

These results made me stop and ask for guidance.

Knowledge-page search answered 0 of 15 fixed questions that my data can answer. I did the same evaluation on two different days and got the same result.

The relevance scores for these searches were near the minimum.

The raw recall endpoint performed much better. It returned the correct evidence for 12 of the same 15 questions.

This result suggests that the data is present. The knowledge-page search path did not find it for me.

Reflect answered all 15 questions. On the first evaluation, only about one quarter to one third of its answers were correct.

Roughly 40 to 60 percent of the reflect answers contained a claim that my data did not support.

I also saw self-referential drift. In one case, a note stated that a fact was fabricated.

A later consolidation treated that note as a fact and returned it as one.

In another case, the system said that a decision was approved. Its only source was an earlier system draft, not a real approval.

Consolidation also developed a backlog. The failed-consolidation count stayed at the same value across two separate measurements.

This result suggests a stable group of stuck items rather than a temporary problem.

I searched the issue tracker and found reports with similar symptoms.

One report from a single user described heavy model usage and about USD 5 of credit use in 30 minutes. It also described a long consolidation and a large backlog.

That pattern resembles my reflect costs.

I also found reports of consolidation crashes with the default configuration. Other reports described reflect returning “I don't have information” after the model omitted a required tool call.

These reports appear close to my experience, but I cannot determine whether they have the same cause.

My questions

I am trying to understand which explanation is correct. I would value your advice.

1. Is my configuration wrong?
   Is there a configuration control for the automatic reflect operation at session start? Can I prevent a full, very large model pass during every session? Is a budget or schedule the intended control?

2. Did I miss controls for knowledge-page search relevance?
   Raw recall finds my data, but knowledge-page search does not. Does that path have a reranker or snippet control that I missed?

3. Is write and consolidation expected to use this many resources for this amount of data?
   A few thousand documents produced millions of graph edges. Consolidation calls also took 15 to 30 minutes on the cheaper route. Am I generating too much data, or is this expected behavior that requires a larger budget?

4. Is Hindsight designed mainly for enterprise knowledge graphs?
   Is a homelab with a few thousand documents simply outside the intended use case? If so, I prefer to know that before I spend more.

I would be grateful for guidance in either case.

If my configuration is wrong, I am happy to correct it. If this is a fit problem, your intended data scale and budget would help home users make informed decisions.

Thank you again for your work and for reading this issue.

[Kxrma47]

This is not a hardware-fit problem first; several default automation controls explain the continuing spend. In the coding-agents config set "autoReflect": false, "pageTriggerType": "manual", and "retainSessions": false if transcripts need not be re-ingested; those controls are documented directly in the integration reference. Note that pageTriggerType only affects newly created pages—existing pages must have their trigger patched or be recreated (same documentation). I would stop paid consolidation, make those changes, and evaluate raw recall on a fresh small bank before spending further; the graph growth and unsupported reflect claims still deserve maintainer investigation.

[sergiopadure]

Doesn't that defeat the purpose of the tool, if sessions are not retained and pages are not updated when knowledge advances? To my understanding the goal of this tool is to provide up to date consistent memory to agents, by disabling those feature that disappears, so what would then be the benefit of keeping the tool?

[Kxrma47]

You're right—turning all three off permanently would remove much of the value. I should have described that combination as a short diagnostic/cost baseline, not the recommended steady state.

A better homelab balance is to keep retainSessions: true, set autoReflect: false (this only removes the automatic first-prompt synthesis; retained memory and on-demand recall still work), and use pageTriggerType: "cron" with something like pageTriggerCron: "0 3 * * *". Pages then remain current on a schedule, and the documented cron refresh is skipped when nothing changed. That preserves evolving memory while avoiding a synthesis for every consolidation: https://github.com/vectorize-io/hindsight/blob/main/hindsight-integrations/coding-agents/README.md#reference

[sergiopadure]

Yeah, that's what Fable ended up recommending as well, but Astra is asking the question if any of this even makes sense. I think I'll start a deep research into the various options to see what's the most sensible for my environment because my current impression is that without hooks the models are going to keep hitting retrieval issues with such a corpus, and unless retrieval is sub-second it makes little sense to put hooks as that would slow down work quite a lot.

Regardless, thank you for your answers!

[voarsh2]

I didn't migrate my codex coding workflow to the new coding agents because "reflect" at the beginning of a session doesn't work well.
Also - I am stuck on on shared default bank - a lot of my projects are same domain and framework - so 5 private repos separates too much valuable data

Recall on every turn can be ok - like the "legacy" integration - and on demand reflect MCP tool calls....