Work with us.

No. Code and dependency analysis run locally in the IDE. Oryon only syncs findings, metadata, and the minimum context needed for AI, authentication, or the dashboard.

Oryon syncs findings, dependency state, project or repository metadata, shared suppressions, and scan history. The goal is to preserve team memory and reporting, not to move the full repository into the cloud.

Not by default. Oryon uses the minimum context needed to enrich or classify findings, usually snippets and relevant metadata, not a full copy of the source tree.

Yes. Code and dependency analysis run locally in the editor. The dashboard stays behind as shared memory, reporting, and follow-up when the team actually needs it.

No. You can use the extension locally without depending on the dashboard. Linking a repository matters when you want shared memory, scan history, synced dependency state, and reusable suppressions across future scans.

Yes. Dashboard linking is project or repository based, not all or nothing. You can start with a local-first pilot and only sync the repositories where shared memory, history, or team follow-up actually matter.

The triage flow is intentionally conservative. A finding is only dropped if both passes agree on `drop`; on conflict, timeout, error, or uncertainty, Oryon keeps the finding.

Both. It can analyze changes while you edit or save, and it can also run a broader workspace scan when you want a fuller view of repository state.

Yes. In addition to detection, Oryon adds explanation, technical context, and, when relevant, remediation guidance so developers can understand what matters and what to review first.

Yes. Oryon is built so useful decisions survive the next scan. Shared suppressions and repository memory reduce noise without forcing teams to repeat the same triage work again and again.

No. Oryon improves early signal inside the developer workflow, but it does not replace manual review, specialized audits, or offensive testing where the risk level or context requires them.

It is built specifically to reduce that problem. The heuristic pre-filter removes a good amount of innocuous baseline noise, the triage layer tries to separate relevant signal from doubtful findings, and shared suppressions stop teams from fighting the same false positive on every scan.

Today the clearest fit is VS Code and compatible forks such as Cursor, VSCodium, Windsurf, Antigravity, or Code - OSS, where the local-first model and editor-native workflow create the strongest advantage.

Yes. Oryon does not require you to replace your existing stack. Many teams use it to shift the signal earlier into the IDE while keeping broader scanners or extra controls in CI and platform workflows.

Today the core surface is the VS Code extension, the Oryon dashboard and API, project-based sync, shared suppressions, Google, Magic Link, and SSO authentication, and GitHub or GitLab issue drafts. The API can also ingest data from CI.

Yes. Oryon can prepare issue drafts so teams can move from a finding to action faster while keeping technical context and remediation framing clearer.

Yes, although the exact behavior depends on repository size, structure, and language mix. On larger teams, the right approach is usually to pilot on one representative repository first and tune the workflow before broader rollout.

No. The first layer of value should happen inside the editor. CI, the API, and dashboard sync help extend coordination and reporting, but they are not required to start evaluating the extension or the local-first workflow.

For the full experience, yes. An account gives you dashboard access, authentication, repo-linked shared memory, scan history, and sync between the extension and the platform.

You gain shared memory. Suppressions, findings, dependency state, and scan history stay tied to the same repository fingerprint, so future scans do not start from zero.

No. The dashboard adds coordination, reporting, and shared history, but the first layer of value still lives in the extension. Teams can start in the editor and expand into the dashboard when shared memory becomes useful.

Yes. Oryon supports both individual and organization-style setups, so you can work in a personal space or collaborate inside a shared team workspace with broader visibility and coordination.

That depends on the workspace and its permissions. The intended model is to share visibility with the people and teams who need to work on those projects, not to expose every result indiscriminately.

Yes. The right model is for each person to use their own identity and, when needed, collaborate inside the same workspace or team. That keeps permissions, traceability, and shared memory cleaner than using shared credentials.

It fits both. An individual developer gets earlier feedback inside the IDE; a team also gets dashboard memory, repo-linked context, scan history, and shared handling of false positives.

Yes. Oryon includes a Free plan so teams can try the workflow and evaluate basic fit before moving to plans with more capacity, more projects, or team-oriented features.

Cancellation stops the next renewal cycle. In practice, access usually remains active until the end of the paid period, after which the workspace moves to the plan state or limits that apply.

Yes. Plan changes affect the account, dashboard, and available limits, not the base extension installation. The normal path does not require reinstalling the plugin.

Yes. Depending on the case, Oryon can help with technical questions, initial setup, workflow evaluation, and pilot definition so teams do not have to discover everything by trial and error.

Yes, and that is usually the right way to evaluate it. The best path is to start with one or two representative repositories, validate signal quality and workflow friction, and only then expand to more developers.

The product is not meant to rely on artificial lock-in. The normal path is to start small, validate fit, and expand only if the workflow earns it. If you cancel, the next renewal stops and access remains active until the end of the paid period.