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.