Skip to content

Featherless streaming context failure

Reproduction and root cause

A custom provider can accept a small test request while rejecting the longer history sent by normal chat. A live Featherless test reproduced this with a synthetic prompt of 40,034 upstream tokens: the response status was HTTP 200 and the content type was text/event-stream, but its single event was an object: "error" with error.code: "context_length_exceeded". The message stated that the account's allowance was 32,768 tokens. The account's authenticated /v1/plan independently returned max_context_length: 32768.

Two bugs combined:

  1. Context budgeting used model-family/catalog limits, which can exceed a provider account's plan allowance. A configured 64,000-token budget was therefore allowed through.
  2. The custom SSE reader ignored the provider's error event, then reported a missing completion marker as a disconnected stream. This hid the actionable refusal.

The historical failing request body was not retained, so the exact original token count cannot be reconstructed. The same observed UI failure was reproduced with synthetic input, and the mismatch between the configured budget and live plan allowance was confirmed. No private chat text was sent in diagnostic requests.

Changes

  • The exact https://api.featherless.ai/v1 provider reads its authenticated plan cap. Positive results are cached for five minutes, isolated by an opaque credential hash; concurrent lookups share one request, the cache is bounded, and failed discovery has a short retry interval.
  • Send, regenerate, and continue intersect the model window with the provider cap before the existing history budgeting. Output headroom remains reserved. Stored messages are unchanged.
  • Custom SSE errors terminate with the upstream explanation, without automatic resend. No-space data: events and the final buffered line are parsed as well.
  • Other provider URLs do not receive Featherless plan requests. Plan discovery failure does not block chat, and subsequent upstream errors remain visible.

Validation

  • Four new streaming regression tests failed before the fix and passed after it.
  • All 213 LLM tests passed, including new account isolation, unavailable-plan, history trimming, and streaming error tests, plus existing retry, single-attempt, and OpenCode session tests.
  • Live fixed-path verification used a synthetic 40,093-token history and the account's configured 12,000-token output reserve. Prompt budgeting retained 17,548 locally estimated tokens; Featherless counted 17,736 input tokens and returned 15 output tokens with a normal completion marker. The diagnostic call itself capped generation at 16 output tokens.
  • Workspace typecheck and build passed. The full server suite passed 1,599 tests, with seven previously reproduced baseline failures and four skipped tests; failure files match the prior baseline comparison (publish date, isolated accounting/memory billing setup, route-source assertions, and duplicate world fixture). No database migration or user configuration change is required.

Run the focused tests from the repository root:

sh
pnpm --filter @yumina/server exec tsx --test --test-force-exit src/lib/llm/*.test.ts
pnpm typecheck
pnpm build