A huge number of people. In 2023 they made around $80 billion of profit on $300 billion of revenue. Their ad network, search engine (Google), web browser (Chrome), mobile OS (Android), videos website (YouTube) and email service (Gmail) are all either leaders in user numbers or close to being (actually I think they might be #1 in all of those categories...)
You either pay a flat fee, or you have to deal with the added baggage of considering that each search costs you a very real half a cent or whatever.
Would you use your search engine more if every search query were an implicit microtransaction? Would you use it more or less if you had to consider that your first search of the month cost $3, or if it's the last day of the month and you need to search for something but you have to wait to not incur a full month's fee.
This is one of those arguments that sounds reasonable but isn't. Nothing but a flat fee structure makes sense for something you'll be doing hundreds if not thousands of times a month. And let's be real: if you're the kind of person who could go a full month with no web searches, you don't want or need what Kagi is offering.
Almost everyone is paying for their electricity based on usage, and yet people don't seem to think "this will cost me a dollar" when turning on the washing machine (unless really short on money). I think usage-based SaaS subscriptions could make sense from user's perspective, they are just too uncommon right now.
> or you have to deal with the added baggage of considering that each search costs you a very real half a cent or whatever.
And one way to "deal with" that is get used to it and forget about it unless you get some surprise hit (which can be avoided with a cap). But you'll have a warm glow feel that it's "fair"
It's not like this is some novel issue average people have never had exposure to (eg, utilities)
I think you could bundle online search and LLM, offline (personsal) search and LLM and it would make 10-20 bucks a month attractive. Why just do internet search. Be my search for everything!
I think it should be free or cheaper for people who genuinely cant afford it to give the equity of access that Google does.
> replacement for Google that is to survive should really convince and be super cheap
The market for most is met with ads. It's why streaming services are adding ad tiers and JCPenney doing "away with constant sales and coupons, opting instead for everyday low prices" failed [1]. That's most consumers. It's almost all non-premium consumers. That's good fodder for Google and whatever LLM garbage replaces them.
Paraphrasing Scott Galloway, advertising is a tax on the stupid and the poor. I wish something like Kagi got public funding. But we have better priorities than taking ads out of search. So for the time being, you get one product for the wealthy and savvy and another, that's just good enough, for everyone else.
> If I make 0 searches, why do I need to pay?
Do you ever have months in which you don’t use a search engine at all? If so you might just not be the target audience.
Well yes but it's kinda crappy that you do. Can easily imagine an alternate reality where laws are more pro-consumer such that it's illegal to charge someone for a service in a month that they don't use it.
> Can easily imagine an alternate reality where laws are more pro-consumer such that it's illegal to charge someone for a service in a month that they don't use it
Didn't use my vacation home this month, skipping the mortgage payments!
The comparison with a house does not work, it relies on a misapplication of the word "use". In the context of a house, "use" refers to ownership. You receive the benefits (use) of ownership regardless of your presence. You basically pay for the inability for others to live on the property.
Can you please create a simple UX to connect to the database like username, password box etc. I just an error right now saying invalid dsn, but does not tell me what is wrong.
I've always said that the best ORM is one that allows for type safe query building.
This kind of generates the type safe queries for you, which is the end goal. But then why don't developers use the query builder instead? Why have an unnecessary generation step?
I feel like a good query builder ORM is more than enough and more straightforward than this. What am I missing?
A query builder ORM is an abstraction I don't want and don't need. I know which SQL queries I want to run on my DB; please don't make me learn a whole DSL in order to run them. All I get in exchange for that is the extra work of translating my SQL into your DSL, plus the headache of circumventing the inevitable leaks in your abstraction.
I just want type-safe SQL templates that return native data structures. Sqlc provides that, and I've quite enjoyed working with it.
I prefer just using SQL without the query builder. If I'm ever concerned about type safety, I could wrap it in a function. Guess this tool does it for you, but separating your queries into .sql files seems like more effort.
One of the design principles of sqlc is that SQL queries should be static in application code so that you know exactly what SQL is running on your database. It turns out you can get pretty far operating under this constraint, although there are some annoyances.
The query builder is yet another mini language that you have to learn and they change for each ORM so learning one is mostly wasted time.
Many times I’ve been stuck in a place where I knew exactly how to write the SQL for it but had to spend several minutes studying the ORM docs to learn how to express it.
SQLc also has the advantage of static checking your queries.
It has some other disadvantages so it’s not all rosy.
Last time I used a query builder, I accidentally used its orderBy in some invalid way that it didn't complain about. Just silently didn't ORDER BY the cols I wanted.
The SDK itself is open source, but you need an API for authentication, and another cool part is that it sends slack logs of the IP address and the payload of whoever tries to break the rate limting rule. Would you be interested in a 15 minute discussion on how it works? i could drop my calendar if you are interested?
You're being too kind if anything. Whilst trying to bash HTML emails into something acceptable I questioned if my life wouldn't better have been spent as a monk in Tibet.
On the info leaving your machine part, obviously since we're using OpenAI the table metadata will be sent to draft the SQL. But the conversations and messages and the stored results and everything stays local in an SQLite DB. No cloud or anything involved. With Local LLMs it will indeed be FULLY airtight.
We don't support local LLMs yet cause we want to ensure high quality results. We're only exposing models after we test them thoroughly (eval pipeline work nearly done now - less than a week left probs). So soon we'll be releasing more supported models, including local LLMs. But only if they're good enough/fast enough. Speed is one concern for local LLMs but you should see the quality - pretty meh right now. But haven't tested all of them so can't generalize yet. With the eval pipeline this will be much easier.
