"It's super obnoxious when humans interrupt me, but what if a computer did it too while also costing me money just so I could save one single keypress?"
It's painful to contemplate how you thought this wasn't an absolutely terrible idea.
Sending, processing, and responding to "not the thing I want you to respond to because I'm not done composing my query yet" is really not the way to go. But congratulations on burning more of the sky for fun while creating a worse human experience?
Well it's got editable response wait, so that it can re-think its response before sending it to you if the course of your message changes.
I just thought it was a nice idea to pre-generate the response (yes admittedly it burns more tokens) but with open models and frontier level capabilities trickling down to low cost models, I'm not enormously concerned about the cost aspect.
I think it would be quite nice to add microphone input at some point, so that I could see if it rivals nice human response times.
The "not the thing I want you to respond to" part, I understand what you mean, but with some tinkering you could get it to match your usual typing/speech behaviours and cadence so that it doesn't start talking about the wrong thing before you finish your message.
> The "not the thing I want you to respond to" part, I understand what you mean, but with some tinkering you could get it to match your usual typing/speech behaviours and cadence so that it doesn't start talking about the wrong thing before you finish your message.
I believe that you haven't actually thought about the problem. Your choices are, universally, respond sooner than desired or respond later than desired. There is no universal right amount of time to wait. There is no universal pattern to when your inquiry completes. So there is no universe where the machine responds only after you are finished and no sooner but also without waiting longer than it would take you to indicate that you want a response.
"It's super obnoxious when humans interrupt me, but what if a computer did it too while also costing me money just so I could save one single keypress?"
It's painful to contemplate how you thought this wasn't an absolutely terrible idea.
Sending, processing, and responding to "not the thing I want you to respond to because I'm not done composing my query yet" is really not the way to go. But congratulations on burning more of the sky for fun while creating a worse human experience?
Well it's got editable response wait, so that it can re-think its response before sending it to you if the course of your message changes.
I just thought it was a nice idea to pre-generate the response (yes admittedly it burns more tokens) but with open models and frontier level capabilities trickling down to low cost models, I'm not enormously concerned about the cost aspect.
I think it would be quite nice to add microphone input at some point, so that I could see if it rivals nice human response times.
The "not the thing I want you to respond to" part, I understand what you mean, but with some tinkering you could get it to match your usual typing/speech behaviours and cadence so that it doesn't start talking about the wrong thing before you finish your message.
It's entirely open source https://github.com/scalattice/dont-hit-send
> The "not the thing I want you to respond to" part, I understand what you mean, but with some tinkering you could get it to match your usual typing/speech behaviours and cadence so that it doesn't start talking about the wrong thing before you finish your message.
I believe that you haven't actually thought about the problem. Your choices are, universally, respond sooner than desired or respond later than desired. There is no universal right amount of time to wait. There is no universal pattern to when your inquiry completes. So there is no universe where the machine responds only after you are finished and no sooner but also without waiting longer than it would take you to indicate that you want a response.