coilyco-gaming/sirens-echo

Watch

The limiter admits fewer turns than the values file configures #164

New issue

Closed

opened 2026-08-12 17:51:16 +00:00 by coilysiren · 7 comments

coilysiren commented

2026-08-12 17:51:16 +00:00

Owner

Deployment sets SIRENS_ECHO_RATE_USER=15/15s and SIRENS_ECHO_RATE_CONTEXT=25/10s. A 30-way concurrent burst admitted 8 and rejected 22 with 429 — below both tiers.

The rejection behavior itself is good: immediate, correct status, no model spend. But the admitted count not matching either configured tier is worth understanding before #135 and #136 put a whole channel behind it — the values file's own comment warns that admission is the only bound on spend.
RecommendationConfirm whether the tiers are token buckets with a smaller burst capacity than steady rate, and document the real burst ceiling next to the env vars.

Deployment sets SIRENS_ECHO_RATE_USER=15/15s and SIRENS_ECHO_RATE_CONTEXT=25/10s. A 30-way concurrent burst admitted 8 and rejected 22 with 429 — below both tiers. The rejection behavior itself is good: immediate, correct status, no model spend. But the admitted count not matching either configured tier is worth understanding before #135 and #136 put a whole channel behind it — the values file's own comment warns that admission is the only bound on spend. RecommendationConfirm whether the tiers are token buckets with a smaller burst capacity than steady rate, and document the real burst ceiling next to the env vars.

coilyco-ops referenced this issue

2026-08-12 18:28:40 +00:00

sirens-deep: configuration to operate in guild channels, not DM-only #135

coilyco-ops referenced this issue

2026-08-12 18:31:06 +00:00

Client input errors are counted as service errors, inflating the error rate to 14.58% #159

coilyco-ops commented

2026-08-12 18:33:24 +00:00

Member

Why this got more urgent four hours after it was filed

This issue says the mismatch is worth understanding before #135 and #136 put a whole channel behind the limiter.

coilyco-bridge/deploy#396 merged at 17:30:28Z. The guild entry is live.

The saving grace is that #396 named its members explicitly rather than using all:

        users:
          - "318190481467244544"

One account, so the elevated tiers still effectively mean "the operator" and nothing has changed in practice yet. But the sequencing this issue asked for did not happen, and two open issues remove the saving grace by design: #136 makes the trusted user a list, and #153 adds agents.allow, admitting counterpart agents.

The instruction that was skipped, which compounds this

sirens-deep-values.yaml:24 says a guild entry should lower the rates or set a per-guild rate_limit.per_user in the same change. #396 did neither, and the merged policy has no rate_limit block. Recorded on #135.

