jellyotsiro

tens of KBs (v small)

good point.

we’re using “framework” intentionally because it goes beyond argument parsing. crust handles parsing, but also:

type inference across args + flags end to end compile-time validation (so mistakes fail before runtime) plugin system with lifecycle hooks (help, version, autocomplete, etc.) composable modules (prompts, styling, validation, build tooling) auto-generates agent skills and modules from the CLI definitions

so it sits a layer above a traditional arg parser like yargs or commander, closer to something like oclif, but much lighter and bun-native.

thanks for flagging! the post itself works, just the link at the bottom

will fix in the next hour!

thanks for the catch, what we meant is that we’re not committing to strict stability guarantees yet, so APIs may still change as we iterate toward 1.0.

one of the examples would be trynia.ai (search and index api for ai agents)

here is github: github.com/nozomio-labs/nia-cli

sick

rag is not a core! we use both semantic search but combining with fts, grep, direct read, etc.

Open source models with minimal safety fine tuning or Grok

Thanks for testing this. The Bannon email from June 30, 2019 is in there (HOUSE_OVERSIGHT_029622). Good stress test idea.

Couple things happening:

Semantic search limitation: Less-famous names don't have strong embeddings, so it defaults to general connections rather than specific mentions Keyword search gap: You're right — raw grep can catch exact names I'm missing

yes! once for files come out, I will add them right away

Shareable conversations would definitely make the tool more useful yeah. I really like the query parameter approach over UUIDs so it would make links human-readable

On the limited dataset: Completely agree - the public files are a fraction of what exists and I should have mentioned that it is not all files but all publicly available ones. But that's exactly why making even this subset searchable matters. The bar right now is people manually ctrl+F-ing through PDFs or relying on secondhand claims. This at least lets anyone verify what is public.

On LLMs vs traditional NLP: I hear you, and I've seen similar issues with LLM hallucination on structured data. That's why the architecture here is hybrid:

- Traditional exact regex/grep search for names, dates, identifiers - Vector search for semantic queries - LLM orchestration layer that must cite sources and can't generate answers without grounding

sorry all publicly available files *

it uses semantic search so yes

ill take like 1 hour in the evening to dive deeper, i was never familiar with epstein stuff until i built the agent to simplify things for me.

Trump famously told New York Magazine in 2002: "I've known Jeff for 15 years. Terrific guy. He's a lot of fun to be with. It is even said that he likes beautiful women as much as I do, and many of them are on the younger side."

Trump and Epstein were social acquaintances in Palm Beach and New York circles during the 1990s-early 2000s. They socialized together at Mar-a-Lago and other venues

oh forgot about it, thanks. just a funny project i build in couple hours so didnt really sweat haha

thanks! yes writing docs is pain the ass haha

The economics are simple. When an agent guesses, it produces wrong code, failed runs, and wasted time. External context is the biggest source of those mistakes, because IDEs only index what’s in your repo. We are a complement to Cursor, ChatGPT, and Claude, not a replacement.

JetBrains is great at indexing your local codebase and understands it deeply. We don’t try to replace that. Nia focuses on external context: docs, packages, APIs and other remote sources that agents need but your IDE can’t index.

We’re not a coding tool. We’re the context layer for agents.

Not quite “better RAG for code”. The core idea is agentic discovery plus semantic search. Instead of static chunks pushed into context, the agent can dynamically traverse docs, follow links, grep for exact identifiers, and request only the relevant pieces on demand.

No manual chunking. We index with multiple strategies (hierarchical docs structure, symbol boundaries, semantic splitting) so the agent can jump into the right part without guessing chunk edges.

Context is selective. The agent retrieves minimal snippets and can fetch more iteratively as it reasons, rather than preloading large chunks. We benchmark this using exact match evaluations on real agent tasks: correctness, reduced hallucination, and fewer round trips.

We don’t store your code or any proprietary local content on our servers. When we say “external context” we mean public or user-approved remote sources like docs, packages or APIs. Those are indexed on our side. Your private project code stays local

hey, what error does it throw?

Nia is focused on external context rather than learning the patterns inside your own codebase. Cursor and IDE-native tools are better for local project structure today. Where Nia helps is when the agent needs ground truth from outside your repo. For example, you can index React Native docs, libraries you depend on, API references or Stack for your backend and let the agent search and validate against those sources directly instead of losing context between prompts.

going to open source it soon :)

yeah, their mcp is to provide better context of your own codebase. not external information.

thanks! will be waiting for ur feedback

Serena is great for semantic code editing and symbol-level retrieval on your own codebase. It gives the agent IDE-like capabilities inside the repo. Nia focuses on a different layer. We target external context: remote code, docs, packages, APIs, research, enterprise knowledge, etc

w nia the agent can dynamically search, traverse, and validate information outside the local project so it never hallucinates against out-of-date or incomplete sources.