Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

research: how to understand Cortex adoption (installs, versions, retention) without being intrusive

Aperta
  • Qualcosa non va?
#1,321 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@mrsabath ci sta già lavorando.

Dal 7/10/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

laptop question
Feature Description

We cannot currently answer basic questions about Cortex adoption: how many people have installed
it, which versions are in use, how many installs are still running a week later. The only signal
today is anecdotal — someone mentions in chat that they installed it.

This issue is research, not implementation. The goal is to understand the available options
for obtaining adoption information, what each one costs in user trust, and what the honest
trade-offs are — and to produce a recommendation for discussion. No approach should be
implemented off the back of this issue. Whatever comes out of it gets its own issue, scoped
and agreed separately.

The reason for the care: Cortex sits in the request path and decrypts the user's agent traffic.
That earns a level of trust that is very easy to spend and very hard to get back. Users are
rightly sensitive about anything leaving their machine, and a tool positioned as "see what your
coding agent actually sends" undermines its own pitch if it quietly sends things itself. The
default assumption for this research is that intrusive collection is off the table, and the
burden is on any proposal to show it does not cross that line.

It is a legitimate outcome of this issue to conclude that we should collect nothing from
installed clients, and get what we need from other sources — or to accept that some questions
simply stay unanswered.

Proposed Solution

Investigate and write up the options. Not a plan to build any of them.

1. What do we actually need to know, and why?

  • List the specific questions worth answering (install count? version spread? retention?
    which agent integrations are used? platform mix?)
  • For each, state the decision it would inform. Questions that would not change any decision
    should be dropped rather than carried along
  • Separate "would genuinely change what we build" from "nice to know" — the second category
    does not justify any user-visible cost
  • Note what precision is actually required: an order of magnitude is often enough, and cheap
    approximations may beat exact counts that need instrumentation

2. Survey the approaches, including the ones that collect nothing

Zero-collection and off-machine sources first, since these carry no user cost:

  • Download and release-asset counts (GitHub release API, install-script fetches, container
    pulls, package-manager stats) — what they can and cannot tell us, and how badly CI and
    mirrors distort them
  • Repo-side signals: stars, forks, clones, issue and feedback volume, questions in chat
  • Asking people directly: surveys, a check-in with known users, opt-in registration for
    early adopters. Low-tech, honest, and possibly sufficient at our current scale
  • Update-check traffic, if an update check is something users would want anyway for its own
    sake — and whether using it for counting is a bait-and-switch

Then approaches that do involve the client, each assessed honestly rather than advocated for:

  • Fully opt-in reporting (explicit affirmative action, off by default, no dark patterns)
  • Local-only accounting the user can voluntarily share — Cortex keeps its own numbers, nothing
    leaves the machine unless someone chooses to send them
  • Aggregate or privacy-preserving techniques, and whether their complexity is remotely
    justified at our scale
  • Anonymous reporting — documented here specifically so its costs are on the record. Note
    that "anonymous" is a weaker claim than it sounds: IP addresses, timing and rare
    configuration combinations can re-identify small populations

3. Assess each against the trust bar

  • What leaves the machine, in concrete terms — not a category label
  • Whether it can be meaningfully described to a user in one sentence they would accept
  • Re-identification risk, especially at small user counts where uniqueness is high
  • Whether it is verifiable by a suspicious user, or requires taking our word for it
  • Reaction if it were discovered rather than announced — a useful test of whether we are
    comfortable with it
  • What it would do to Cortex's positioning as a transparency tool

4. Look at what comparable tools do — and how it went

  • How other local developer tools and proxies handle this (both the ones that collect and the
    ones that deliberately do not)
  • Cases where telemetry damaged a developer tool's standing, and what specifically triggered
    it — usually defaults, disclosure and discoverability rather than the payload itself
  • Any legal or policy constraints that apply to us

5. Deliverable

  • A written comparison of the options with the trade-offs stated plainly, including the
    do-nothing option as a real candidate
  • A recommendation, which may be "collect nothing from clients"
  • If any client-side approach is recommended: what it sends, the default, the disclosure, the
    off switch, and how a user verifies the claim — as a proposal for discussion, not a
    decision already taken
  • Open questions needing a product or maintainer call, flagged rather than resolved quietly
  • Follow-up issues filed for whatever is agreed. Nothing ships from this issue.
Additional Context

Part of the Cortex v0.9.0 release, Pillar 2 (Observability) of rossoctl/rossoctl#2514 — here
pointed at understanding adoption of the tool itself rather than at the agent's traffic.

Related:

  • cortex#898 — report statistics to a central collector. Overlapping concerns: its payload is
    traffic and cost rather than adoption, but it raises the same trust questions and should
    probably not be designed independently of whatever this research concludes
  • cortex#944 / cortex#945 — macOS and Linux install + service lifecycle (where install-time
    signals would originate, if any)
  • cortex#959 — first-run path, install to first useful reading (the drop-off we cannot currently
    see)
  • cortex#1236 / cortex#1237 — agentop configure surfaces (relevant to the integration-mix
    question)
  • cortex#1002 — Cortex being down can break the harness (any client-side network call would have
    to avoid this failure mode entirely)
Lingua principale
Go
Stelle
18
Fork
42
Merge medio
12h 34m
PR unite (30g)
257

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rossoctl/cortex

Tutte le issue di rossoctl/cortex

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.