HackerTrans
トップ新着トレンドコメント過去質問紹介求人

graphitout

no profile record

投稿

Show HN: Vilberta: speech to speech/text chatbot

github.com
1 ポイント·投稿者 graphitout·5 か月前·2 コメント

Show HN: Vibe coded React based flashcard app

github.com
3 ポイント·投稿者 graphitout·5 か月前·0 コメント

コメント

graphitout
·3 か月前·議論
For a chatbot like claude code, since the instruction prompt part (including descriptions of tools) is relatively constant for multiple users and over a long time, a lot of optimizations can be made. Even basic prompt caching gives a lot of speed and cost reduction.
graphitout
·5 か月前·議論
We are not there yet. A bit too optimistic for today. May be in 1 year.

I added types to a python codebase (50k) using claude code and it still took some effort to make mypy happy.
graphitout
·5 か月前·議論
Very nice. Just the thing I was looking for.
graphitout
·5 か月前·議論
Yes. Most of the MCP based search lookup now happens over the text stage.

voicevoyage.io looks interesting. Will keep an eye.
graphitout
·5 か月前·議論
Quite funny to see that coming from OpenAI. Nevertheless, how can they prove that?
graphitout
·5 か月前·議論
What is the strategy to deal with pay-as-you-go services used in vibe coded apps? I am always worried about the risk of some bad loop consuming thousands of dollars in a day.
graphitout
·5 か月前·議論
Very interesting. The moment I saw the repo I looked for a python reference implementation and found:

https://github.com/antirez/voxtral.c/blob/main/python_simple...

Thanks a lot! Let me see if I can get it to work with pure numpy while keeping the input audio part streaming.
graphitout
·5 か月前·議論
Claude gave me $50 yesterday with the release of opus4.6 and I burned my session quota + $30 yesterday itself. The code changes were very reasonable.

It is good for handling all code changes where there are no security aspects involved.
graphitout
·5 か月前·議論
The RAG was setup on a bunch of documents, most of them were manuals containing steps about measurements, troubleshooting, and replacing components of industrial machines.

The issue was that most of these steps were long (above 512 tokens). So the typical chunk window wouldn't capture the full steps. We added a tool calling capability by which LLM can request nearby chunks of a given chunk. This worked well in practice, but burned more $$.
graphitout
·5 か月前·議論
I do not follow. Could you clarify please? Who is going to fund and what is the criteria they are using?
graphitout
·5 か月前·議論
optimal chunk size is strongly query-dependent - very true.

Faced similar issues. Ended up adding a agentic tool call layer on the top to retrieve the nearby chunks to handle a case where a relevant answer was only partially available in a chunk (like a 7 step instruction in which only 4 were available in a chunk). It worked ok.
graphitout
·5 か月前·議論
Nice visualization. Would be nice to also see state variables (like stack or queue) along with the graph.