Buoy

The next two languages are Go and Ruby as it happens! We need to make some changes based on learnings from the launch today first but it’s relatively easy for us to implement these new languages

Thanks! It’s much harder to implement that’s for sure but I totally agree that it’s a great way to interact, being able to and follow up messages and clarify things is really great

Thanks for flagging - will get this fixed! For reference the paper is here: https://arxiv.org/abs/2212.10496

Thank you very much! Released an article yesterday on my tips for the ChatGPT API if you haven’t already seen it!

Not currently, I think jetbrains is definitely next in terms of priority but I think as per some suggestions on here and on Twitter we may end up releasing our headless API to allow people to build their own integrations - need to hire some more devs first though!

I’ve heard a few reports of slow indexing, it may be load related but I need to investigate further (on a flight currently so will look when I land), if you’re happy to drop me a line on [email protected] and I’ll try to help figure this out!

Yes we’ve definitely considered this as an option, we’ll hopefully be able to explore it more when we have more dev resource in the next few months (just my cofounder and I working on the tech currently). I think it makes a lot of sense to allow people to make their own integrations!

This may be load related - very happy to provide support on your issue if you can drop me a line at [email protected]

Interesting suggestion, the extension itself is actually a React project that runs in VS Code so not much uplift would be required but we’d have to figure out how we’d actually interact with the codebase in that instance

Hey, thank you for the feedback - are you unable to get beyond the sign in point? If you could drop me a line on [email protected] I’ll gladly try to sort this out for you!

Yes we do in the medium term, we fortunately built the product in a modular/headless way so adding further integrations is easier, although we're strapped for dev resource currently so once that problem is alleviated then we can start looking at supporting more IDEs!

No the public API is limited to 4k tokens for the time being, although it seems that a longer context window version is in the works

I'd suggest you try on 10k examples or more (variety is key ofc) and see how you get on!

Glad to know that's what it's called! For avoidance of any doubt I'm not trying to claim I 'discovered' any of this - just wanted to share some useful learnings :D

We've had some demand for this, if there's enough we'll definitely consider it when we hire more engineering resource, which is the current constraining factor

Yes definitely give this a go, for us with our use case davinci is prohibitively expensive in production so we literally cannot use it given the number of requests we make - interestingly I saw some OpenAI documentation the other day at the YC event which basically said that with a large enough dataset (I recall >= 30k examples) all of the models (yes even ada) start to behave with similar performance, so bear that in mind!

Thanks - we used to use a bunch of k-shot prompts (particularly with our previous idea before we pivoted when we got into YC), but with the davinci model we were sending ~3.5k tokens per invocation, which in the long term was costing far more than finetuning!

Definitely give them a go, we use fine-tuned ada a bunch for classification work for example; I personally think the smaller models are overlooked and don't get enough love - if OpenAI increased the context window of a model like babbage to 8k tokens I feel like that would be as much of a big deal as making a marginal improvement to davinci, purely because so many use cases rely on low-latency, many request models.

Yep, that was the aim, I'm just trying to put some stuff out there that helped us out!

Embeddings have been the talk of the town, but their stock implementation can be made better very easily.