Nothing your team
decides is ever lost.

Oynix remembers everything from GitHubSlack JiraConfluenceNotionFirebaseand helps your ClaudeChatGPTCursorGeminiGrok OpenClaw see, rather than start blind.

Install OynixSee how it works
Works withClaudeClaude CodeCursorCursorChatGPTCodexGeminiGemini CLIOpenClaw OpenClaw18 agents · 18 sources

The gap

Tap to connect your sources

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.

4 months

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 Forbes
$300M

What 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 figure
$1,200

One 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 Forbes

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

GitHubGitHubConnected
ConfluenceConfluenceConnected
Slack SlackConnected
JiraJiraConnected
Google Drive Google DriveConnected
0:30

Connect your sources

One tap. No tokens, no scope hunting.

Knowledge graph
PaymentGatewayowned by SaraENG-412rate limit → middleware17 callersdecided 12 Nov
0:60

The graph builds itself

Code linked to what explains it. No writing.

Oynix · MCPgraph layer
Claude
Claude
Blind
Cursor
Cursor
Blind
Codex
Codex
Blind
0:90

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.

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.

oynix wiki · payments-service
Overview
History

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 pointcmd/server/main.go → ApiGateway
Hot pathApiGateway → PaymentGateway → stripe_client
StoragePaymentStore over Postgres, RedisClient for idempotency keys
Most connectedPaymentGateway, 17 callers across 4 services
cmd/server/main.go:31internal/payments/gateway.goinferred from imports

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 expiry15 min idle, 8 hr absolute
ValidationverifyStrict() only, enforced in middleware
Refreshrotating, single use, replay is rejected
OwnerSara, since 12 Nov
internal/auth/service.go:42ENG-288#eng-platform, 6 Mar

Payments

PaymentGateway is the only component permitted to call Stripe. Handlers never touch stripe_client directly, so retries and idempotency stay in one place.

Providerstripe_client, wrapped, never called directly
IdempotencyRedis key per intent, 24 hr TTL
Retries3 attempts, exponential, 4xx never retried
Blast radius17 callers, 4 services
internal/payments/gateway.go:88commit 7c21abambiguous: two retry paths

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.

Locationinternal/middleware/ratelimit.go
Algorithmtoken bucket, per API key
Decided12 Nov, ENG-412
ENG-412commit a3f9d2#eng-platform

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 NovRate limiting moves to middleware
28 OctStripe calls confined to PaymentGateway
6 MarLenient token validation removed
19 FebIdempotency keys moved to Redis from Postgres
31 decisionsfrom 4 sources3 marked ambiguous

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 riskbilling/legacy, last owner left in June
git history, 90 days42 pull requests

Runbooks

Five runbooks assembled from incident threads and the fixes that closed them. Each step links to the change that made it necessary.

Stripe timeoutCheck idempotency keys before replaying, or charges double
429 from gatewayToken bucket is per API key, not per IP
Session dropsUsually clock skew on the refresh node
INC-91INC-104#incidents
Generated from 18 sources · every claim tracedUpdated 4 min ago

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.

ownsowned_untilcontainscontainsdescribesSarapeopleJohnpeoplepayments/payments-svcPaymentGatewaypayments-svcPaymentStorepayments-svcPayments RFCconfluence
same servicecrosses a service boundaryclick a node
person · people
Sara
TypePerson
Ownspayments/, auth/
Commit share64% over 90 days
Reviews42 pull requests
Since12 Nov
Known from
GitHub42 pull requests reviewedSlack#eng-platform, 12 Nov
Extracted

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.

One real path through checkout4 edges · 3 tagged extracted, 1 ambiguous
User taps Paycheckout-webCheckoutAPIbilling-svccurrency== "INR"razorpay_clientvendorstripe_clientvendorextractedextractedextractedambiguous
billing-svc/checkout.go · L112The Razorpay branch is read straight from the code.
Why the last edge is ambiguousTwo code paths set the currency flag, and a feature flag can override both. Oynix says so rather than guessing which one wins.
Extracted

Found in the code. The relationship exists at a file and line you can open.

Inferred

Reasoned from structure and naming. Usually right, worth checking before you rely on it.

Ambiguous

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.

01

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.

PaymentGatewaycharge()retry()WebhookRateLimitercheckout.go17 callers · 4 repos · resolved, not guessed

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.

54%
Oynix accuracy
at 2.3K tokens of context
41%
Best of three alternatives
the strongest of three tools we tested, at 9.3K tokens for the same questions
5
Graph tools over MCP
ownership, source, context, impact, blast radius
16
Agent hosts
one command writes the right config for each

Measured, keyless, zero cost per query

2.66s
Small repo, indexed
1,055 nodes. No model, no network, no spend
8.08s
Large repo, indexed
24,358 nodes, structural. Adding descriptions takes it to about 18 minutes on a repository this size
70.3%
Memory, LoCoMo n=600
top score of every system tested, against mem0, supermemory, zep and BM25
88.3%
Code retrieval, issue to code
n=300, ahead of graphify and BM25, both sides keyless

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.

Local engine

Cloning, parsing and indexing happen on your hardware. Nothing is shipped to a hosted indexer first.

Bring your own keys

Your model provider, your account, your quota. Queries go from your machine to your provider.

Bring your own database

Point Oynix at your own graph store. The memory is yours, and it stays inside your infrastructure.

Shared when you want it

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.