A flow that resends on timeout, with no record of what it already sent and no duplicate-protection key, writes that record twice. That's the point where ownership matters. **Someone must decide, before the first real batch, who is paged, what the cap on retries is, and how a record is marked as done.** ## Cost of the failed Hindsight batch run By the end, most of a working day had gone on cleanup for the person who was paged. The night also left a block of half-processed records, a run of duplicate calls billed at full price, and customers who saw the fault before anyone did. I've fixed no figures here. Any number I invented would be read as a benchmark, and the real inputs are your own rate limit, retry cap and unit price. In place of figures, the table gives each row a stand-in in words, the formula that turns it into a number, and the place where your real limit goes. Read it as a way to size your own incident before the batch runs, not as a forecast. | Row | Invented value | Formula | Where you enter your real limit | |---|---|---|---| | Cleanup hours | Most of one person's day | Half-processed records × minutes to inspect and repair each ÷ 60 | Your own repair time per record, measured on a small sample | | Half-processed records | The share of the batch in flight when the limit hit | Requests in flight at the failure × share that had already written a result | Your concurrency setting and the provider's documented rate limit | | Duplicate calls | One extra call per record that was retried without a done-marker | Records retried × retries per record, up to the cap | Your retry cap | | Duplicate spend | Every duplicate call paid for in full | Duplicate calls × documented unit price per call | The unit price on the provider's pricing page for the model you call | | Customers affected | Those whose records sat in the half-processed set | Half-processed records that reach a customer-facing step | Your count of records that trigger a message or update | Pull on one row and the others move. A lower retry cap shrinks duplicate calls, and a done-marker written before the next step shrinks half-processed records. Both cut cleanup hours and the customer count in turn. Duplicate spend is the easiest row to measure, but it's rarely the costly one. Run the arithmetic with your own limits before the first real batch. If the cleanup-hours row comes out larger than the time you are willing to give up at 2am, the cap and the done-marker need tightening first. ## Missing rate limit defenses in the workflow Whoever owned the workflow found out from a customer, not from the system, after five missing controls stacked up and it failed. Each gap is ordinary, and each one stays invisible until the first real batch arrives. ### Setting batch size within the tier limit Sized by how many records needed processing, the batch ignored how many requests the account's tier allows per minute. Test a handful of records and you never come near a per-minute limit, so the first working request proves nothing about it. A full batch hits the gate within seconds, and everything past it is rejected. Put a queue between the records and the worker; that is the generic fix. The worker drains it at a rate set below the published limit. If you move to a higher tier, that raises the ceiling and fixes volume only. It does nothing for the missing retry, cap and duplicate rules, so a larger batch just fails the same way, faster. ### Retries that made the outage worse When the gate rejected a request, the flow retried immediately, with no pause and no stop condition. Each rejection produced another request, so the worker spent its whole run pressing against a limit that only eases when it stops pressing.  Look at the illustration below: the retry arrows loop from the gate straight back to the worker with no gap between them, and the worker never gets a quiet minute in which the limit could reset. To repair this, use backoff with jitter, the standard approach. The wait grows after each failure, and a random offset keeps parallel workers from retrying in step. Pair it with a hard cap on attempts per record and a spend ceiling per run. Without those two, a retry loop is an open-ended bill with nobody assigned to watch it. What follows from the picture is the quieter half of the failure: the loop was noisy to the API, yet silent to the people who owned the flow. ### Idempotency keys and alerts for API failures Before the error came back, some retried requests had in fact succeeded, so the retry processed the same record twice. The duplicate cards in the illustration pile up past the gate for that reason.  To fix it, use an idempotency key per record and a done-marker written only after a confirmed result, so a repeat is recognised and skipped. Then there is the bell that never rang. Nothing counted rejections, nothing flagged a record that exhausted its attempts, and nothing paged a named person. A flow with no alert and no owner fails correctly, in the sense that it does exactly what it was built to do, **until someone notices the bill or the backlog**. ## Fix it in a workflow with Activepieces: the rules that changed The rules go into the flow by hand, and whoever builds the flow owns them. The connection options, in order of simplicity: 1. An HTTP request step. 2. An AI step pointed at a custom or OpenAI-compatible provider. 3. An MCP server. The rules can also be described rather than assembled step by step. Describe the retry cap, the done-marker and the alert in Activepieces' built-in chat, and what it publishes is a live flow in your account, editable like one a builder assembled by hand, with a run trace for every execution showing exactly what happened.  It sits under the same RBAC and audit logs as every other flow, and MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production. ### Option 1: the HTTP request step Start here. It calls the API directly, so every header, timeout and error code stays visible to you. The cost of a bad retry is the part people miss. On the [Activepieces pricing page](https://www.activepieces.com/pricing), Free carries 1,000 credits a month, and a large batch of runs, especially with AI steps, or repeated test runs can use it up faster than expected.  With your own AI keys on Plus and up, every AI step costs 1 credit and the model cost goes to your own provider bill. Plus carries 10,000, which buys room but also lets a runaway loop burn for longer before anyone notices. On Team, which carries 50,000, a loop can run unattended for days and the invoice becomes your alert. Next come the connections that add less control. Option 2, an AI step with a custom provider: use this only if the AI step accepts a custom base URL and Hindsight's endpoint speaks the OpenAI request format. I haven't confirmed either, so do not build on it before testing one request. Where it works, you trade control over errors and retries for convenience. Option 3, an MCP server: treat this as unavailable until Hindsight publishes an MCP server. Without one, there's nothing to connect. The five rules now in the flow: 1. Retry only on rate-limit and server errors, a fixed number of times, with a growing delay between attempts. 2. Never retry a client error such as a malformed request. It will fail identically every time. 3. Cap each run's call count and each day's total, so a loop stops well short of your plan's credits. 4. Store a unique key per input record and check it before calling, so a restarted batch skips finished work. 5. Alert a named person when a cap trips or retries run out. Monday checklist: - Confirm the flow has a named owner. Run ten records through it before the full batch, so you'll catch configuration problems before scaling to the full dataset. - Check that the alert reaches a real inbox. ## Frequently asked questions None of the four questions below is answered by the Hindsight docs I can cite, and each one decides who gets paged when a flow stops working. The table records what the docs state for each, so you can tell a documented fact from an assumption before you build on it. | Question | What the Hindsight docs state | Source link | |---|---|---| | Free tier | Docs silent | None to cite | | Client-library compatibility | Docs silent | None to cite | | Key rotation | Docs silent | None to cite | | Where pricing and limit changes are posted | Docs silent | None to cite | With every row reading "docs silent", each answer below is a rule for working around the gap, not a fact about the service. Put a named owner on each gap before the first real batch. ### Is there a free tier for the Hindsight models inference API? Plan as if there's no free tier, because the docs are silent on one. A flow that quietly depends on free usage fails the first time the account is billed or throttled. Ask the vendor in writing, keep the answer with the flow's runbook, and set your own spend cap in the flow so a loop can't create the bill for you. ### Is the Hindsight API compatible with OpenAI client libraries? Do not assume compatibility with OpenAI client libraries; the docs state nothing on it. A library that appears to work on one request may mishandle error bodies, retry headers or streaming, and those are the paths a first request never exercises. If you test a library, test it against a forced failure, not only a success, and record which version you tested. For rotating or revoking a Hindsight API key, the docs describe no procedure. That makes key ownership your problem: record who issued each key, where it's stored and who can replace it.  Keep keys in one secret store, not copied into individual flows, so that if the vendor offers no rotation path you can at least replace a key in one place. ### Where do I check for changes to Hindsight pricing and limits? Nobody will warn you by default: the docs name no changelog, status page or notice channel for pricing and limit changes. So assign one person to check the vendor's pages on a schedule and to read account emails.  Have the flow log every limit or rate error it receives, because a sudden rise in those errors may be the first sign that a limit changed. ## Related reading - [Hindsight Models for Agent Memory: What Each Does](https://www.activepieces.com/blog/hindsight-models-for-agent-memory-what-each-does) - [Hugging Face Inference API Pricing: A 2026 Guide](https://www.activepieces.com/blog/hugging-face-inference-api-pricing-a-2026-guide) - [DeepInfer (2026): DeepSeek's Inference Framework, Oct 20](https://www.activepieces.com/blog/deepinfer-2026-guide) ## References - [Activepieces](https://www.activepieces.com/pricing) - [Deploybase, Standard Compute, Google AI forum](https://deploybase.ai/articles/llm-api-rate-limits-compared-all-providers) - [Rewindex](https://rewindex.com/company/anthropic/reports)When a call times out, all you know is that no answer arrived, not that nothing happened.