[Discord][help] Shipper connection reset failures still consume credits

[kokisanai]

Created from Open Design Discord support triage.

Discord source:

• Channel: #help
• Message URL: https://discord.com/channels/1479002485040480266/1479045739882483753/1517111311312490617
• Author: Sanjay
• Time: 2026-06-18T10:18:43.182Z

User report:
Bought credits, tried Shipper, hit continuous "connection reset" style failures, and credits were still consumed. User asked whether credits can be refunded and asked for investigation. Attachments included screenshots:

• Screenshot_2026-06-18_151851.png
• WhatsApp_Image_2026-06-18_at_3.47.13_PM.jpeg
• Screenshot_2026-06-18_151834.png

Why this looks product-side:

• Failure is described as repeated runtime/connection-reset behavior during use, not a one-off prompt-quality issue.
• Credits being consumed on failed or cut-off runs creates a billing/trust problem.
• The user is explicitly asking for product investigation and refund clarity.

Expected:

• If a run fails due to connection reset / transport failure, the UX should clearly classify the failure.
• Billing behavior should be explicit and should not silently burn credits on obviously failed runs without a clear explanation or recovery path.
• Support should have a concrete path to inspect logs / usage records for the affected run(s).

Questions / follow-up data useful for debugging:

• Exact Open Design version
• Whether this happened on AMR Cloud vs BYOK / specific provider path
• Exact final error text shown in the failing run
• Whether the failure reproduces in a fresh conversation
• Correlation between failed run ids and wallet history entries

This was opened so support/product can track the runtime+billing side instead of leaving it as a Discord-only report.

[lefarcen]

Hey @kokisanai — thanks for pulling this out of Discord and capturing the billing angle clearly.

This looks like a real runtime + trust bug on our side, not a prompt-quality issue. Two adjacent threads in the repo make it worth tracking here: #3937 fixed one class of mid-stream socket drops by classifying them as retryable instead of immediate hard failures, and #4394 is in flight for AMR Cloud recovery around balance-related interruptions. Neither one fully covers the specific case here — connection-reset style failure and credits still being consumed — so keeping this open as its own bug is the right call.

The highest-value next evidence is: exact Open Design version, whether the failing path was AMR Cloud vs BYOK / which provider, the final on-screen error text, and one or two failing run IDs matched against the wallet history entries. With that, we can check whether the debit happened before the reset, during a retry path, or after a failure that was classified incorrectly.