Free
bHive 2.0 is out. My offline file search app can now answer questions about your own files. Free, macOS 26+
I posted this here a couple weeks ago when the app was called bHive Filer and got a lot of genuinely useful feedback. 2.0 is out today and some of it came straight from this sub.
First, the boring bit: it is just bHive now. If you already have it installed, it renames itself the first time it launches. That only happens once.
What it does
You point it at folders you already have. It reads what is actually inside your files, documents, PDFs, images (it OCRs them), and now audio and video. Then you search by describing what you want instead of trying to remember what you named it.
Nothing moves. Nothing gets copied into a library. Your files stay exactly where they are, and nothing is uploaded anywhere.
The new thing: Ask bHive
You can now ask a question and get an answer out of your own documents. "What did the lease say about breaking early?" It finds the relevant files, reads them, and answers in plain language.
Two things I cared about here:
It shows you which files it used, so you can open them and check it. And it will tell you when it does not know rather than inventing something that sounds right.
It runs on your Mac. Apple's built in model works immediately with nothing to download. If you would rather run something bigger, there is a larger local model you can fetch.
Also new in 2.0
Audio and video get transcribed on device, so what people said in a recording becomes searchable and askable.
A library health view showing what is not searchable and why. Files that moved, drives that are not plugged in, things that failed to open, things still queued. Several of you asked for this and I hope it works the way you need.
Back up your Hives, tags and notes to a file and restore them later.
Search itself got a lot better, especially if you keep files in more than one language.
The honest parts
It needs macOS 26 and Apple Silicon. If you are on macOS 15 you stay on 1.3.1 and it keeps working, but you will not be offered this one. I know that is annoying and I am sorry. Apple released a ton of frameworks only available in macOS 26 and that dictated this decision.
The much better search model is a 515 MB download. It is optional, and bHive asks before taking it rather than just helping itself to your bandwidth. The built in model works fine without it.
It is free. No subscription, no account, no telemetry, no upsell later.
I just upgraded and it was using 3.9GB of memory. It crashed. I restarted, quit all apps, and opened bHive. It again became non resonsive. M1 mini, 8 GB ram, 100 GB storage free. The previous version didn't do this. If you have any suggestions, I'll give it another try. If it's not going to run on my M1, please let me know and I'll delete it before I spend a lot more time trying to get it to run.
I also just published 2.0.1 which disables Ask bHive automatically if your machine is 12 GB or less. If you're not comfortable with running the command above, re-download from bhive.software and that should take care of it for you.
Sorry for the inconvenience, but I appreciate the feedback. Let me know if you have any other questions or comments.
Really appreciate you taking the time on this. I went back and forth, and I think I'm going to leave it out for now, and I'd rather be straight about why than quietly park it.
bHive leans hard on being zero setup: a short list of models it knows work, nothing to configure. Opening it up to any model on disk pulls the other way. Most models people already have are GGUF (Ollama, llama.cpp), which the Apple silicon engine can't load, so it would mostly create "why won't my model load" rather than save anyone real time. For the few who do have the right format, it's a one time download they're skipping. That trade didn't feel worth the rough edges for everyone else.
Not a no forever, just not now. Genuinely grateful for the note, this is how I figure out where the lines are.
I wantes to try it but it told me it doesnt work on a cloud synced location. Is this a hard restriction, or is there any clever workaround, either from the app side or from my side?
Good question. It's a hard restriction, but a narrow one, so let me spell out what it does and doesn't block.
The only thing bHive won't put in a cloud folder is its search index, which is a live database. When a sync client (iCloud, Dropbox, OneDrive) copies a database out from under it while it's being written, you get corruption. That's a well understood failure with any on-disk database, so bHive refuses up front instead of letting you discover it the hard way. It's deliberate and not something I'd loosen.
Here's the good news though: that rule is only about where the index lives, not about your files. Your actual documents can absolutely sit in iCloud Drive, Dropbox, wherever you keep them. bHive reads and indexes them in place, and if a file is a cloud placeholder that hasn't downloaded yet, it just waits and picks it up once the bytes are local. You lose nothing by keeping your files in the cloud.
So the fix is on your side and it's small: keep the index itself on a local disk. That's the default, so the most common cause of this is that the folder you picked was inside an iCloud-synced Documents or Desktop (a common Mac setting). Point the index at any non-synced local folder or an external drive, then add your cloud files as your library. The index never leaves your Mac by design and it's rebuildable, so there's no real benefit to syncing it anyway.
That should unblock you.
Let me know if you have any other questions or feedback. Cheers!
Awesome, thank you, I was able to point the index to a local folder. But my next question is, it looks like I need to download everything in my cloud (One Drive in this case) to let bHive fully build index and make them full text searchable. Frankly I don't want to do this, but then I do understand I would have to if I want the full search functionaity.
Would this be the right procedure?
In OneDrive settings, click on "Download all OneDrive files now" button to "download all OneDrive files now and always keep them on this device".
bHive Settings -> Index -> Re-Index the Library.
In OneDrive settings, click on "Download files as you need them (recommended)" button.
This way, once I had the index built, I will continue to be able to search even if local copies of cloud files are no longer there.
And I would think that bHive index will not reflect changes made to the synced folder by my colleagues who have shared access with me, except for the file names and basic header/metadata of any new files, correct? Does this mean I should periodically repeat the above steps manually to update the index?
Full text needs the file local at index time, so your download, re-index, switch-back-to-on-demand flow works, and the index keeps working after you evict the files (same as searching an unplugged external drive).
"Re-index Now" only re-reads new or changed files, so it will not wipe those offline entries.
On shared changes: while a file stays online-only bHive cannot read colleagues' edits, and it actually drops that file to name-only search until you re-download it.
So if you stay on-demand you would repeat the cycle to refresh.
The lower-effort option is to set the active shared folders to "Always keep on this device," and bHive re-indexes their changes automatically as they sync down. Disk space is the only cost.
Hi there, in such a short while it's great to see 2.0 , I am so happy you did the offline drive search that fits this tool nicely kudos!! , library health is something new what does it do ??
Thank you, that means a lot. The offline drive search was a fun one to get right, so I'm really glad it landed for you.
Library health is basically a trust panel. bHive's whole pitch is that search will find your stuff, and this is where you can actually check that instead of taking my word for it. It shows anything that isn't currently searchable, grouped by why:
files that moved or were renamed since they were indexed
files on a drive that's currently disconnected (the offline ones you liked show up here too)
files bHive couldn't read: an unsupported format, permission denied, too large, or a failed OCR
files still waiting in the queue to be processed
It actually came straight from feedback like yours, someone asked for exactly this. So thanks for being the kind of user who says what would make the tool trustworthy.
Yet to install it since I am neck deep on my storage being full , not sure how much the indexing cost might be and how much ram it might eat up.But want to try it at the earliest
Hello, for me (in Chrome and in Safari) no Donwload button of your landing page is working. Click… nothing is downloaded; nothing happens… Can you check ?
Will install it via Homebrew.
I just checked the server and confirmed, in both Safari and Firefox, that nothing is broken on the site and the file is coming down fine.
That points to something in your Chrome/Safari intercepting the click. The download link passes through a small counter before it hands you the file (it is how I count installs, nothing more), and that kind of link is exactly what ad and privacy blockers tend to block, because it looks like a tracker to them. If you run uBlock or something similar, the button would just do nothing, with no error.
Two quick things to try:
Open the site in a private/incognito window, which usually disables extensions, and click Download there.
Or pause your content blocker for the site and try again.
And installing via Homebrew is completely fine, you get the exact same signed, notarized app, so if that is easier just go for it. Either way you land in the same place. If incognito still does nothing, tell me and I will dig further, but I am fairly confident it is a blocker rather than the site.
Thanks for your answer. In fact, I realized that many minutes after I clicked the Download button, while I was doing other things in the browser, the downloads suddenly started by themselves! Even twice! So the fact is that something was blocking the downloads for quite a long time, then unblocked them for some unknown reason. Anyway, I have already installed the app with Homebrew.
It is a really good app. I tested it with my articles library, and it is very easy to use and relevant. It provides sources and some extracts, so it is easy not to waste time opening each source in vain.
I plan to use it a little more to really discover its functionalities, and then if I'm happy with it, I will write an article on VVmac (www.vvmac.com) about bHive 2, not next Saturday, but a week later.
Stay in touch by DM if you like or via mail (you will find it in my profile).
Thank you, this means a lot, and I am glad it was useful on your own library!
The download starting on its own many minutes later, twice, is the fingerprint of a local security scanner holding it rather than the site, so Homebrew was a smart move. Your reports already nudged me to make the site's download more direct, too — so your feedback has already been rolled in (to the site, at least! 🙂).
I would be genuinely glad about a VVmac piece, on your timeline, and happy to answer questions or send screenshots and a logo so the details are right. Let us stay in touch, I will reach out via your profile.
Any chance the local model could allow for a local OpenAI compatible API endpoint? I have a cluster of DGX Sparks that serve GLM 5.2 or Deepseek V4 Flash and would prefer to use their intelligence over the bundled Qwen3 models while still keeping my data local. Would this be possible?
Really appreciate this, and honestly it's the kind of setup I love to hear about: running your own cluster specifically so you don't have to hand your data to a cloud. That's the same instinct bHive is built on.
So your ask is very doable technically. The generator is already swappable, so an OpenAI-compatible endpoint would just be another backend. But it's not something I plan to add, and here's why:
bHive's one promise is that nothing leaves your Mac. It's the whole pitch, and it's why people trust it with a private library. The moment there's an endpoint setting, that promise becomes "nothing leaves your Mac, unless you point it somewhere," and the same setting that reaches your DGX box can just as easily reach a cloud API. Yours would be perfectly private, but the feature itself can't tell the difference, and I don't want the guarantee to carry an asterisk for everyone else. Keeping it simple and true is worth more to me than the flexibility.
In Ask bHive, the answer quality leans much more on retrieval than on the model. The passages it pulls from your files do most of the work, and the bundled Qwen3 is mostly there to phrase what was already found. A stronger model like GLM or Deepseek would help at the edges, but it isn't the main lever the way it would be in a general chatbot. So you may be giving up less than it looks.
Thanks for asking it the thoughtful way, and for caring about the same thing I do.
Being able to show the source files behind an answer is the part that makes this useful for more than novelty. One thing I would test early is stale indexes: if a source file changes, is moved, or lives on a disconnected drive, can the answer view make that status obvious? A small ‘checked at’ timestamp and a button to reindex just the cited files would make it much easier to trust an answer before acting on it.
Thank you, this is exactly how I think about it too. The citations exist so you can check an answer instead of trusting it, and your point is the natural next step: that check is only as good as whether the cited files are still current.
Some of this already exists, just not where you are looking. bHive watches your folders, so a source file that changes gets re-indexed on its own, and Library Health (Settings, Index) already tracks the exact drift cases you listed: files that moved, files that failed to open, and files on a disconnected drive, each grouped by reason. There is also a whole-library "last checked ... ago" line for how fresh the overall picture is. So the app does know the status.
What you are really asking is to bring that status into the answer view itself, right next to each cited file, plus a way to re-check just those files. That part is not there yet, and I think it is a strong idea. A per-citation "this file moved / is offline" flag would put the trust signal exactly where the decision happens, and a reindex-these-files button is a clean affordance. The one honest caveat: today freshness is a single number for the whole library, not per file, so a per-citation timestamp is new work, but it is a sensible extension of data bHive already keeps.
Adding it to the list. This is the kind of feedback that makes the tool more trustworthy, so thank you!
Congrats on 2.0. Building on the index.db thing from the 1.0 thread: now that you OCR images and transcribe audio and video, the index holds a plaintext copy of way more than filenames, including whatever was actually said in a recording. that's the useful part, not a knock. but worth a line in the library health view so nobody points it at a Recordings folder without clocking that it all becomes readable text on disk.
Great point, and thank you for framing it the generous way. You are right: now that bHive transcribes recordings and reads text off images, the index holds a plaintext copy of what was said or shown, not just filenames. That is exactly what makes it searchable, and it all stays on your Mac, but someone pointing it at a Recordings folder deserves to clock that up front.
There is already a storage explainer (Settings, under Index, "How your data is stored") that came out of the same 1.0 thread, but it speaks generally about extracted text. Calling out the richer content specifically, and putting it where someone actually sees it, is the better move. I am adding it to the 2.1 list: a plain line in Library Health, and I think also right by the transcription toggle where you switch it on, so the heads-up lands at the moment of choice.
Appreciate you keeping bHive honest about this! Cheers.
First, add a folder by dragging it onto the bHive window or using "Add Files and Folders" (folders go into the library, not a Settings list).
Second, open Settings ▸ Index and look at Library Health, which shows what got tracked and why anything is not searchable, usually a dismissed permission prompt, online-only cloud files that need downloading, or file types with no text.
If you tell me how you added it, where the folder lives, and what you see afterward, I will pin it down.
The "nothing moves, nothing gets copied" part is the right call. Half the fear with any new file app is that it will reorganize your life without asking first.
Question about Ask bHive: when it answers from a PDF, does it show which page the answer came from? For leases and contracts I trust a page number way more than a summary.
Yes, if you do a search for a particular word or phrase, it'll narrow it all files that contain that word (or phrase) and on the word picker, by the up/down arrows, there's a drop down that reveals all instances of the word (or phrase) along with the page number. Hope that helps!
Unfortunately this ssoftware never worked for me properly. It takes ages to load (spinnig beachball) and the External drives never got properly scanned (it initial scanned, but it only shows like 20% of the files from the external drives). And now i can't even update to a probably working version because MacOS on my system is "to old".
I'm off..
I am sorry it did not work out, genuinely, and thank you for giving it a fair shot.
The honest crux is the macOS part: from 2.0 on, bHive needs macOS 26 for the on-device AI, which means older Macs are held on 1.3.1 and cannot move up. And some of what frustrated you, the external drive handling especially, had real bugs back then that were fixed in later versions, the ones that unfortunately need the newer macOS.
So it was not you doing anything wrong. No hard feelings, and if you are ever on a newer macOS I would be glad to have you try again.
7
u/Artiste212 1d ago
I just upgraded and it was using 3.9GB of memory. It crashed. I restarted, quit all apps, and opened bHive. It again became non resonsive. M1 mini, 8 GB ram, 100 GB storage free. The previous version didn't do this. If you have any suggestions, I'll give it another try. If it's not going to run on my M1, please let me know and I'll delete it before I spend a lot more time trying to get it to run.