Show HN: Don't Hit Send – the model answers while you type | Hacker News Reader

Show HN: Don't Hit Send – the model answers while you type

github.com

7 pointsRomulusHill3 comments

Type. The model is already answering. There is no send button.

Left pane is one long draft. Right pane is a stack of replies. Pause for ~350ms and it fires a normal streaming chat completion with the whole draft. Type again and it aborts the last request if that reply never produced text; if it did, that bubble stays and a new one stacks. Bubbles never rewrite. Enter is a newline.

That is overlapping unary streams, not a duplex socket. Same shape as ghost-text, pointed at a conversation instead of a code line. The bit that took the work is the hold: do not fire on "and N" while someone is still typing "and NASA".

git clone https://github.com/scalattice/dont-hit-send.git cd dont-hit-send export SCALATTICE_API_KEY=slt_... # or OPENAI_API_KEY + OPENAI_BASE_URL ./run.sh # http://127.0.0.1:8766

Stdlib Python, MIT, key stays on your machine. Defaults to Scalattice OpenAI-compat; any host that speaks /v1/chat/completions works from Settings or env.

Browser demo on our inference platform (sign-in after a short try): https://scalattice.com/dont-hit-send/

Why've we built this? The conventional AI chat interface is overdone and lacks innovation, I've personally been building agentic software for a while now and feel a lack of innovation in the interactivity. This is a step towards trialling some different inference interfaces!

Open articleView on HN

"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.

Reply on news.ycombinator.com