logoalt Hacker News

danudey • yesterday at 10:14 PM • 2 replies • view on HN

I'm paying ten bucks a month and I don't want to be paying for an API I don't use. If the options are raise everyone's prices to cover the cost of the searches that an extreme minority of people want to use or ask those people to pay a little bit more for that extra functionality I think the second option makes the most sense.

You're paying ten bucks a month for access to Kagi the web search, not Kagi the search API. If you want them to provide that service and scale it accordingly it makes sense for that to be a separate feature with a separate price.


Replies

darkamaul • yesterday at 10:27 PM

You could argue that it also includes the assistant that I’m barely using at all… Why is this included in the sub while the main reason I use Kagi is the search, and the search itself is not included if performed via an agent?

➕ show 1 reply
MrJohz • yesterday at 11:02 PM

I mean, presumably at some level you are using the search API - it's just a programmatic interface into the same underlying database calls. I don't know if Kagi web search uses the public API directly or if they share an underlying internal API, but I imagine there's not a lot of difference on Kagi's end.

The big difference is that API usage can be scaled up way quicker than web page hits and scraping can be, which is an understandable concern if you're trying to price your service for human usage and not for bots hammering away as fast as they can. But judicious use of rate limits could help here - have a subscribers API tier that allows only a relatively low volume of calls and do standard API pricing for all requests beyond that.

That said, I'm sure there are complexities here that I'm missing that make this easier to say than to do.