Two great questions!
The breaker only checks things when a stream is about to start. A half open trial claims one slot before the stream opens, and that slot stays claimed for the entire stream, with no checks in between chunks. Whether the attempt counts as a success or failure only gets decided after the stream finishes and the response passes validation, not the moment data stops arriving. The one exception is an idle timeout in the middle of a stream, which counts as a failure right away. If it waited like everything else, a provider that sends one chunk and then hangs forever would never reach validation, so the call would just hang with nothing ever recorded.
The retry budget treats a retry against a fallback provider the same as a retry against the original one. It only tracks how many recent attempts were retries out of the total, with no idea about tokenizers or how different the output might be. This is intentional, since a retry against a fallback still costs capacity the same way a normal retry does. Whether a fallback’s output is actually equivalent gets handled elsewhere, by a function called detectSoftFailure. It looks at a response that technically passed validation and can still mark it as a failure if it’s wrong in a way validation cannot catch, and that decision is what causes a retry in the first place. The retry budget just counts the retry once it happens. It never looks at why.