Okay thanks by the way this is how I am currently doing it

you can for example use containers

lxc or docker

I meant this is current approach

I will look into the approach you suggested

but honestly you probably need both approachs for a robust system: - initial fix generation using AST to identify issues and use AST manipulation to construct the proposed fix in a syntactically correct way. This produces the fixed file. - Then you clone the codebase with fixed file in a sandboxed env, and run tests. If tests pass you can use git and gh cli to create branch/Pull request. If tests failed, go to first step and then iterate

My bad

I built a proof-of-concept SaaS for Graylog clients in HACKERverse where AI is used to generate attack simulations and trigger them directly on Graylog dashboards. It includes real-time analytics and insights, showing how AI can make log management systems smarter and more proactive. chekc this out https://graylog.hackerverse.cloud/

@jibrandev how is your SaaS for graylog is doing like how much is its growth and overall cost monthly (hosting charges ) etc

I actually want to launch my own Saas so that's why I am asking

hey Pinecone community! sharing something we just open-sourced that takes a different approach to RAG entirely. NanoIndex skips the vector DB and embedding step. it indexes documents as trees, extracts entity relations, and navigates structure at query time instead of doing nearest-neighbor search over chunks. for financial and legal documents especially, this matters a lot. the answer to a real question is usually spread across multiple sections. chunk retrieval finds one. tree navigation finds all of them. 95% on FinanceBench. 96% on DocBench Legal. would be curious to hear from people here who've hit the limits of vector retrieval on structured documents. demo: https://nanoindex.nanonets.com/demo github: https://github.com/NanoNets/nanoindex

this looks very nice

I built a team of AI Employees that work together reliably for weeks. They work in agile sprints, with clear OKRs and tight KPIs... Try it if you wanna automate some boring tasks https://hire.sista.ai

pretty cool. thanks for sharing

hey everyone! question for people running production RAG systems, how do you handle document updates? suppose you have thousands or millions of chunks already embedded and indexed. a source document changes (new section added, policy updated, docs edited etc.) do you re-embed the entire document, re-embed only affected chunks, use some kind of diffing/hash-based approach?or not worry about the extra embedding cost? i'm asking because i built a small experiment that tracks chunk-level hashes and only re-embeds chunks whose content changed. before i spend more time on this, i'm trying to understand whether this is an actual pain point people experience in production or whether most people simply re-embed everything or use some other techniques.

hey 👋 vector db crowd seemed like a good fit for this shipped an open source python framework for tracking LLM cost/ tokens/latency — TokenSense. runs entirely in-process, no proxy relevant here because if you're running RAG pipelines, every query usually means an embedding call + a retrieval + a generation call, and tracking cost across all three gets messy fast. this wraps your openai/anthropic/groq clients with one line and tracks every hop automatically pip install tokensense-ai also has langchain + llamaindex callback hooks since most RAG stacks run through one of those website: visualvortexcreatives.dev github: github.com/SahilSelokar/Tokensense docs: docs.visualvortexcreatives.dev curious if anyone here tracks embedding costs separately from generation costs in their pipelines — feels like a gap most tools don't handle well

Hey! Thanks for sharing. This seems like a good fit for the #1424897417320595487 channel. Can you add it there?

Sure!!

discord.gg/prettygirls

discord.gg/prettygirls

discord.gg/prettygirls

discord.gg/prettygirls

discord.gg/prettygirls

Hey guys! Just pushed a massive update (v0.2.3) to TokenSense We finally solved the "is this cheaper model actually good enough?" problem. Built a feature called ShadowTest that runs your production model against a cheaper candidate (like gpt-4o vs claude-haiku) in parallel, and scores it using exact match, JSON validation, or an LLM judge. Gives you the exact pass rate and cost savings before you ship it. Also fully nailed down streaming support (stream=True) with exact token extraction and zero latency overhead. Check it out if you're building with LLMs! Repo: https://github.com/SahilSelokar/Tokensense Website:https://visualvortexcreatives.dev/ pip install tokensense-ai

Hey everyone! I recently built and open-sourced Open Index — a structured context layer for AI agents. It's designed for anyone building domain-specific AI agents (SRE, customer support, security, legal, insurance, sales, marketing, etc.) and helps organize domain knowledge as structured entities and relationships that agents can navigate reliably. Would love to hear your thoughts, feedback, or ideas for improving it. GitHub: https://github.com/DrDroidLab/open-index

Hey Shrish here, everyone's vibecode-maxxing till we hit our claude bill, I'm building an open-source context layer for coding agents that helps cut your claude costs and improve accuracy by giving coding agents a graph. We are at 1.6k+ stars on github, as we launched Graft last month. Here's the repo: https://github.com/NanoNets/Graft/ Quickstart: https://graft.nanonets.ai/ I wanted to understand whats the bigger issue for you is it the token costs or accuracy? Thanks for listening to me :))

@damp-piano-64892 and @dazzling-advantage-62195 how are your products similar and different?

Mine is just for coding agents and gives coding agents depth to the language you code in using LSPs

Open Index is more domain-agnostic. You define the entities, schemas, and relationships for whatever domain your agent operates in infrastructure, incidents, customers, tickets, security assets, insurance cases, etc. The agent can then navigate and continuously update that structured context.