feat(connections): Harmoniqs Cloud is connectable where Pasqal is by Rchari1 · Pull Request #92 · harmoniqs/opencode

Rchari1 · 2026-07-28T21:35:50Z

The reports

"where is our harmoniqs cloud, where can I put an API key in"
"I literally tried to switch to piccolissimo and it did not ask me for an API key"
"it's not a prompt that should ask, it should be integrated in like how pasqal is connected"

Why both happened

Both trace to amicode#200, and neither was a broken wire.

statusTabConnections()filtered company-compute out of the Connections tab and connectionTitle() renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation — one credential for one service, not a second product. The effect was not: Pasqal Cloud rendered as a connectable service in the place that lists clouds, and ours did not. So people went looking for Harmoniqs Cloud exactly where Pasqal is, and found nothing.

Report 2 has a different cause and is not a bug: with a valid key on file hpClickAction("connected") returns "activate", so clicking HP switches immediately instead of re-asking. Correct — but the status dot lived inside the collapsed card, so the row had no way to say "you're already connected," and a successful switch was indistinguishable from a no-op. (Verified live: the server reported company-compute → state: "connected", identity raghav-internal.)

Changes

statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, using the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this un-hides a working flow rather than building a new one. Kept as a function so there's still one obvious place to filter a genuinely internal connection later.
connectionTitle() → "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate).
The solver row states its connection state — CONNECTED / CHECK KEY / ADD KEY. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, words survive colour-blindness and a screenshot, and it says what a click will do.
HP row tooltips name Harmoniqs Cloud, and the connected one states the consequence: every solve on this solver runs there.

Not changed

The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points (tab and capsule) write the same credential, so connecting in either shows up in both.

Testing

ui: 57 pass. turbo typecheck: 23/23. Strings verified present in the built darwin-arm64 binary, which is vendored and serving the running dev host.

The two filter tests that pinned #200's removal are rewritten to pin the opposite, with the regression spelled out — including that a compute-only list must still render a card rather than hit the empty state.

Reviewer note

This reverses a deliberate #200 decision (Kate's, on presentation grounds). Worth a look from her: the disagreement is only about where the credential is entered, not about the one-credential model, and the capsule affordance is untouched.

