Thanks for the quick response. My use-case for a Fiddler Replayer would be to replay captured network traffic generated from desktop application, allowing me to "spoof" the actions performed by that application in an automated testing environment. This is important as said desktop application contains no internal hooks which I could call in an automated fashion.
To that end, all I would require in a Fiddler Replayer is a tool that can replay a specified SAZ file and then terminate when finished. Capturing the entirety of the response data isn't necessary.
What I meant by a "reasonable return code" is highly negotiable and would basically any return code. Starting Fiddler from the command line, specifying a SAZ, merely opens the Fiddler GUI and never returns anything. An automated system has no idea when and if the Fiddler process actually did anything. In this case, "reasonable return codes" could be something like "hi, I finished", "that saz was invalid", "uh oh, I got a 401/403 as part of the response", "oops, I got a 500 as part of the response". An entire captured response SAZ may be unreasonably cumbersome to parse. Any return code that tells me Fiddler has finished working and whether it did what I was expecting would count as "reasonable" to me.