billycao

There are only 16 direct dependencies, and they all look pretty reasonable to me.

Have you worked with any Node.js projects before? I'd actually say this is a relatively sparse list of dependencies for a user-facing tool.

Thanks a bunch! For launch/beta, we're paying for the GPU time ourselves. :) Quoting Matt below:

"We weren't really sure how to price it, so we're using the beta period for now to figure out what mix of models people are using and trying to figure out reasonable pricing based on that, and also ironing out various bugs and sharp edges. Then we'll start charging for it; personally I'd prefer to have it be usage-based pricing rather than the monthly subscriptions that ChatGPT and Claude use, so that you can treat it more like API access for those companies and don't have to worry about message caps."

Open to feedback here! :)

- Billy

Appreciate the feedback! We currently use fly.io as our cloud GPU provider, but we're actively investigating other providers due to various limitations (like NVLink support).

Borrowing Matt's words from our reddit thread:

It means that we can spin up a single model server and use it for multiple people, effectively splitting the cost. Whereas if you try to rent the GPUs yourself on something like Runpod, you'll end up paying much more since you're the only person using the model.

- Billy

Might have been a transient error as we were deploying some auth provider fixes. Should be good to go now! :) - Billy

This is now fixed, and signups should be working again! Had a misconfiguration with our auth provider, even though we were on the paid plan.

Thanks for testing! :)

- Billy

Whoops! We had a hiccup with our auth provider and have just pushed the fix.

Sign up should be working again! Thanks for testing! :)

- Billy

Thanks for the feedback!

We're working on fleshing out ToS, privacy policy, and company specifics, but just to answer your first question, I'm Billy Cao, an ex-Google eng, and Matt Baker is ex-Airbnb, ex-Meta.

Re: concerns, our infra will scale relatively well (several qps per model, probably), but we're still in the stages of fleshing things out and getting feedback. :)

Feel free to drop us a line at hi@glhf.chat if you wanted to chat specifics!

- Billy

Hey there!

We currently use vllm under the hood and vllm doesn't support Codestral (yet). We're working on expanding our model support. Hence (almost) any model.

Thanks for testing! :)

https://github.com/vllm-project/vllm/issues/6479

- Billy :)

2nd dev Billy here.

Great point. Right now we don't log or store any chat messages for the API (only what models people are choosing to run). We do store messages for the web UI chat history and only share it with inference providers (currently together.ai) per request for popular models, but I know some hand-waved details from an HN comment doesn't suffice.

We'll get on that ASAP. :)

Hey there! I'm Billy, the other dev working on glhf.chat :)

We do have API support! We expose an OpenAI compatible API. You can see details when logged in at https://glhf.chat/users/settings/api

Just like our web UI it supports feeding in any huggingface user/repo.

(Also available via the user menu)

Let us know if you have any questions/feedback!

I might subscribe to the oft-repeated mantra to not fix what isn't broken, especially considering that users cannot view other users' calendars, so mediocrity or spam is not of a major concern to you.

That said, awesome app. It's certainly a problem I'm sure many are constantly faced with. (I know I am) My first impressions though include a lack of detailed info (how does it work?) compounded by the inconvenience of making an account for the site. (I still haven't registered)

Edit: As for a small change you can do right away, I feel like users would consider "John Doe" <jdoe@example.com> more intuitive than "Invite Name" <Invite Email>. (Consider making the name optional altogether or just having a more intuitive input method, like multiple <input> prompts)

It's interesting opening two tabs and only drawing on one, and using the second tab to see what other people are probably seeing.

Some strokes have huge lag during spikes, others that I made on my screen are never displayed on the other tab.

I agree, I highly doubt that the percentage of storage that is non-unique is enough to increase Dropbox's profit margins significantly.

I'm certain they use this and several other techniques such that each user reflects a far less impact on Dropbox's storage than the 50GB bought, but if that's printing money than Amazon would be a first world country by now.

I'm wondering, how do you strike a balance between having a long runway and not falling into a sense of well-funded sloppiness?

Many suggest that the lack of funds forces a startup to be lean and mean, but I can see how appropriating funds has the obvious benefit of allowing you to estimate and plan your risks better.