# Show HN: Oynix – Make your coding agent aware of your whole codebase, locally > Source: > Published: 2026-08-25 19:34:53+00:00 # Nothing your team decides is ever lost. Oynix remembers everything from and helps your see, rather than start blind. The gap ## Your team's reasoning is everywhere. Your agent sees none of it. The decision lives in a Slack thread. The rationale left with the engineer. Your agent starts every session blind, and rewrites what someone already solved. [See how it works](#how) The cost ## Blind is not cheap. It is billed somewhere else. The industry spent two years measuring what AI gives back. The measurements that matter now are about what it costs when it does not know what your team already knows. Uber spent its entire 2026 AI budget in four months of a twelve month year, after putting Claude Code in front of roughly 5,000 engineers. Uber CTO, May 2026 · The Information, via ForbesWhat Salesforce expects to spend on Anthropic this year. Asked what for, Benioff answered in one word: “Coding.” Marc Benioff, CEO · All-In podcast · May 2026His projection, not a filed figureOne two hour coding session, run by Uber’s own CTO. Engineers there average $150 to $250 a month. Power users reach $2,000. Uber CTO, May 2026 · The Information, via ForbesThe buyer cannot justify it. The seller cannot absorb it. Every one of these is the same bill in a different envelope. **The agent does not know what your team already knows, so somebody pays to tell it again, every session.** 90 seconds to context ## Connect once. Every agent reads the same memory. One CLI on your own machine ties your repos, docs, tickets and conversations into a single graph, then serves it to whatever agent you already use. ### Connect your sources One tap. No tokens, no scope hunting. ### The graph builds itself Code linked to what explains it. No writing. ### Every agent plugs in An MCP server. Zero tokens on our side. [Keep goingConnecting is level two of seven. Here is the rest of the ladder, and where everything else stops.](#levels) Connectors · 18 live sources ## Everything your team knows, in one graph. Each connector pulls its source in and links it to the code it shaped. Six providers connect in one tap. Pick exactly which channels, spaces or drives sync. [GitHubCode](/connectors/github) [GitLabCode](/connectors/gitlab) [BitbucketCode](/connectors/bitbucket) [1-TAPJiraTickets](/connectors/jira) [1-TAPConfluenceDocs](/connectors/confluence) [1-TAPLinearTickets](/connectors/linear) [1-TAPSentryErrors](/connectors/sentry) [1-TAPGoogle DriveDocs · Sheets · Slides](/connectors/gdrive) [SlackComms](/connectors/slack) [Microsoft TeamsComms](/connectors/teams) [Microsoft 365Docs](/connectors/microsoft) [NotionDocs](/connectors/notion) [CrashlyticsErrors](/connectors/crashlytics) [FirebaseData](/connectors/firebase) [SupabaseData](/connectors/supabase) [MixpanelEvents](/connectors/mixpanel) [CleverTapEvents](/connectors/clevertap) [Files & DocsUpload · 31 types](/connectors/upload) **your tool?** [Request one](/request-new-tool) The wiki Server only ## A handbook nobody had to write. Oynix generates an engineering handbook from the graph, with every claim traced to the file, commit or thread it came from. It updates when the code does. #### Architecture The service is four packages behind one HTTP entry point. `cmd/server` wires the router, then hands every request through middleware before it reaches a handler. **Entry point** cmd/server/main.go → ApiGateway **Hot path** ApiGateway → PaymentGateway → stripe_client **Storage** PaymentStore over Postgres, RedisClient for idempotency keys **Most connected** PaymentGateway, 17 callers across 4 services #### Auth & sessions Tokens are validated with `verifyStrict()` on every request. There is no lenient path, and the permissive helper was removed in March after it allowed an expired token through staging. **Session expiry** 15 min idle, 8 hr absolute **Validation** verifyStrict() only, enforced in middleware **Refresh** rotating, single use, replay is rejected **Owner** Sara, since 12 Nov #### Payments `PaymentGateway` is the only component permitted to call Stripe. Handlers never touch `stripe_client` directly, so retries and idempotency stay in one place. **Provider** stripe_client, wrapped, never called directly **Idempotency** Redis key per intent, 24 hr TTL **Retries** 3 attempts, exponential, 4xx never retried **Blast radius** 17 callers, 4 services #### Rate limiting Rate limiting lives in middleware, not in handlers. This was decided on 12 November after a duplicated implementation caused a merge conflict in `auth/handler.go` . Two engineers had independently added a limiter, one per handler and one global. The team kept the middleware version and deleted the handler copy. Resolution took four minutes once the earlier thread surfaced. **Location** internal/middleware/ratelimit.go **Algorithm** token bucket, per API key **Decided** 12 Nov, ENG-412 #### Decisions Thirty-one decisions recovered from tickets, pull request reviews and Slack. Each one keeps the thread it came from, so the reasoning survives the people. **12 Nov** Rate limiting moves to middleware **28 Oct** Stripe calls confined to PaymentGateway **6 Mar** Lenient token validation removed **19 Feb** Idempotency keys moved to Redis from Postgres #### Ownership Ownership is derived from commit history and review activity, not from a file anyone has to maintain. It changes when the work changes. **payments/** Sara, 64% of commits in 90 days **auth/** Sara, took over from John on 12 Nov **middleware/** John, 41%, shared with Priya **At risk** billing/legacy, last owner left in June #### Runbooks Five runbooks assembled from incident threads and the fixes that closed them. Each step links to the change that made it necessary. **Stripe timeout** Check idempotency keys before replaying, or charges double **429 from gateway** Token bucket is per API key, not per IP **Session drops** Usually clock skew on the refresh node Ask the graph ## Ask a question. Get the exact nodes that answer it. No paragraph of hedging. Your agent receives the subgraph, tagged with where every edge came from. Pick a question, then click any node. **Type** Person **Owns** payments/, auth/ **Commit share** 64% over 90 days **Reviews** 42 pull requests **Since** 12 Nov **GitHub** *42 pull requests reviewed* **Slack** *#eng-platform, 12 Nov* Confidence ## Every edge says how it knows. Oynix tags each relationship with the evidence behind it. When your agent answers from the graph, you can tell what was read from source and what was reasoned. **billing-svc/checkout.go · L112** The Razorpay branch is read straight from the code. **Why the last edge is ambiguous** Two code paths set the currency flag, and a feature flag can override both. Oynix says so rather than guessing which one wins. Found in the code. The relationship exists at a file and line you can open. Reasoned from structure and naming. Usually right, worth checking before you rely on it. The evidence points more than one way, and the graph tells you so instead of picking. The mechanics ## Context has seven levels. Most tools ship two. Reading your code is the first one. It is also where almost every tool stops, because the other six require knowing things your repository does not contain. ### Index Read the code as a graph rather than a folder. Every symbol, call and import, across every repo, in one structure you can walk. ### Connect Attach the places the reasoning actually lives. Seventeen sources, one tap each, and the tickets, threads and docs land beside the code they explain. ### Reason Answer a question by walking across all of it at once. Not a search box over one source, but a path from a function to the argument that produced it. **charge()** retry twice before failing? ### Write back Put the answer back where the question came from, so the second person to ask it never has to. A read-only graph decays. This one does not. func (g *Gateway) charge(ctx, amt) error { + // Retries twice: the PSP returns 503 on cold start. + // Decided in ENG-412 after the Nov 12 incident. for attempt := 0; attempt < 2; attempt++ { ### Presence Know who is in this file right now, and whose work you are about to collide with. Context is not only historical. **charge()**. Your agent is about to rewrite the same function. ### Skills Teach the agent how this team works, not how software works in general. The conventions nobody wrote down because everybody already knew them. *→*Money is always an integer of minor units. Never a float. *→*Any PSP call goes through the retry wrapper, never directly. *→*Schema changes ship behind a flag, and Priya reviews them. ### Compound Every session leaves the graph better than it found it. The work of explaining your codebase happens once and keeps paying. Memory, not documentation. Agents ## Retrieval that costs zero tokens. Oynix is an MCP server, not a wrapper. Your agent does the reasoning with its own model and its own keys. We return graph facts, so you are never billed twice for the same thought. Measured, keyless, zero cost per query The indexing times above are the structural pass: parsing, the code graph, the search index. All of it runs on your machine with no model and no network. Almost all of the remaining time in a full index goes to writing a plain-English description of every function, which is what lets you ask a question in your own words instead of guessing at the identifier. That step is optional, and nothing measured above needs it. Local first ## The engine runs on your machine. Bring your own model keys and your own database. Your code is parsed locally and stored where you point it. We host nothing you did not ask us to host. Cloning, parsing and indexing happen on your hardware. Nothing is shipped to a hosted indexer first. Your model provider, your account, your quota. Queries go from your machine to your provider. Point Oynix at your own graph store. The memory is yours, and it stays inside your infrastructure. Serve the same graph to your whole team over your own network. A new hire asks instead of reading a year of threads. ### Not sure Oynix is right for your team? Ask an AI that has read the docs, the source and the benchmark. It will tell you where Oynix fits and where it does not.