z64

Transparently, what we have been discussing is to offer our keystone products (search, assistant, translate, email, ...) as standalone items. Then we will offer a all-in-one Kagi bundle that has everything under one payment.

The reason for this boils down to the following observations:

- Cost of operation at scale varies wildly between these, making it complicated to operate and manage cash flow

- Complexity for the consumer gets unruly as arbitrary things are limited to our fixed brackets of standard/pro/ultimate, we'll need some crazy matrix to explain what is included in each one

- Apprehension in our customer base about paying for things they don't want, chiefly AI related features. Some people just want search and don't want to pay for anything else, even if its included for free.

Itemizing our ecosystem addresses each of these by letting people pay for what they want, and ignore what they don't. If you want Kagi mail, you just get Kagi mail - there is no gymnastics of "I want Kagi mail, but I need extra storage so I need ultimate, but I don't need Assistant stuff, ...". From a business POV it will cleanly fund each initiative without everything competing for the same $10.

This is still on the whiteboard and not set in stone - so don't take what I'm saying as gospel - but it is generally where our heads are at in terms of managing the complexity of our offerings, cost of operation, and consumer piece of mind. It's a very difficult problem to navigate!

Edit: I mention Kagi Mail here, some people may not know but it is in a closed-ish beta at the moment - we hope to bring it to market by EOY!

Our $10 search sub price is solely based off of the cost of operating search and has remained unchanged for years (est. 2023), before we offered any LLM-based features as part of our plans.

We added AI features to the existing plans at no extra charge. The only thing we preempted was our Ultimate plan (which we initially offered with literally zero extra perks!), anticipating that LLMs would become more capable and popular and require a higher margin to operate at scale.

https://blog.kagi.com/unlimited-searches-for-10

I'm working on making an internal proposal to integrate with Gemini on several fronts, yes. Still hatching the idea, and much else to do - maybe this summer it will come to fruition if it pans out :)

I don't think we would go to that end, not as a first step anyways; I'm thinking of some simpler ones. Sparing details as I'm just brainstorming for now and getting to know their communities.

But, there are already plenty of services that proxy Gemini pages so that you can read them in conventional browsers, as well as search engines for Gemini content.

I've been tossing around the very early idea of seeing what we can do to elevate alcoves of the web such as Gemini[1] through Kagi. I am slightly conscious of that some people might not like us operating in that space, it's been on my TODO to poll people about it and take a quick pulse. I love the tech and think we could give it meaningful exposure.

Is this along the lines of what you have in mind - any other active efforts you're aware of that you think we should look into?

[1] https://en.wikipedia.org/wiki/Gemini_(protocol)

There is a practical limit that we can't cache results for too long; Search engine users are particularly sensitive to stale data, especially around current events. Without a holistic and realiable way to know when the cache ought to be invalidated, our caching is mostly focused on mitigating "abuse", e.g., someone / bunch of people spamming the same search in a short timespan; no sense in repeating all those upstream calls.

Most "cost saving engineering" is involved in finding cases/hueristics where we only need to use a subset of sources and omitting calls in the first place, without compromising quality. For example, we probably don't need to fire all of our sources to service a query like "youtube" or "facebook".

Marginalia data is physically consolidated into the same infra that we use for small web results in our SERP, but also among other small scale sources besides those two. That line is simply referring directly to https://kagi.com/smallweb (https://github.com/kagisearch/smallweb).

Thank you!

We have about 50 employees distributed across NA, EU, and Asia; maybe about 10 of us are in the US/Canada? 4 of them are actually local to Belgrade and use the Hub regularly, and see occasional visits from the rest of the company - we all meet up 2-3 times a year.

It's also a space that our founder has already been leasing for the better part of 10 years(?), long before Kagi was even a thing. As others have pointed out, this is Serbia, not SF - it's very cheap in relative.

So in perspective,

- a handful of our team just got a nice office for daily use together in person

- it is a "home base" that others in Kagi can freely use as they travel; we're already planning some "jams" to host there in 2026 to get major features over the line in person :)

- our community can engage with us there as well, we love our customers! online engagement is a very suffocated and transactional space

- it really isn't that expensive

It's all net positive to us in terms of investment in our own people and the community.

Trust with regards to...? Orion doesn't have any telemetry, doesn't force any updates on you, doesn't require any account. You can audit the application's behavior with standard tools to verify that it isn't "phoning home", etc., it doesn't need to be open source to do that, nor would making it open source obviate auditig the final executable anyways.

What do you perceive as the risk to "trusting" Orion in this case?

edit: Sandboxing the app also further reduces the surface area for "trust", though I'm unfamiliar with MacOS as a platform when it comes to that.

(I work at Kagi, but do not work on Orion)

There's a lot of different reasons that people ask for open sourcing of Orion / software in general; could I ask you to expand a bit more as to which issues being open source would address for you?

I can assume of course, but I'd rather listen to you articulate it, even if it's usual reasons.

We would like to eventually offer everyone an API credit stipend with their subscription. Our APIs should get plenty of love this year, so please stay tuned.

> also they blocked my vpn's another big nono

