Holdfast

Holdfast's Stripe integration can currently only be configured manually (pasting the Webhook address into Stripe settings and filling in the signing secret), because Stripe Connect requires a platform account and the author does not have one.

Holdfast's core design principle is: a message is not considered acknowledged until it has been safely stored.

Holdfast sits between service providers (such as Stripe and GitHub) and the application, performing five functions: writing to disk before responding, verifying signatures and isolating forged or replayed messages, retrying or safely shelving, explaining problems, and safely resending messages.

In Holdfast the model never decides where a message goes; retries, shelving, deduplication and resending are all implemented in Go code with test coverage.

In Holdfast, Gemma 3 4B is only responsible for choosing one of eight fixed causes (constrained by a JSON schema) and writing the explanatory text, and the code checks the output word by word.

Holdfast applies a verbatim post-check to customer-facing explanations: if they contain terms such as "HTTP", "payload" or "endpoint", or promise an action that was not performed, they are rejected and replaced with built-in rule wording; the title is always generated by code.

Inside the container, llama.cpp read the host machine's resources (60GB+ of memory, 16 cores) rather than the 4GB plan quota, causing the prompt cache to potentially grow to 8GB and trigger an OOM; three LLAMA_ARG_* environment variables were used to set it back to within 4GB.

In Live mode, Holdfast performs double SSRF validation on the forwarding URL entered by the user: it checks the target address once when saving, and checks the resolved result again on every dial.

Holdfast's resend plan sends each event only once, in order of arrival, and events already delivered or with failed signatures are not resent.

Holdfast is a project submitted by developer Tanay in the Hacktoberfest open-source AI challenge, used to solve the problem of lost Webhook messages.

Holdfast uses shape-diff to traverse two JSON bodies to identify field renames (for example, data.object.customer_id disappearing and data.object.customer.id appearing), and provides directional information to the model rather than a raw list of paths.

Holdfast's summary must have a fixed structure: what happened to this payment (who, how much), an explanation of the cause in everyday language, and what will happen next.

Holdfast's Promise check rejects phrasings such as "under review", "will resend" and "our team is...", and developer fix suggestions must point out the field that moved, otherwise it falls back to the rule-generated version.

The author empirically compared Gemma 3 1B and 4B: 1B, in the rename scenario, wrote "the app will resend the shelved event" and told the sender to make the change, and both errors were caught by the checks and fell back to the rule answer; 4B took about 16 seconds on a laptop GPU and accurately stated the customer, amount and specific field.

Holdfast is deployed on Render's two-core CPU, where one Gemma explanation takes 92 seconds; after optimization, two live measurements took 48 seconds and 83 seconds respectively.

The Holdfast page first instantly shows the built-in rule answer, then replaces it once Gemma has written the explanation, in order to mask model latency.

In the field-rename scenario, Gemma judged the cause correctly in the first version of Holdfast, but the summary fabricated a "under review" action, and the developer suggestion direction was reversed (it said the app needed customer_id when it was actually a Stripe field change).

On launch day all Gemma calls failed with connection refused because the inter-service address on Render used the default port rather than Ollama's 11434 port; the rule engine took over automatically and the site remained available throughout.

The first user was the author's own small app Tasklet (which turns GitHub issues into to-dos); in testing, Holdfast acknowledged GitHub's test ping within 0.27 seconds, and when Tasklet returned 503, it retried 5 times within 34 seconds (waiting 2, 4, 8 and 16 seconds respectively) before safely shelving it, then resent after recovery so the task appeared exactly once and was not lost.

In some diagnostic outputs Gemma tried to end a JSON string with a curly quote, causing it to be unable to stop and to repeat itself; the fixes included a per-field length cap, truncating at stray curly quotes, checking that the summary ends like a sentence, and reordering the fields to cause, summary, fix. After the fix it went from 2 of 5 usable to all 4 usable, taking 16–40 seconds.