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?
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).
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.
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.
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.
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.
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.
> 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 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!
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.