Argh, I am sorry to hear that. We do not block _any_ VPN, but have been struggling with our hosting provider (GCP) to not do this. We are working with GCP support on this - if you give us a chance, and encounter any issues, please reach out to [email protected] with details and we will see what we can do.

Also, see my other comment in this thread about Tor, if that is helpful for you.

I would say there are three major factors:

1. We have a diverse set of upstream sources. It would require all of them to be "compromised" for our results to completely tank.

2. We have a "crawler-lite" that solely collects info on page quality - number of ads/trackers detected, page speed, etc. - and we take that into account when ranking the results, generally nudging them down the page if "cleaner" ones can be found.

3. Our sole source of income is our users, and we actively respond to impacts in search quality that our users submit to us on our feedback form. If they are not happy with the results quality, then we are out of business.

Put simply: Our technology and business model is completely aligned to resist "enshittification". We have no reason to bias results or "sell out" to anyone.

With the momentum we've gathered, we are also taking first steps to building our own full scale index[1], both as a valuable contribution to the ecosystem of search and a contingency to reduce our reliance on 3rd parties.

[1]: Help us build it! https://help.kagi.com/kagi/company/hiring-kagi.html

It just uses Stripe credit under the hood. So as long as you still have an account registered with us (active subscription or not), you can use that credit to resubscribe any time - or use it on other things, like API credits, or gift codes.

Always happy to hear people finding us through HMS! It's a fantastic community, and the Handmade ethos resonates deeply with a lot of us on the team.

Thank you for your support.

- Zac

Heya, this is Zac from Kagi.

We do not block Tor - in fact, we recently launched our own self-hosted Tor node[1].

We have had problems with GCP blocking VPN and Tor traffic (mostly the former) when we have made zero configuration to do so. It's quite frustrating, and we have been working with their support to improve this generally.

Haven't heard anyone having issues with Tor since we set up the node though :) If you give it a try, let us know how it works for you.

[1] https://help.kagi.com/kagi/getting-started/accessing-via-tor...

Hi Yunwal, I work at Kagi.

> No markdown blocks for code makes assistants really tough to use.

Could you clarify if you are referring to the markdown from your prompt not rendering? Or the response from the model not rendering markdown for code blocks?

The former was an intentional choice for now to simplify release; it is on our roadmap. The latter would be a bug - in which case, you can email the thread URL to [email protected] and I'd be happy to take a closer look.

Very kind, thank you! (and everyone else too, many heartwarming replies)

Very cool! The deluge of cloud solutions are absolutely one of those things that can be a distraction from figuring out "What do I actually need the computer to do?".

Internally I try to promote solutions with the fewest moving cloud-parts, and channel the quiet wisdom of those running services way larger than ours with something like an sqlite3 file that they rsync... I know they're out there. Not to downplay the feats of engineering of huge distributed solutions, but sometimes things can be that simple!

Hi there, this is Zac from Kagi. I just posted some other details here that might be of interest:

https://news.ycombinator.com/item?id=39019936

TL;DR - we are a tiny, young team at the center, and everyone has a closet full of hats they wear. No dedicated SRE team yet.

> "what happens if a ton of searches happen?"

In fairness, you can checkout https://kagi.com/stats - "a lot of searches" is already happening, approaching 400k per day, and systems still operate with plenty of capacity day-to-day, in addition to some auto-scaling measures.

The devil is in the details of some users exploting a pathological case. Our lack of experience (now rightfully gained) is knowing what organic or pathological traffic we could have predicted and simulated ahead of time.

Load-simulating 20,000 users searching concurrently sounds like it would have been a sound experiment early on, and we did do some things resembling this. But considering this incident, it still would not have caught this issue. We have also had maybe 10 people run security scanners on our production services at this point that generated more traffic than this incident.

It is extremely difficult to balance this kind of development when we also have features to build, and clearly we could do with more of it! As mentioned in my other post, we are looking to expand the team in the near term so that we are not spread so thin on these sorts of efforts.

There is a lot that could be said in hindsight, but I hope that is a bit more transparent WRT how we ended up here.

Hi there, I'm Zac, Kagi's tech lead / author of the post-mortem etc.

This has 100% been a learning experience for us, but I can provide some finer context re: observability.

Kagi is a small team. The number of staff we have capable of responding to an event like this is essentially 3 people, seated across 3 timezones. For myself and my right-hand dev, this is actually our very first step in our web careers - this is to say that we are not some SV vets who have seen it all already. To say that we have a lot to learn is a given, from building Kagi from nothing though, I am proud of how far we've come & where we're going.

Observability is something we started taking more seriously in the past 6 months or so. We have tons of dashboards now, and alerts that go right to our company chat channels and ping relevant people. And as the primary owner of our DB, GCP's query insights are a godsend. During the incident both our monitoring went off, as well as query insights showing the "culprit" query - but, we could have monitoring in the world, and still lack the experience to interpret it and understand what the root cause is or most efficient action to mitigate is.

In other words, we don't have the wisdom yet to not be "gaslit" by our own systems if we're not careful. Only in hindsight can I say that GCP's query insights was 100% on the money, and not some bug in application space.

All said, our growth has enabled us to expand our team quite a bit now. We have had SRE consultations before, and intend to bring on more full or part-time support to help keep things moving forward.