gysakai

What tests did you run on code from the older models? What kind of security review did it go through? When you say it was "not so good," do you mean it failed to compile or couldn't even pass basic tests?

I hadn't sat down to watch a concert on TV in a long time. It was Mozart and Vivaldi, performed in the courtyard of the Louvre. For a while, I kept wondering, "Where is the conductor?"

Then I noticed that one of the violinists was leading the other musicians while playing, through eye contact, body movement, and the music itself. Only after looking him up later did I learn that it was Julien Chauvin's ensemble, and that this was simply how they performed.

I ended up watching Julien Chauvin and his ensemble for a full hour. It went by in no time.

The Raiders reference made me laugh. That was way too accurate.

The sheer volume may be part of the problem too. With that much low-quality content around, you end up thinking, "Am I really supposed to stop and work out exactly what's wrong with every single one?" Still, I do think some visible feedback would be nice.

The problem isn't that people complain instead of flagging. The problem is that flagging provides no visible reason or feedback loop. That's what my own experience tells me.

Same here, actually. I'm more of a typer myself. Voice is only the beggining. Keyboards and mice exist because we've had to adapt to computers. Maybe the next step is for computers to adapt to us. I hope so.

I mean, we've spent 50+ years adapting to the machine. with an LLM in the middle, we can just say what we want and let it do the adapting.

For me, Ai has been useful for getting side projects I'd been meaning to publish for ages over the finish line. Probably not onthe scale you mean, though.

Yeah, same here.When I had AI test the code, the compiler catching its mistakes helped it keep going on its own and produce more robust code faster. Just my impression, thought.

Maybe the first step is getting rid of the keyboard.

Hi HN,

Why did I make this?

I had been using Typeless for voice input on Android. But it did not even have simple buttons for moving the cursor left and right. And if you want to use it a lot, you need a paid plan, which is not cheap. I was not happy with that.

OpenAI’s transcription API provides low enough latency for this kind of voice input, and it can be used at a very low cost compared with many existing voice-input applications.

So I thought: why not make something for myself first?

And I did. That became KoIME.

KoIME is BYOK, and I operate no backend server. More importantly, it was just the right size of project for learning and experimenting with the IME internals of an Android application.

The STT engine is separated behind a small interface, so I hope people will fork the project and experiment with it themselves. For example, you could insert an LLM layer that rewrites the transcription for a particular domain. That kind of modification is exactly what I would like people to try.

The name KoIME also contains a small Japanese joke.

The Japanese word for “voice” is koe, written 声. A voice IME can therefore be described as a “Koe IME,” which I shortened to KoIME.

But KoIME also sounds like the Japanese word 濃いめ, meaning something like “a little stronger” or “richer.”

The design philosophy has become rather concentrated too, so I think the name fits. :)

My impression from the `.smolmachine` single-binary packaging is that it could have a massive impact on next-gen edge computing and distributed serverless infrastructure.

To me, it feels like it could fulfill WASM's promise of a "portable execution unit that runs instantly anywhere," but with the added benefit of keeping the existing Linux binary ecosystem intact via microVMs.

I'm curious—is this kind of use case aligned with the direction you're aiming for?