Oracle Router.

Oracle Router is the Hivy routing layer: easy work can stay local or low-cost, while harder work can be routed to a configured frontier model when needed.

Practical use.

Routing is a choice about where a reasoning step runs, not a requirement to send every task to a frontier model. Keep routine project inspection local when possible and reserve configured remote calls for work that benefits from them.

What it carries.

  • Difficulty-aware routing
  • Local-first default posture
  • Optional BYOK cloud routing when enabled
  • Frontier tokens reserved for hard problems

How it fits ShardStitch.

This feature helps choose the next recovery path from the task state, target tool, and available evidence rather than routing every task through the same packet.

Routing with a recovery boundary.

Oracle Router is most useful when a task has an obvious cost or difficulty difference: keep routine scans local, then route a harder reasoning step to a configured model when needed. The recovery packet remains the stable handoff artifact, so changing models does not require rebuilding the entire conversation.

Routing is optional and configuration-dependent. ShardStitch does not silently send project data to a provider; review the configured provider, credentials, and sharing boundary before enabling any cloud route.

Route only the step that needs a different model.

For a straightforward status scan, stay on the local path. If a task needs broader reasoning, select a configured provider for that step and carry the same verified repository state into the handoff.

  1. Define the question and its data needs before selecting a route.
  2. Use a local backend for routine summarization or project-state checks when it is adequate.
  3. Before a remote route, check the provider configuration and what context will be sent; after the response, validate recommendations against local files.

Worked example.

A routine question about which files changed can remain local. A difficult architecture review may justify a configured remote model, but first narrow the prompt to the relevant diff and decision, and confirm what context the provider will receive. When the response returns, test its recommendation against the repository instead of copying it directly into a patch.

Limits and verification.

Routing does not make a model answer authoritative. A remote provider may receive the context included in that request, so local-first operation and optional remote routing are distinct modes. Review provider settings and do not send secrets or unrelated project files.