cd /news/developer-tools/show-hn-oynix-make-your-coding-agent… · home topics developer-tools article
[ARTICLE · art-110781] src=oynix.dev ↗ pub= topic=developer-tools verified=true sentiment=· neutral

Show HN: Oynix – Make your coding agent aware of your whole codebase, locally

Oynix, a new developer tool launched on Hacker News, creates a local graph of a team's code, docs, tickets, and conversations so coding agents can access institutional knowledge instead of starting blind. The tool connects to 18 sources including GitHub, Jira, Slack, and Notion, and serves the graph to any agent via an MCP server. Oynix cites Uber's 2026 AI budget overspend and Salesforce's expected Anthropic spending as evidence that blind agents are costly.

read8 min views2 publishedAug 25, 2026
Show HN: Oynix – Make your coding agent aware of your whole codebase, locally
Image: source

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 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.

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 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.

── more in #developer-tools 4 stories · sorted by recency
── more on @oynix 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/show-hn-oynix-make-y…] indexed:0 read:8min 2026-08-25 ·