The solver row said "API key connected" and "Runs in the cloud" — which cloud was never stated, on the one control where a user commits to a paid service. Every refusal they can hit downstream now says "Harmoniqs Cloud" (amico-run's local-launch refusal, the hpc gate), so the control that sends them there should use the same name. The connected tooltip also states the consequence — every solve on this solver runs there — since that is the thing users were guessing about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Reported: "where is our harmoniqs cloud, where can I put an API key in" — and separately, switching to Piccolissimo + Altissimo appeared to do nothing. Both trace to amicode#200. It filtered company-compute OUT of the Connections tab and renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation (one credential for one service, not a second product), but the result was that Pasqal Cloud rendered as a connectable service in the place that lists clouds and OURS did not. Users went looking for it exactly where Pasqal is. - statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, with the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this is un-hiding a working flow, not building a new one. Kept as a function so there is still one obvious place to filter a genuinely internal connection later. - connectionTitle() returns "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate). - The solver row now states its connection state (CONNECTED / CHECK KEY / ADD KEY). With a key already on file, clicking HP correctly activates without re-asking — but the status dot lived inside the collapsed card, so the row had no way to say so and a successful switch was indistinguishable from a no-op. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, and words survive colour-blindness and a screenshot. It also says what a click will do. The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points write the same credential, so connecting in either shows up in both. ui: 57 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Rchari1 · 2026-07-28T21:35:50Z

The reports

"where is our harmoniqs cloud, where can I put an API key in"
"I literally tried to switch to piccolissimo and it did not ask me for an API key"
"it's not a prompt that should ask, it should be integrated in like how pasqal is connected"

Why both happened

Both trace to amicode#200, and neither was a broken wire.

statusTabConnections()filtered company-compute out of the Connections tab and connectionTitle() renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation — one credential for one service, not a second product. The effect was not: Pasqal Cloud rendered as a connectable service in the place that lists clouds, and ours did not. So people went looking for Harmoniqs Cloud exactly where Pasqal is, and found nothing.

Report 2 has a different cause and is not a bug: with a valid key on file hpClickAction("connected") returns "activate", so clicking HP switches immediately instead of re-asking. Correct — but the status dot lived inside the collapsed card, so the row had no way to say "you're already connected," and a successful switch was indistinguishable from a no-op. (Verified live: the server reported company-compute → state: "connected", identity raghav-internal.)

Changes

statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, using the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this un-hides a working flow rather than building a new one. Kept as a function so there's still one obvious place to filter a genuinely internal connection later.
connectionTitle() → "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate).
The solver row states its connection state — CONNECTED / CHECK KEY / ADD KEY. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, words survive colour-blindness and a screenshot, and it says what a click will do.
HP row tooltips name Harmoniqs Cloud, and the connected one states the consequence: every solve on this solver runs there.

Not changed

The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points (tab and capsule) write the same credential, so connecting in either shows up in both.

Testing

ui: 57 pass. turbo typecheck: 23/23. Strings verified present in the built darwin-arm64 binary, which is vendored and serving the running dev host.

The two filter tests that pinned #200's removal are rewritten to pin the opposite, with the regression spelled out — including that a compute-only list must still render a card rather than hit the empty state.

Reviewer note

This reverses a deliberate #200 decision (Kate's, on presentation grounds). Worth a look from her: the disagreement is only about where the credential is entered, not about the one-credential model, and the capsule affordance is untouched.

The solver row said "API key connected" and "Runs in the cloud" — which cloud was never stated, on the one control where a user commits to a paid service. Every refusal they can hit downstream now says "Harmoniqs Cloud" (amico-run's local-launch refusal, the hpc gate), so the control that sends them there should use the same name. The connected tooltip also states the consequence — every solve on this solver runs there — since that is the thing users were guessing about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Reported: "where is our harmoniqs cloud, where can I put an API key in" — and separately, switching to Piccolissimo + Altissimo appeared to do nothing. Both trace to amicode#200. It filtered company-compute OUT of the Connections tab and renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation (one credential for one service, not a second product), but the result was that Pasqal Cloud rendered as a connectable service in the place that lists clouds and OURS did not. Users went looking for it exactly where Pasqal is. - statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, with the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this is un-hiding a working flow, not building a new one. Kept as a function so there is still one obvious place to filter a genuinely internal connection later. - connectionTitle() returns "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate). - The solver row now states its connection state (CONNECTED / CHECK KEY / ADD KEY). With a key already on file, clicking HP correctly activates without re-asking — but the status dot lived inside the collapsed card, so the row had no way to say so and a successful switch was indistinguishable from a no-op. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, and words survive colour-blindness and a screenshot. It also says what a click will do. The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points write the same credential, so connecting in either shows up in both. ui: 57 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Rchari1 · 2026-07-28T21:35:50Z

The reports

"where is our harmoniqs cloud, where can I put an API key in"
"I literally tried to switch to piccolissimo and it did not ask me for an API key"
"it's not a prompt that should ask, it should be integrated in like how pasqal is connected"

Why both happened

Both trace to amicode#200, and neither was a broken wire.

statusTabConnections()filtered company-compute out of the Connections tab and connectionTitle() renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation — one credential for one service, not a second product. The effect was not: Pasqal Cloud rendered as a connectable service in the place that lists clouds, and ours did not. So people went looking for Harmoniqs Cloud exactly where Pasqal is, and found nothing.

Report 2 has a different cause and is not a bug: with a valid key on file hpClickAction("connected") returns "activate", so clicking HP switches immediately instead of re-asking. Correct — but the status dot lived inside the collapsed card, so the row had no way to say "you're already connected," and a successful switch was indistinguishable from a no-op. (Verified live: the server reported company-compute → state: "connected", identity raghav-internal.)

Changes

statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, using the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this un-hides a working flow rather than building a new one. Kept as a function so there's still one obvious place to filter a genuinely internal connection later.
connectionTitle() → "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate).
The solver row states its connection state — CONNECTED / CHECK KEY / ADD KEY. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, words survive colour-blindness and a screenshot, and it says what a click will do.
HP row tooltips name Harmoniqs Cloud, and the connected one states the consequence: every solve on this solver runs there.

Not changed

The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points (tab and capsule) write the same credential, so connecting in either shows up in both.

Testing

ui: 57 pass. turbo typecheck: 23/23. Strings verified present in the built darwin-arm64 binary, which is vendored and serving the running dev host.

The two filter tests that pinned #200's removal are rewritten to pin the opposite, with the regression spelled out — including that a compute-only list must still render a card rather than hit the empty state.

Reviewer note

This reverses a deliberate #200 decision (Kate's, on presentation grounds). Worth a look from her: the disagreement is only about where the credential is entered, not about the one-credential model, and the capsule affordance is untouched.

The solver row said "API key connected" and "Runs in the cloud" — which cloud was never stated, on the one control where a user commits to a paid service. Every refusal they can hit downstream now says "Harmoniqs Cloud" (amico-run's local-launch refusal, the hpc gate), so the control that sends them there should use the same name. The connected tooltip also states the consequence — every solve on this solver runs there — since that is the thing users were guessing about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Reported: "where is our harmoniqs cloud, where can I put an API key in" — and separately, switching to Piccolissimo + Altissimo appeared to do nothing. Both trace to amicode#200. It filtered company-compute OUT of the Connections tab and renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation (one credential for one service, not a second product), but the result was that Pasqal Cloud rendered as a connectable service in the place that lists clouds and OURS did not. Users went looking for it exactly where Pasqal is. - statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, with the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this is un-hiding a working flow, not building a new one. Kept as a function so there is still one obvious place to filter a genuinely internal connection later. - connectionTitle() returns "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate). - The solver row now states its connection state (CONNECTED / CHECK KEY / ADD KEY). With a key already on file, clicking HP correctly activates without re-asking — but the status dot lived inside the collapsed card, so the row had no way to say so and a successful switch was indistinguishable from a no-op. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, and words survive colour-blindness and a screenshot. It also says what a click will do. The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points write the same credential, so connecting in either shows up in both. ui: 57 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Rchari1 · 2026-07-28T21:35:50Z

The reports

"where is our harmoniqs cloud, where can I put an API key in"
"I literally tried to switch to piccolissimo and it did not ask me for an API key"
"it's not a prompt that should ask, it should be integrated in like how pasqal is connected"

Why both happened

Both trace to amicode#200, and neither was a broken wire.

statusTabConnections()filtered company-compute out of the Connections tab and connectionTitle() renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation — one credential for one service, not a second product. The effect was not: Pasqal Cloud rendered as a connectable service in the place that lists clouds, and ours did not. So people went looking for Harmoniqs Cloud exactly where Pasqal is, and found nothing.

Report 2 has a different cause and is not a bug: with a valid key on file hpClickAction("connected") returns "activate", so clicking HP switches immediately instead of re-asking. Correct — but the status dot lived inside the collapsed card, so the row had no way to say "you're already connected," and a successful switch was indistinguishable from a no-op. (Verified live: the server reported company-compute → state: "connected", identity raghav-internal.)

Changes

statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, using the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this un-hides a working flow rather than building a new one. Kept as a function so there's still one obvious place to filter a genuinely internal connection later.
connectionTitle() → "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate).
The solver row states its connection state — CONNECTED / CHECK KEY / ADD KEY. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, words survive colour-blindness and a screenshot, and it says what a click will do.
HP row tooltips name Harmoniqs Cloud, and the connected one states the consequence: every solve on this solver runs there.

Not changed

The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points (tab and capsule) write the same credential, so connecting in either shows up in both.

Testing

ui: 57 pass. turbo typecheck: 23/23. Strings verified present in the built darwin-arm64 binary, which is vendored and serving the running dev host.

The two filter tests that pinned #200's removal are rewritten to pin the opposite, with the regression spelled out — including that a compute-only list must still render a card rather than hit the empty state.

Reviewer note

This reverses a deliberate #200 decision (Kate's, on presentation grounds). Worth a look from her: the disagreement is only about where the credential is entered, not about the one-credential model, and the capsule affordance is untouched.

The solver row said "API key connected" and "Runs in the cloud" — which cloud was never stated, on the one control where a user commits to a paid service. Every refusal they can hit downstream now says "Harmoniqs Cloud" (amico-run's local-launch refusal, the hpc gate), so the control that sends them there should use the same name. The connected tooltip also states the consequence — every solve on this solver runs there — since that is the thing users were guessing about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Reported: "where is our harmoniqs cloud, where can I put an API key in" — and separately, switching to Piccolissimo + Altissimo appeared to do nothing. Both trace to amicode#200. It filtered company-compute OUT of the Connections tab and renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation (one credential for one service, not a second product), but the result was that Pasqal Cloud rendered as a connectable service in the place that lists clouds and OURS did not. Users went looking for it exactly where Pasqal is. - statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, with the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this is un-hiding a working flow, not building a new one. Kept as a function so there is still one obvious place to filter a genuinely internal connection later. - connectionTitle() returns "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate). - The solver row now states its connection state (CONNECTED / CHECK KEY / ADD KEY). With a key already on file, clicking HP correctly activates without re-asking — but the status dot lived inside the collapsed card, so the row had no way to say so and a successful switch was indistinguishable from a no-op. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, and words survive colour-blindness and a screenshot. It also says what a click will do. The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points write the same credential, so connecting in either shows up in both. ui: 57 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Rchari1 · 2026-07-28T21:35:50Z

The reports

"where is our harmoniqs cloud, where can I put an API key in"
"I literally tried to switch to piccolissimo and it did not ask me for an API key"
"it's not a prompt that should ask, it should be integrated in like how pasqal is connected"

Why both happened

Both trace to amicode#200, and neither was a broken wire.

statusTabConnections()filtered company-compute out of the Connections tab and connectionTitle() renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation — one credential for one service, not a second product. The effect was not: Pasqal Cloud rendered as a connectable service in the place that lists clouds, and ours did not. So people went looking for Harmoniqs Cloud exactly where Pasqal is, and found nothing.

Report 2 has a different cause and is not a bug: with a valid key on file hpClickAction("connected") returns "activate", so clicking HP switches immediately instead of re-asking. Correct — but the status dot lived inside the collapsed card, so the row had no way to say "you're already connected," and a successful switch was indistinguishable from a no-op. (Verified live: the server reported company-compute → state: "connected", identity raghav-internal.)

Changes

statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, using the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this un-hides a working flow rather than building a new one. Kept as a function so there's still one obvious place to filter a genuinely internal connection later.
connectionTitle() → "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate).
The solver row states its connection state — CONNECTED / CHECK KEY / ADD KEY. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, words survive colour-blindness and a screenshot, and it says what a click will do.
HP row tooltips name Harmoniqs Cloud, and the connected one states the consequence: every solve on this solver runs there.

Not changed

The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points (tab and capsule) write the same credential, so connecting in either shows up in both.

Testing

ui: 57 pass. turbo typecheck: 23/23. Strings verified present in the built darwin-arm64 binary, which is vendored and serving the running dev host.

The two filter tests that pinned #200's removal are rewritten to pin the opposite, with the regression spelled out — including that a compute-only list must still render a card rather than hit the empty state.

Reviewer note

This reverses a deliberate #200 decision (Kate's, on presentation grounds). Worth a look from her: the disagreement is only about where the credential is entered, not about the one-credential model, and the capsule affordance is untouched.

The solver row said "API key connected" and "Runs in the cloud" — which cloud was never stated, on the one control where a user commits to a paid service. Every refusal they can hit downstream now says "Harmoniqs Cloud" (amico-run's local-launch refusal, the hpc gate), so the control that sends them there should use the same name. The connected tooltip also states the consequence — every solve on this solver runs there — since that is the thing users were guessing about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Reported: "where is our harmoniqs cloud, where can I put an API key in" — and separately, switching to Piccolissimo + Altissimo appeared to do nothing. Both trace to amicode#200. It filtered company-compute OUT of the Connections tab and renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation (one credential for one service, not a second product), but the result was that Pasqal Cloud rendered as a connectable service in the place that lists clouds and OURS did not. Users went looking for it exactly where Pasqal is. - statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, with the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this is un-hiding a working flow, not building a new one. Kept as a function so there is still one obvious place to filter a genuinely internal connection later. - connectionTitle() returns "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate). - The solver row now states its connection state (CONNECTED / CHECK KEY / ADD KEY). With a key already on file, clicking HP correctly activates without re-asking — but the status dot lived inside the collapsed card, so the row had no way to say so and a successful switch was indistinguishable from a no-op. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, and words survive colour-blindness and a screenshot. It also says what a click will do. The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points write the same credential, so connecting in either shows up in both. ui: 57 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Rchari1 · 2026-07-28T21:35:50Z

The reports

"where is our harmoniqs cloud, where can I put an API key in"
"I literally tried to switch to piccolissimo and it did not ask me for an API key"
"it's not a prompt that should ask, it should be integrated in like how pasqal is connected"

Why both happened

Both trace to amicode#200, and neither was a broken wire.

statusTabConnections()filtered company-compute out of the Connections tab and connectionTitle() renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation — one credential for one service, not a second product. The effect was not: Pasqal Cloud rendered as a connectable service in the place that lists clouds, and ours did not. So people went looking for Harmoniqs Cloud exactly where Pasqal is, and found nothing.

Report 2 has a different cause and is not a bug: with a valid key on file hpClickAction("connected") returns "activate", so clicking HP switches immediately instead of re-asking. Correct — but the status dot lived inside the collapsed card, so the row had no way to say "you're already connected," and a successful switch was indistinguishable from a no-op. (Verified live: the server reported company-compute → state: "connected", identity raghav-internal.)

Changes

statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, using the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this un-hides a working flow rather than building a new one. Kept as a function so there's still one obvious place to filter a genuinely internal connection later.
connectionTitle() → "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate).
The solver row states its connection state — CONNECTED / CHECK KEY / ADD KEY. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, words survive colour-blindness and a screenshot, and it says what a click will do.
HP row tooltips name Harmoniqs Cloud, and the connected one states the consequence: every solve on this solver runs there.

Not changed

The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points (tab and capsule) write the same credential, so connecting in either shows up in both.

Testing

ui: 57 pass. turbo typecheck: 23/23. Strings verified present in the built darwin-arm64 binary, which is vendored and serving the running dev host.

The two filter tests that pinned #200's removal are rewritten to pin the opposite, with the regression spelled out — including that a compute-only list must still render a card rather than hit the empty state.

Reviewer note

This reverses a deliberate #200 decision (Kate's, on presentation grounds). Worth a look from her: the disagreement is only about where the credential is entered, not about the one-credential model, and the capsule affordance is untouched.

The solver row said "API key connected" and "Runs in the cloud" — which cloud was never stated, on the one control where a user commits to a paid service. Every refusal they can hit downstream now says "Harmoniqs Cloud" (amico-run's local-launch refusal, the hpc gate), so the control that sends them there should use the same name. The connected tooltip also states the consequence — every solve on this solver runs there — since that is the thing users were guessing about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Reported: "where is our harmoniqs cloud, where can I put an API key in" — and separately, switching to Piccolissimo + Altissimo appeared to do nothing. Both trace to amicode#200. It filtered company-compute OUT of the Connections tab and renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation (one credential for one service, not a second product), but the result was that Pasqal Cloud rendered as a connectable service in the place that lists clouds and OURS did not. Users went looking for it exactly where Pasqal is. - statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, with the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this is un-hiding a working flow, not building a new one. Kept as a function so there is still one obvious place to filter a genuinely internal connection later. - connectionTitle() returns "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate). - The solver row now states its connection state (CONNECTED / CHECK KEY / ADD KEY). With a key already on file, clicking HP correctly activates without re-asking — but the status dot lived inside the collapsed card, so the row had no way to say so and a successful switch was indistinguishable from a no-op. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, and words survive colour-blindness and a screenshot. It also says what a click will do. The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points write the same credential, so connecting in either shows up in both. ui: 57 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Rchari1 · 2026-07-28T21:35:50Z

The reports

"where is our harmoniqs cloud, where can I put an API key in"
"I literally tried to switch to piccolissimo and it did not ask me for an API key"
"it's not a prompt that should ask, it should be integrated in like how pasqal is connected"

Why both happened

Both trace to amicode#200, and neither was a broken wire.

statusTabConnections()filtered company-compute out of the Connections tab and connectionTitle() renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation — one credential for one service, not a second product. The effect was not: Pasqal Cloud rendered as a connectable service in the place that lists clouds, and ours did not. So people went looking for Harmoniqs Cloud exactly where Pasqal is, and found nothing.

Report 2 has a different cause and is not a bug: with a valid key on file hpClickAction("connected") returns "activate", so clicking HP switches immediately instead of re-asking. Correct — but the status dot lived inside the collapsed card, so the row had no way to say "you're already connected," and a successful switch was indistinguishable from a no-op. (Verified live: the server reported company-compute → state: "connected", identity raghav-internal.)

Changes

statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, using the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this un-hides a working flow rather than building a new one. Kept as a function so there's still one obvious place to filter a genuinely internal connection later.
connectionTitle() → "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate).
The solver row states its connection state — CONNECTED / CHECK KEY / ADD KEY. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, words survive colour-blindness and a screenshot, and it says what a click will do.
HP row tooltips name Harmoniqs Cloud, and the connected one states the consequence: every solve on this solver runs there.

Not changed

The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points (tab and capsule) write the same credential, so connecting in either shows up in both.

Testing

ui: 57 pass. turbo typecheck: 23/23. Strings verified present in the built darwin-arm64 binary, which is vendored and serving the running dev host.

The two filter tests that pinned #200's removal are rewritten to pin the opposite, with the regression spelled out — including that a compute-only list must still render a card rather than hit the empty state.

Reviewer note

This reverses a deliberate #200 decision (Kate's, on presentation grounds). Worth a look from her: the disagreement is only about where the credential is entered, not about the one-credential model, and the capsule affordance is untouched.

The solver row said "API key connected" and "Runs in the cloud" — which cloud was never stated, on the one control where a user commits to a paid service. Every refusal they can hit downstream now says "Harmoniqs Cloud" (amico-run's local-launch refusal, the hpc gate), so the control that sends them there should use the same name. The connected tooltip also states the consequence — every solve on this solver runs there — since that is the thing users were guessing about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Reported: "where is our harmoniqs cloud, where can I put an API key in" — and separately, switching to Piccolissimo + Altissimo appeared to do nothing. Both trace to amicode#200. It filtered company-compute OUT of the Connections tab and renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation (one credential for one service, not a second product), but the result was that Pasqal Cloud rendered as a connectable service in the place that lists clouds and OURS did not. Users went looking for it exactly where Pasqal is. - statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, with the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this is un-hiding a working flow, not building a new one. Kept as a function so there is still one obvious place to filter a genuinely internal connection later. - connectionTitle() returns "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate). - The solver row now states its connection state (CONNECTED / CHECK KEY / ADD KEY). With a key already on file, clicking HP correctly activates without re-asking — but the status dot lived inside the collapsed card, so the row had no way to say so and a successful switch was indistinguishable from a no-op. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, and words survive colour-blindness and a screenshot. It also says what a click will do. The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points write the same credential, so connecting in either shows up in both. ui: 57 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Rchari1 · 2026-07-28T21:35:50Z

The reports

"where is our harmoniqs cloud, where can I put an API key in"
"I literally tried to switch to piccolissimo and it did not ask me for an API key"
"it's not a prompt that should ask, it should be integrated in like how pasqal is connected"

Why both happened

Both trace to amicode#200, and neither was a broken wire.

statusTabConnections()filtered company-compute out of the Connections tab and connectionTitle() renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation — one credential for one service, not a second product. The effect was not: Pasqal Cloud rendered as a connectable service in the place that lists clouds, and ours did not. So people went looking for Harmoniqs Cloud exactly where Pasqal is, and found nothing.

Report 2 has a different cause and is not a bug: with a valid key on file hpClickAction("connected") returns "activate", so clicking HP switches immediately instead of re-asking. Correct — but the status dot lived inside the collapsed card, so the row had no way to say "you're already connected," and a successful switch was indistinguishable from a no-op. (Verified live: the server reported company-compute → state: "connected", identity raghav-internal.)

Changes

statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, using the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this un-hides a working flow rather than building a new one. Kept as a function so there's still one obvious place to filter a genuinely internal connection later.
connectionTitle() → "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate).
The solver row states its connection state — CONNECTED / CHECK KEY / ADD KEY. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, words survive colour-blindness and a screenshot, and it says what a click will do.
HP row tooltips name Harmoniqs Cloud, and the connected one states the consequence: every solve on this solver runs there.

Not changed

The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points (tab and capsule) write the same credential, so connecting in either shows up in both.

Testing

ui: 57 pass. turbo typecheck: 23/23. Strings verified present in the built darwin-arm64 binary, which is vendored and serving the running dev host.

The two filter tests that pinned #200's removal are rewritten to pin the opposite, with the regression spelled out — including that a compute-only list must still render a card rather than hit the empty state.

Reviewer note

This reverses a deliberate #200 decision (Kate's, on presentation grounds). Worth a look from her: the disagreement is only about where the credential is entered, not about the one-credential model, and the capsule affordance is untouched.

The solver row said "API key connected" and "Runs in the cloud" — which cloud was never stated, on the one control where a user commits to a paid service. Every refusal they can hit downstream now says "Harmoniqs Cloud" (amico-run's local-launch refusal, the hpc gate), so the control that sends them there should use the same name. The connected tooltip also states the consequence — every solve on this solver runs there — since that is the thing users were guessing about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Reported: "where is our harmoniqs cloud, where can I put an API key in" — and separately, switching to Piccolissimo + Altissimo appeared to do nothing. Both trace to amicode#200. It filtered company-compute OUT of the Connections tab and renamed it "Solver API key", moving the whole connect flow inside the solver capsule's collapsed card. The reasoning was sound in isolation (one credential for one service, not a second product), but the result was that Pasqal Cloud rendered as a connectable service in the place that lists clouds and OURS did not. Users went looking for it exactly where Pasqal is. - statusTabConnections() no longer filters. Harmoniqs Cloud renders as a card beside Pasqal Cloud, with the base-url-token form (Service URL + API key) the tab already supported for non-Pasqal ids — so this is un-hiding a working flow, not building a new one. Kept as a function so there is still one obvious place to filter a genuinely internal connection later. - connectionTitle() returns "Harmoniqs Cloud". In a list whose other entry is "Pasqal Cloud", "Solver API key" read as a settings field rather than our service — and Harmoniqs Cloud is the name every downstream refusal already uses (amico-run's local-launch refusal, the hpc gate). - The solver row now states its connection state (CONNECTED / CHECK KEY / ADD KEY). With a key already on file, clicking HP correctly activates without re-asking — but the status dot lived inside the collapsed card, so the row had no way to say so and a successful switch was indistinguishable from a no-op. Text rather than a bare dot: Kate's idiom is that the dot accompanies words, and words survive colour-blindness and a screenshot. It also says what a click will do. The wire id stays company-compute — renaming it would break the credential route, the status cache, and CONNECTION_IDS for no user-visible gain. Both entry points write the same credential, so connecting in either shows up in both. ui: 57 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Rchari1 changed the title ~~style(capsule): the HP row names Harmoniqs Cloud~~feat(connections): Harmoniqs Cloud is connectable where Pasqal isJul 28, 2026

Rchari1and others added 2 commits July 28, 2026 18:51

jack-champagne force-pushed the rchari/harmoniqs-cloud-copy branch from 7eab475 to 67bfdf7Compare July 28, 2026 22:52

jack-champagne merged commit 95e915e into local/amicodeJul 29, 2026
1 of 5 checks passed

Rchari1 changed the title ~~style(capsule): the HP row names Harmoniqs Cloud~~feat(connections): Harmoniqs Cloud is connectable where Pasqal isJul 28, 2026

Rchari1and others added 2 commits July 28, 2026 18:51

jack-champagne force-pushed the rchari/harmoniqs-cloud-copy branch from 7eab475 to 67bfdf7Compare July 28, 2026 22:52

jack-champagne merged commit 95e915e into local/amicodeJul 29, 2026
1 of 5 checks passed

Rchari1 changed the title ~~style(capsule): the HP row names Harmoniqs Cloud~~feat(connections): Harmoniqs Cloud is connectable where Pasqal isJul 28, 2026

Rchari1and others added 2 commits July 28, 2026 18:51

jack-champagne force-pushed the rchari/harmoniqs-cloud-copy branch from 7eab475 to 67bfdf7Compare July 28, 2026 22:52

jack-champagne merged commit 95e915e into local/amicodeJul 29, 2026
1 of 5 checks passed

Rchari1 changed the title ~~style(capsule): the HP row names Harmoniqs Cloud~~feat(connections): Harmoniqs Cloud is connectable where Pasqal isJul 28, 2026

Rchari1and others added 2 commits July 28, 2026 18:51

jack-champagne force-pushed the rchari/harmoniqs-cloud-copy branch from 7eab475 to 67bfdf7Compare July 28, 2026 22:52

jack-champagne merged commit 95e915e into local/amicodeJul 29, 2026
1 of 5 checks passed

Rchari1 changed the title ~~style(capsule): the HP row names Harmoniqs Cloud~~feat(connections): Harmoniqs Cloud is connectable where Pasqal isJul 28, 2026

Rchari1and others added 2 commits July 28, 2026 18:51

jack-champagne force-pushed the rchari/harmoniqs-cloud-copy branch from 7eab475 to 67bfdf7Compare July 28, 2026 22:52

jack-champagne merged commit 95e915e into local/amicodeJul 29, 2026
1 of 5 checks passed

Rchari1 changed the title ~~style(capsule): the HP row names Harmoniqs Cloud~~feat(connections): Harmoniqs Cloud is connectable where Pasqal isJul 28, 2026

Rchari1and others added 2 commits July 28, 2026 18:51

jack-champagne force-pushed the rchari/harmoniqs-cloud-copy branch from 7eab475 to 67bfdf7Compare July 28, 2026 22:52

jack-champagne merged commit 95e915e into local/amicodeJul 29, 2026
1 of 5 checks passed

Rchari1 changed the title ~~style(capsule): the HP row names Harmoniqs Cloud~~feat(connections): Harmoniqs Cloud is connectable where Pasqal isJul 28, 2026

Rchari1and others added 2 commits July 28, 2026 18:51

jack-champagne force-pushed the rchari/harmoniqs-cloud-copy branch from 7eab475 to 67bfdf7Compare July 28, 2026 22:52

jack-champagne merged commit 95e915e into local/amicodeJul 29, 2026
1 of 5 checks passed

Rchari1 changed the title ~~style(capsule): the HP row names Harmoniqs Cloud~~feat(connections): Harmoniqs Cloud is connectable where Pasqal isJul 28, 2026

Rchari1and others added 2 commits July 28, 2026 18:51

jack-champagne force-pushed the rchari/harmoniqs-cloud-copy branch from 7eab475 to 67bfdf7Compare July 28, 2026 22:52

jack-champagne merged commit 95e915e into local/amicodeJul 29, 2026
1 of 5 checks passed

Uh oh!

Conversation

Rchari1 commented Jul 28, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The reports

Why both happened

Changes

Not changed

Testing

Reviewer note

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Rchari1 commented Jul 28, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The reports

Why both happened

Changes

Not changed

Testing

Reviewer note

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Rchari1 commented Jul 28, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The reports

Why both happened

Changes

Not changed

Testing

Reviewer note

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Rchari1 commented Jul 28, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The reports

Why both happened

Changes

Not changed

Testing

Reviewer note

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Rchari1 commented Jul 28, 2026•
edited
Loading

Rchari1 commented Jul 28, 2026•
edited
Loading

Rchari1 commented Jul 28, 2026•
edited
Loading

Rchari1 commented Jul 28, 2026•
edited
Loading

Rchari1 commented Jul 28, 2026•
edited
Loading

Rchari1 commented Jul 28, 2026•
edited
Loading