Why This Search Exists

Teams often need repo, issue, or metadata lookups as part of content, indexing, or operational workflows. The task is simple, public, and read-only, so spinning up a full browser stack is unnecessary.

At the same time, many teams still want one consistent interface across hosted tasks and local browser tasks, rather than maintaining completely separate tool models.

Recommended Approach

Hosted adapters solve that nicely. The same `site` naming pattern can be used, but the execution shifts to a remote-safe API path such as `POST /v1/sites/run` when the target is public and stateless.

That means GitHub repo lookups can stay lightweight, while the broader local browser runtime is reserved for workflows where browser state genuinely matters.

Key Takeaways

  • Public GitHub metadata is a strong fit for hosted adapters.
  • Shared naming across local and hosted tools reduces mental overhead.
  • A hosted adapter layer works best when the task is read-only and predictable.
  • The local browser runtime stays focused on stateful interaction, not public metadata calls.

Fast Start

  1. Register or reuse an API key for the hosted layer.
  2. Discover current hosted adapters through `GET /v1/sites/hosted`.
  3. Call `POST /v1/sites/run` with `name=github/repo` and the repo argument.
  4. Use the same adapter catalog page to compare hosted and local execution modes.

Next Action

Open hosted adapter catalog

Move from research to implementation by choosing the correct boundary: local runtime for real-session work, hosted API for public-safe retrieval.