| ▲ | smallerize 5 hours ago | |||||||||||||
That's true, but it makes it difficult to compare pricing when it's based on tokens. Maybe we need a benchmark for price per a specific input, like enwiki8. | ||||||||||||||
| ▲ | leecommamichael 5 hours ago | parent | next [-] | |||||||||||||
Yes, almost all work people share which seeks to measure the capabilities and differences of models needs to get more precise. We are clamoring to say something meaningful about these things. | ||||||||||||||
| ▲ | kevincox 2 hours ago | parent | prev | next [-] | |||||||||||||
But even that isn't the whole story because the models can produce wildly amount of thinking output as well as regular output for a similar query. Sometimes you can take a cheap model and have it think a ton or an expensive model that thinks little and get similar results. But the number of tokens generated will be wildly different. | ||||||||||||||
| ▲ | whodatbo1 4 hours ago | parent | prev | next [-] | |||||||||||||
A better metric is price per byte. Most thinking traces, prompts, skills are in plain English, which is roughly 1 byte per character, assuming UTF-8 encoding (even code should not be much more either). As an aside, it is common to use bits-per-byte as a loss metric instead of the per token calculation, precisely because of the effect of different tokenizers. | ||||||||||||||
| ||||||||||||||
| ▲ | victorbjorklund 4 hours ago | parent | prev [-] | |||||||||||||
It is kind of a shame we ended up comparing token pricing across models and providers when it doesn’t really make sense. Not sure what would be better though. | ||||||||||||||
| ||||||||||||||