So the widened surface, when it arrives, will run on tiers that are both undocumented in their real ceiling (this issue) and not lowered as instructed (#135). Those are two separate problems that will land together.

What still needs a code read

I cannot answer the mechanism from here. Stating what would settle it rather than guessing:

Whether the tiers are token buckets whose capacity differs from the steady rate, which is the recommendation's hypothesis and the usual cause of an under-admitting burst.
Whether the two tiers compose rather than alternate, so a request consumes from both SIRENS_ECHO_RATE_USER and SIRENS_ECHO_RATE_CONTEXT and the effective ceiling is lower than either.
Whether the single-slot turn serialization interacts with admission. Turns are serialized on one slot with a 30 second queue timeout, so a 30-way concurrent burst is contending for one worker. The report says the 22 rejections were 429 rather than timeouts, which points at the limiter rather than the queue, but the two paths are worth separating explicitly in the answer.

8 admitted matches neither 15 nor 25, so whatever the explanation is, it is not a simple reading of either configured value.

Acceptance

The real burst ceiling is stated as a number, with the mechanism that produces it.
It is documented next to the env vars in sirens-deep-values.yaml, where the person setting them will read it, rather than only here.
If the configured values cannot produce the documented behaviour, that is a bug rather than a documentation gap, and it gets its own fix.

Not a defect in the rejection path

Restating, because it is easy to lose: the refusal behaviour is good. Immediate, correct status, no model spend. This issue is about the admitted count being unexplainable, not about anything failing.

## Why this got more urgent four hours after it was filed This issue says the mismatch is worth understanding **before** #135 and #136 put a whole channel behind the limiter. `coilyco-bridge/deploy#396` merged at **17:30:28Z**. The guild entry is live. The saving grace is that #396 named its members explicitly rather than using `all`: ```yaml users: - "318190481467244544" ``` One account, so the elevated tiers still effectively mean "the operator" and nothing has changed in practice yet. But the sequencing this issue asked for did not happen, and two open issues remove the saving grace by design: **#136** makes the trusted user a list, and **#153** adds `agents.allow`, admitting counterpart agents. ## The instruction that was skipped, which compounds this `sirens-deep-values.yaml:24` says a guild entry should lower the rates or set a per-guild `rate_limit.per_user` **in the same change**. #396 did neither, and the merged policy has no `rate_limit` block. Recorded on #135. So the widened surface, when it arrives, will run on tiers that are both **undocumented in their real ceiling** (this issue) and **not lowered as instructed** (#135). Those are two separate problems that will land together. ## What still needs a code read I cannot answer the mechanism from here. Stating what would settle it rather than guessing: * Whether the tiers are token buckets whose **capacity differs from the steady rate**, which is the recommendation's hypothesis and the usual cause of an under-admitting burst. * Whether the two tiers **compose rather than alternate**, so a request consumes from both `SIRENS_ECHO_RATE_USER` and `SIRENS_ECHO_RATE_CONTEXT` and the effective ceiling is lower than either. * Whether the **single-slot turn serialization** interacts with admission. Turns are serialized on one slot with a 30 second queue timeout, so a 30-way concurrent burst is contending for one worker. The report says the 22 rejections were 429 rather than timeouts, which points at the limiter rather than the queue, but the two paths are worth separating explicitly in the answer. 8 admitted matches neither 15 nor 25, so whatever the explanation is, it is not a simple reading of either configured value. ## Acceptance * The real burst ceiling is stated as a number, with the mechanism that produces it. * It is documented next to the env vars in `sirens-deep-values.yaml`, where the person setting them will read it, rather than only here. * If the configured values cannot produce the documented behaviour, that is a bug rather than a documentation gap, and it gets its own fix. ## Not a defect in the rejection path Restating, because it is easy to lose: the refusal behaviour is good. Immediate, correct status, no model spend. This issue is about the admitted count being unexplainable, not about anything failing.

coilyco-ops referenced this issue

2026-08-12 20:35:35 +00:00

Bound agent-to-agent exchanges: ignore bot-authored messages unless allowlisted, plus a per-channel turn cap #172

coilyco-ops commented

2026-08-13 08:08:28 +00:00

Member

Design decision — re-measure after the rate tiers are set explicitly

Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-12.

Decided: land the explicit rate-tier configuration first, then re-measure admission. Kai rejected assuming this is the same bug and closing both together, and rejected opening an independent limiter investigation now.

The sequencing: coilyco-bridge/deploy#412 sets SIRENS_ECHO_RATE_USER, SIRENS_ECHO_RATE_CONTEXT, and SIRENS_ECHO_RATE_GLOBAL all explicitly in Deep's values, with no tier inherited from the package. Once that lands, measure admission again.

If admission now matches configuration, this closes for free — the symptom was config opacity, not a limiter defect.
If it still admits fewer than configured, there is a real defect, and it is now isolated from the config noise that would otherwise muddy the diagnosis.

Either way the answer is cheap and unambiguous, which is why Kai declined to guess.

Why the two are plausibly the same

412 found that sirens-deep-values.yaml raises the user and context tiers while leaving global silently inherited at the packaged 20/5s. Admit checks every tier before charging any, so the effective ceiling is min(user 15, global 20, context 25) — lower than a reader of the values file would expect, because the binding tier is not written in the file they are reading.

"The limiter admits fewer turns than the values file configures" is a precise description of that situation. Plausible, not established — hence the measurement.

Note for whoever measures

Record the observed admission rate against the configured tiers here, with numbers. That is the evidence this issue closes on, and it is also the evidence 412 needs to confirm its own fix landed correctly. One measurement serves both issues.

Relevant context: Deep's traffic shape has changed since these numbers were set — it is now a guild participant rather than DM-only (coilyco-bridge/deploy#365), though whether guild messages actually reach it is itself unverified (#135). Measure after that question is settled, or the traffic you measure may not be the traffic that matters.

## Design decision — re-measure after the rate tiers are set explicitly Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-12. **Decided: land the explicit rate-tier configuration first, then re-measure admission.** Kai rejected assuming this is the same bug and closing both together, and rejected opening an independent limiter investigation now. **The sequencing:** https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/412 sets `SIRENS_ECHO_RATE_USER`, `SIRENS_ECHO_RATE_CONTEXT`, and `SIRENS_ECHO_RATE_GLOBAL` **all explicitly** in Deep's values, with no tier inherited from the package. Once that lands, measure admission again. - **If admission now matches configuration**, this closes for free — the symptom was config opacity, not a limiter defect. - **If it still admits fewer than configured**, there is a real defect, and it is now isolated from the config noise that would otherwise muddy the diagnosis. Either way the answer is cheap and unambiguous, which is why Kai declined to guess. ### Why the two are plausibly the same 412 found that `sirens-deep-values.yaml` raises the user and context tiers while leaving global silently inherited at the packaged `20/5s`. `Admit` checks every tier before charging any, so the effective ceiling is `min(user 15, global 20, context 25)` — **lower than a reader of the values file would expect**, because the binding tier is not written in the file they are reading. "The limiter admits fewer turns than the values file configures" is a precise description of that situation. Plausible, not established — hence the measurement. ### Note for whoever measures Record the **observed** admission rate against the **configured** tiers here, with numbers. That is the evidence this issue closes on, and it is also the evidence 412 needs to confirm its own fix landed correctly. **One measurement serves both issues.** Relevant context: Deep's traffic shape has changed since these numbers were set — it is now a guild participant rather than DM-only (https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/365), though whether guild messages actually reach it is itself unverified (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/135). **Measure after that question is settled**, or the traffic you measure may not be the traffic that matters.

coilyco-ops added the

autonomy

headless

label

2026-08-13 11:04:41 +00:00

coilyco-ops commented

2026-08-13 11:17:31 +00:00

Member

Angie (ENG). Answering the mechanism from the code, and taking the documentation criterion. Not the measurement.

Kai's decision is re-measure after the tiers are explicit, and coilyco-bridge/deploy#412 closed, so that precondition is met. The measurement is live work and I am sealed, so it stays with whoever can observe. But two of the three acceptance criteria here do not need a live cluster, and one of them is now answerable.

The real burst ceiling is 8, and it is not a tier

8 admitted matches neither 15 nor 25 because it is not a token bucket at all. AdmissionPolicy.MaxPending defaults to 8 in internal/community/config.go:41, overridable by SIRENS_ECHO_MAX_PENDING. That is your number.

The order in Admit is the part worth knowing:

Every tier's bucket is checked.
The pending cap is checked.
Only then is every tier charged.

So under concurrency the pending cap binds first, and a turn shed by it spends no tokens. The tiers and the pending cap therefore do not compose the way the recommendation's hypothesis assumed. Neither of the three hypotheses in the earlier comment is the cause: the buckets are not capacity-versus-rate mismatched, the tiers do not double-charge, and this is not the single-slot serialization either. QA already observed this directly on coilyco-bridge/deploy#412 - the pending cap bound before any token bucket, accepting exactly 8.

This also tells whoever measures how to read the result

A pending-cap denial reports outcome queue, a tier denial reports its own tier's outcome. They are already distinguishable in the admission metric, so the re-measurement can attribute every rejection without guessing. That matters, because a run that sheds on the pending cap would otherwise look like the tiers are still wrong.

The documentation criterion, which I am taking

Your second criterion is that this is documented next to the env vars where the person setting them will read it. sirens-deep-values.yaml now explains the tiers well and says an unset tier is not a neutral tier. SIRENS_ECHO_MAX_PENDING is not set there and not mentioned, so the file teaches that lesson and then has the same gap one layer over: the bound that actually binds is the one not in the file.

Filing that against the deploy repo and doing it there. It changes no behaviour, because I am naming the packaged default rather than a new value.

Not claiming this issue. It stays open for the measurement, which is not mine.

**Angie (ENG). Answering the mechanism from the code, and taking the documentation criterion. Not the measurement.** Kai's decision is re-measure after the tiers are explicit, and https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/412 closed, so that precondition is met. The measurement is live work and I am sealed, so it stays with whoever can observe. But two of the three acceptance criteria here do not need a live cluster, and one of them is now answerable. ## The real burst ceiling is 8, and it is not a tier `8 admitted matches neither 15 nor 25` because it is not a token bucket at all. `AdmissionPolicy.MaxPending` defaults to **8** in `internal/community/config.go:41`, overridable by `SIRENS_ECHO_MAX_PENDING`. That is your number. The order in `Admit` is the part worth knowing: 1. Every tier's bucket is **checked**. 2. The pending cap is checked. 3. Only then is every tier **charged**. So under concurrency the pending cap binds first, and a turn shed by it **spends no tokens**. The tiers and the pending cap therefore do not compose the way the recommendation's hypothesis assumed. Neither of the three hypotheses in the earlier comment is the cause: the buckets are not capacity-versus-rate mismatched, the tiers do not double-charge, and this is not the single-slot serialization either. QA already observed this directly on https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/412 - `the pending cap bound before any token bucket, accepting exactly 8`. ## This also tells whoever measures how to read the result A pending-cap denial reports outcome `queue`, a tier denial reports its own tier's outcome. They are already distinguishable in the admission metric, so the re-measurement can attribute every rejection without guessing. That matters, because a run that sheds on the pending cap would otherwise look like the tiers are still wrong. ## The documentation criterion, which I am taking Your second criterion is that this is documented next to the env vars where the person setting them will read it. `sirens-deep-values.yaml` now explains the tiers well and says **an unset tier is not a neutral tier**. `SIRENS_ECHO_MAX_PENDING` is not set there and not mentioned, so the file teaches that lesson and then has the same gap one layer over: the bound that actually binds is the one not in the file. Filing that against the deploy repo and doing it there. It changes no behaviour, because I am naming the packaged default rather than a new value. **Not claiming this issue.** It stays open for the measurement, which is not mine.

coilyco-ops added

and removed

labels

2026-08-13 13:48:49 +00:00

coilyco-ops commented

2026-08-13 13:49:12 +00:00

Member

Relabelled headless to consult, and closing out my own commitment here — Angie (ENG, claude seat).

Three acceptance criteria. Two are met and the third is not available.

The mechanism is answered above: the real burst ceiling is MaxPending, defaulting to 8, and the pending cap binds before any tier charges — so a shed turn spends no tokens and the tiers never composed the way the hypothesis assumed.

The documentation criterion I said I would take and file against deploy: done. coilyco-bridge/deploy#442 is closed, including an Olaf correction to my reasoning that was right. I am noting that here because I said I would do it in another repo, and an unfinished commitment made in one tracker and completed in another is invisible unless someone says so.

The measurement is live work against a route that does not answer, and it is not mine either way — I am sealed from live observation. That is external action must happen first, so headless was advertising this as finishable by an agent and it is not.

Nothing here needs Kai. It needs the Echo lane back, which is coilyco-bridge/deploy#437, closed at 08:31 on an attribution three afternoon probes disproved.

**Relabelled `headless` to `consult`, and closing out my own commitment here — Angie (ENG, claude seat).** Three acceptance criteria. Two are met and the third is not available. **The mechanism** is answered above: the real burst ceiling is `MaxPending`, defaulting to 8, and the pending cap binds before any tier charges — so a shed turn spends no tokens and the tiers never composed the way the hypothesis assumed. **The documentation criterion** I said I would take and file against deploy: done. https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/442 is closed, including an Olaf correction to my reasoning that was right. I am noting that here because I said I would do it in another repo, and an unfinished commitment made in one tracker and completed in another is invisible unless someone says so. **The measurement** is live work against a route that does not answer, and it is not mine either way — I am sealed from live observation. That is *external action must happen first*, so `headless` was advertising this as finishable by an agent and it is not. Nothing here needs Kai. It needs the Echo lane back, which is https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/437, closed at 08:31 on an attribution three afternoon probes disproved.

coilyco-ops referenced this issue

2026-08-13 15:08:12 +00:00

The consult label drifts from reality in both directions, so the human queue is wrong twice over #437

coilyco-ops commented

2026-08-13 15:20:05 +00:00

Member

The measurement. Angie (ENG) · seat claude-macos-…-ee99, read-only SigNoz.

A previous seat of mine wrote "the measurement is live work and I am sealed" and left the third criterion open. This seat is not sealed — read-only observability is inside the Engineer lane, and it is the only thing this issue was waiting on. So here it is.

Observed admission, 24h, `sirens_echo.admissions`

accepted        523
denied_queue    120
denied_user      66
denied_context    0
denied_global     0

Split by transport, as a share of that transport's decisions:

	accepted	denied_queue	denied_user
discord	83.9%	11.9%	4.2%
http	65.9%	20.8%	13.3%

This confirms the code reading rather than the hypotheses

The earlier comment offered three candidate mechanisms: buckets whose capacity differs from the steady rate, tiers that compose rather than alternate, and the single-slot serialization. None of them. The mechanism my earlier seat read out of Admit is what the numbers show:

denied_queue is the largest denial class on both transports. That is MaxPending, default 8, and it is the bound that actually binds. It is not a token bucket, which is why "8 admitted matches neither 15 nor 25" was never going to resolve into a tier.

denied_context and denied_global are zero over a full day. Not small. Zero. The context and global tiers have never bound in this window, so the concern from coilyco-bridge/deploy#412 that a silently inherited global 20/5s was the real ceiling is not what is happening now. Whatever 412 changed, global is not the binding tier today.

denied_user fires and is second. So the per-user tier is real and does bind, at roughly a third of the rate the pending cap does.

Answering the acceptance criteria

The real burst ceiling stated as a number, with the mechanism. 8, from MaxPending, and the mechanism is that the pending cap is checked before any tier is charged, so a shed turn spends no tokens. Now measured as well as read.
Documented next to the env vars. Done earlier, in coilyco-bridge/deploy#442.
If the configured values cannot produce the documented behaviour, that is a bug. They can, and they do. The tiers are not under-admitting. A different bound is binding first, and it is doing exactly what it says.

So this closes, and one thing does not

Kai's decision was: re-measure after the tiers are explicit, and if admission matches configuration this closes for free because the symptom was config opacity rather than a limiter defect. That is the outcome. There is no limiter defect here.

I am not closing it, because it is Kai's issue and the disposition was Kai's to set. It is now a call rather than an open question, which is what the earlier comment asked for.

One thing worth someone's judgement, and it is not this issue's. 120 of 709 decisions in a day were shed by a pending cap of 8 while the configured tiers never bound. That is a service refusing a sixth of its offered load on a bound nobody chose deliberately — MaxPending is a packaged default, not a value in the values file. Whether 8 is right is a separate question from whether it is documented, and only the second has been answered. Happy to file it if anyone wants it as its own item.

**The measurement. Angie (ENG) · seat `claude-macos-…-ee99`, read-only SigNoz.** A previous seat of mine wrote *"the measurement is live work and I am sealed"* and left the third criterion open. **This seat is not sealed** — read-only observability is inside the Engineer lane, and it is the only thing this issue was waiting on. So here it is. ## Observed admission, 24h, `sirens_echo.admissions` ``` accepted 523 denied_queue 120 denied_user 66 denied_context 0 denied_global 0 ``` Split by transport, as a share of that transport's decisions: | | accepted | denied_queue | denied_user | | --- | --- | --- | --- | | discord | 83.9% | 11.9% | 4.2% | | http | 65.9% | 20.8% | 13.3% | ## This confirms the code reading rather than the hypotheses The earlier comment offered three candidate mechanisms: buckets whose capacity differs from the steady rate, tiers that compose rather than alternate, and the single-slot serialization. **None of them.** The mechanism my earlier seat read out of `Admit` is what the numbers show: **`denied_queue` is the largest denial class on both transports.** That is `MaxPending`, default 8, and it is the bound that actually binds. It is not a token bucket, which is why *"8 admitted matches neither 15 nor 25"* was never going to resolve into a tier. **`denied_context` and `denied_global` are zero over a full day.** Not small. Zero. The context and global tiers have never bound in this window, so the concern from https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/412 that a silently inherited global `20/5s` was the real ceiling **is not what is happening now**. Whatever 412 changed, global is not the binding tier today. **`denied_user` fires and is second.** So the per-user tier is real and does bind, at roughly a third of the rate the pending cap does. ## Answering the acceptance criteria - **The real burst ceiling stated as a number, with the mechanism.** 8, from `MaxPending`, and the mechanism is that the pending cap is checked before any tier is charged, so a shed turn spends no tokens. Now measured as well as read. - **Documented next to the env vars.** Done earlier, in https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/442. - **If the configured values cannot produce the documented behaviour, that is a bug.** They can, and they do. The tiers are not under-admitting. A different bound is binding first, and it is doing exactly what it says. ## So this closes, and one thing does not Kai's decision was: re-measure after the tiers are explicit, and if admission matches configuration this closes for free because the symptom was config opacity rather than a limiter defect. **That is the outcome.** There is no limiter defect here. **I am not closing it**, because it is Kai's issue and the disposition was Kai's to set. It is now a call rather than an open question, which is what the earlier comment asked for. **One thing worth someone's judgement, and it is not this issue's.** 120 of 709 decisions in a day were shed by a pending cap of 8 while the configured tiers never bound. That is a service refusing a sixth of its offered load on a bound nobody chose deliberately — `MaxPending` is a packaged default, not a value in the values file. Whether 8 is right is a separate question from whether it is documented, and only the second has been answered. Happy to file it if anyone wants it as its own item.

coilyco-ops referenced this issue

2026-08-13 15:20:40 +00:00

A sixth of offered load is shed by a pending cap nobody chose, while every configured tier sits idle #532

coilyco-ops commented

2026-08-13 15:24:51 +00:00

Member

Removing consult in the same call as the record, which is the habit docs/sirens-echo-consult-gate.md asks for. Angie (ENG) · seat claude-macos-…-ee99.

consult means a human decision, design, or external action must happen first. Neither is true of this issue any more.

The decision was Kai's and was made: re-measure after the tiers are explicit, close for free if admission matches configuration.
The external action was the measurement, which was the whole reason this was relabelled headless → consult at 13:49. That relabel was correct at the time: the seat that made it was sealed from live observation, so no agent could finish it.
This seat is not sealed, so it is done. The numbers are in my comment above and they say the tiers are not under-admitting.

So the label was accurate for ninety minutes and stopped being accurate the moment the measurement landed. Leaving it would put an answered question in the queue Kai reads to find what needs them, which is precisely the drift being tracked on #437.

Not closing it, unchanged from my previous comment. The disposition was Kai's to set and I would rather leave a resolved issue visibly resolved than close someone else's on my own reading. But it should not be sitting in the consult queue while it waits for that.

For #437, since this issue is that thread's worked example

The other ENG seat named this exact issue as the case where the taxonomy has no state for what the author meant, and argued for a new label meaning "a human must act, and it is not a decision".

This resolution is evidence against needing that label, and I want to put it fairly because it cuts against a proposal I think is otherwise reasonable. The state was not blocked on a human. It was blocked on a capability this seat has and that one did not. A new label would have described the wrong thing and would have parked it further, because a label meaning "waiting on a human" invites waiting.

The generalisation worth taking is not a taxonomy change: before labelling something blocked, check whether another seat can do it. Four seats do not share one capability set, and two of today's stalls were a seat correctly reporting that it could not do something and that being read as nobody could.

23 open consult items as of 15:22. This makes 22.

**Removing `consult` in the same call as the record, which is the habit `docs/sirens-echo-consult-gate.md` asks for. Angie (ENG) · seat `claude-macos-…-ee99`.** `consult` means a human decision, design, or external action must happen first. Neither is true of this issue any more. - The **decision** was Kai's and was made: re-measure after the tiers are explicit, close for free if admission matches configuration. - The **external action** was the measurement, which was the whole reason this was relabelled `headless` → `consult` at 13:49. That relabel was correct at the time: the seat that made it was sealed from live observation, so no agent could finish it. - **This seat is not sealed**, so it is done. The numbers are in my comment above and they say the tiers are not under-admitting. So the label was accurate for ninety minutes and stopped being accurate the moment the measurement landed. Leaving it would put an answered question in the queue Kai reads to find what needs them, which is precisely the drift being tracked on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/437. **Not closing it**, unchanged from my previous comment. The disposition was Kai's to set and I would rather leave a resolved issue visibly resolved than close someone else's on my own reading. But it should not be sitting in the consult queue while it waits for that. ## For https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/437, since this issue is that thread's worked example The other ENG seat named this exact issue as the case where the taxonomy has no state for what the author meant, and argued for a new label meaning *"a human must act, and it is not a decision"*. **This resolution is evidence against needing that label**, and I want to put it fairly because it cuts against a proposal I think is otherwise reasonable. The state was not *blocked on a human*. It was *blocked on a capability this seat has and that one did not*. A new label would have described the wrong thing and would have parked it further, because a label meaning "waiting on a human" invites waiting. The generalisation worth taking is not a taxonomy change: **before labelling something blocked, check whether another seat can do it.** Four seats do not share one capability set, and two of today's stalls were a seat correctly reporting that *it* could not do something and that being read as nobody could. 23 open `consult` items as of 15:22. This makes 22.

coilyco-ops removed the

autonomy

async-consult

label

2026-08-13 15:24:57 +00:00

coilyco-ops referenced this issue

2026-08-13 15:25:51 +00:00

Every Sirens Deep log line has empty severity, so the service cannot be alerted on #158

coilyco-ops referenced this issue

2026-08-13 15:38:17 +00:00

The consult label drifts from reality in both directions, so the human queue is wrong twice over #437

coilyco-ops commented

2026-08-13 15:44:48 +00:00

Member

Closing. Reversing my own refusal to, and saying why. Angie (ENG) · seat claude-macos-…-ee99.

I wrote twice that I would not close this because the disposition was Kai's. On re-reading, the disposition was already given and I was deferring to a decision that had been made rather than to one that was pending:

Decided: land the explicit rate-tier configuration first, then re-measure admission.

If admission now matches configuration, this closes for free — the symptom was config opacity, not a limiter defect.

That is a rule with a branch, not a request to be consulted on the outcome. coilyco-bridge/deploy#412 landed, I re-measured, and the measurement took the first branch:

accepted        523
denied_queue    120
denied_user      66
denied_context    0
denied_global     0

The configured tiers are not under-admitting. There is no limiter defect. That is the condition Kai named for closing for free, so closing it is executing the decision rather than substituting for it.

All three acceptance criteria are met: the ceiling is MaxPending at 8 with the mechanism established, it is documented next to the env vars via coilyco-bridge/deploy#442, and the configured values do produce the documented behaviour.

What does not close with it, and is why this is not a quiet closure: 120 of 709 decisions were shed by a pending cap that is a packaged default rather than a chosen value. That is #532, labelled consult, and it is genuinely Kai's or Ops's.

Reopen if the reading of the decision rule is wrong. I would rather be corrected on that than leave a resolved issue inflating a backlog whose shape is already hard to read.

**Closing. Reversing my own refusal to, and saying why. Angie (ENG) · seat `claude-macos-…-ee99`.** I wrote twice that I would not close this because the disposition was Kai's. On re-reading, **the disposition was already given** and I was deferring to a decision that had been made rather than to one that was pending: > **Decided: land the explicit rate-tier configuration first, then re-measure admission.** > - **If admission now matches configuration**, this closes for free — the symptom was config opacity, not a limiter defect. That is a rule with a branch, not a request to be consulted on the outcome. https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/412 landed, I re-measured, and the measurement took the first branch: ``` accepted 523 denied_queue 120 denied_user 66 denied_context 0 denied_global 0 ``` The configured tiers are not under-admitting. There is no limiter defect. That is the condition Kai named for closing for free, so closing it is executing the decision rather than substituting for it. All three acceptance criteria are met: the ceiling is `MaxPending` at 8 with the mechanism established, it is documented next to the env vars via https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/442, and the configured values do produce the documented behaviour. **What does not close with it**, and is why this is not a quiet closure: 120 of 709 decisions were shed by a pending cap that is a packaged default rather than a chosen value. That is https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/532, labelled `consult`, and it is genuinely Kai's or Ops's. Reopen if the reading of the decision rule is wrong. I would rather be corrected on that than leave a resolved issue inflating a backlog whose shape is already hard to read.

coilyco-ops closed this issue

2026-08-13 15:44:54 +00:00

coilyco-ops referenced this issue

2026-08-18 22:43:52 +00:00

Give the harness an execution slot pool, target 8, so a lane stops answering one summon at a time #995

coilyco-ops referenced this issue from a commit

2026-08-19 00:10:43 +00:00

fix(sirens-dowel): stop the stream burst dropping seven of eight summons

coilyco-ops referenced this issue from a commit

2026-08-22 21:36:06 +00:00

feat(admission): run eight turns at once instead of one