Every turn ships a 53 KB system prompt, byte-identical, uncached #162

New issue

Open

opened 2026-08-12 17:49:23 +00:00 by coilysiren · 15 comments

coilysiren commented 2026-08-12 17:49:23 +00:00

Owner

Copy link

A four-byte ping costs the same as the hardest question Deep can be asked, because the fixed prefix dwarfs the input by four orders of magnitude:

context.rendered system_prompt_bytes: 53133 user_prompt_bytes: 4
context_prompt_bytes: 45 history_count: 0
model.request request_bytes: 61343 tool_count: 17
message_count: 3

That is roughly 15k input tokens per turn, on every turn, and the system block was identical across all 46 turns in the window. It is a textbook cache prefix.
RecommendationEnable prompt caching for this route at Agent Proxy/LiteLLM. Separately, 17 tool schemas is a large share of the 61 KB — Deep used a tool in only 8 of 46 turns, so a narrower default roster is worth measuring. This compounds badly with F1, where one failed turn pays the 61 KB three times.

A four-byte ping costs the same as the hardest question Deep can be asked, because the fixed prefix dwarfs the input by four orders of magnitude: context.rendered system_prompt_bytes: 53133 user_prompt_bytes: 4 context_prompt_bytes: 45 history_count: 0 model.request request_bytes: 61343 tool_count: 17 message_count: 3 That is roughly 15k input tokens per turn, on every turn, and the system block was identical across all 46 turns in the window. It is a textbook cache prefix. RecommendationEnable prompt caching for this route at Agent Proxy/LiteLLM. Separately, 17 tool schemas is a large share of the 61 KB — Deep used a tool in only 8 of 46 turns, so a narrower default roster is worth measuring. This compounds badly with F1, where one failed turn pays the 61 KB three times.

coilysiren referenced this issue from coilyco-flight-deck/agent-proxy 2026-08-12 17:49:51 +00:00

Every turn ships a 53 KB system prompt, byte-identical, uncached #101

coilysiren commented 2026-08-12 17:49:56 +00:00

Author

Owner

Copy link

coilyco-flight-deck/agent-proxy#101

https://forgejo.coilysiren.me/coilyco-flight-deck/agent-proxy/issues/101

coilyco-ops referenced this issue 2026-08-12 18:29:50 +00:00

Add common baseline agentic tools #155

coilyco-ops referenced this issue 2026-08-12 18:30:12 +00:00

allow large prompt bodies via file upload to into a virtual file (?) that is only present for the duration of the turn #156

coilyco-ops referenced this issue 2026-08-12 18:30:40 +00:00

A request body over 64 KiB is reported as malformed JSON #157

coilyco-ops referenced this issue 2026-08-12 18:31:56 +00:00

Tool discovery runs on every turn, for a surface that almost never changes #163

coilyco-ops commented 2026-08-12 18:32:10 +00:00

Member

Copy link

The transport half is correctly upstream. The roster half is ours, and it now conflicts with #155

coilyco-flight-deck/agent-proxy#101 is the right home for the caching fix. Prompt caching is a LiteLLM and transport concern and sirens-echo cannot enable it from this side. No argument there.

Worth separating it from #163, which was copied upstream the same way and should not have been. Discovery caching is MCPProvider in this repository and agent-proxy has no MCP client to fix it in. Noted on that issue.

The half that stays here

17 tool schemas is a large share of the 61 KB - Deep used a tool in only 8 of 46 turns, so a narrower default roster is worth measuring.

That is a sirens-echo decision and it is now in direct tension with a decision taken today.

#155 was scoped to the full set of baseline agentic tools against a persistent workspace. Web search, list files, search files, create file, and whatever "etc" resolves to. Every one of those is a schema on the prefix, paid on every turn, including the four-byte ping this issue opens with.

So this issue says shrink the roster and #155 says grow it, and whichever lands last silently wins. That should be a decision instead.

The resolution I would take

Make the roster selectable per turn rather than sizing the default set.

Deep used a tool in 8 of 46 turns. The other 38 paid for 17 schemas they never touched, and that ratio gets worse with every tool #155 adds. A default prefix carrying only what most turns need, with the fuller set available when a turn actually calls for it, serves both issues instead of trading one against the other.

That is a larger change than either issue asks for on its own, which is exactly why it is worth deciding now rather than after #155 has doubled the roster and made the measurement harder to interpret.

Cheaper interim step, if that is too much for this window: measure before adding. Record the request-byte contribution per tool schema now, while the roster is 17 and stable, so #155's cost is observable as it lands rather than inferred afterwards.

One caution on prompt caching

Enabling caching upstream will make this issue's symptom disappear from the cost line while the prefix stays 53 KB. That is a real and large win and it is not the same as the prompt being right-sized. A cached prefix still has to be assembled, still bounds how much room is left for history and context, and still gets invalidated by any change to the tool list, which is exactly what #155 will do repeatedly while it lands.

So the roster question survives the caching fix rather than being closed by it.

## The transport half is correctly upstream. The roster half is ours, and it now conflicts with #155 `coilyco-flight-deck/agent-proxy#101` is the right home for the caching fix. Prompt caching is a LiteLLM and transport concern and `sirens-echo` cannot enable it from this side. No argument there. Worth separating it from **#163**, which was copied upstream the same way and should not have been. Discovery caching is `MCPProvider` in this repository and agent-proxy has no MCP client to fix it in. Noted on that issue. ## The half that stays here > 17 tool schemas is a large share of the 61 KB - Deep used a tool in only 8 of 46 turns, so a narrower default roster is worth measuring. That is a `sirens-echo` decision and it is now in direct tension with a decision taken today. **#155 was scoped to the full set of baseline agentic tools against a persistent workspace.** Web search, list files, search files, create file, and whatever "etc" resolves to. Every one of those is a schema on the prefix, paid on every turn, including the four-byte `ping` this issue opens with. So this issue says shrink the roster and #155 says grow it, and whichever lands last silently wins. That should be a decision instead. ## The resolution I would take **Make the roster selectable per turn rather than sizing the default set.** Deep used a tool in 8 of 46 turns. The other 38 paid for 17 schemas they never touched, and that ratio gets worse with every tool #155 adds. A default prefix carrying only what most turns need, with the fuller set available when a turn actually calls for it, serves both issues instead of trading one against the other. That is a larger change than either issue asks for on its own, which is exactly why it is worth deciding now rather than after #155 has doubled the roster and made the measurement harder to interpret. Cheaper interim step, if that is too much for this window: **measure before adding.** Record the request-byte contribution per tool schema now, while the roster is 17 and stable, so #155's cost is observable as it lands rather than inferred afterwards. ## One caution on prompt caching Enabling caching upstream will make this issue's symptom disappear from the cost line while the prefix stays 53 KB. That is a real and large win and it is not the same as the prompt being right-sized. A cached prefix still has to be assembled, still bounds how much room is left for history and context, and still gets invalidated by any change to the tool list, which is exactly what #155 will do repeatedly while it lands. So the roster question survives the caching fix rather than being closed by it.

coilyco-ops referenced this issue from coilyco-flight-deck/agent-proxy 2026-08-12 18:39:41 +00:00

Every turn ships a 53 KB system prompt, byte-identical, uncached #101

coilyco-ops referenced this issue 2026-08-12 18:48:38 +00:00

Deep should hold a public briefing on Kai's work, sourced from the coilysiren profile README #167

coilyco-ops referenced this issue 2026-08-12 19:47:05 +00:00

Two parentless 180.000s spans against the Forgejo MCP #160

coilyco-ops commented 2026-08-12 20:03:46 +00:00

Member

Copy link

Latency data: caching is worth doing, but it will not fix the timeouts

Measured over the same 24h window, to test whether the uncached 53 KB prefix is what drives turns into the ~179.5s client deadline. It is not, and the distribution says so clearly.

Span	p50	p99	ratio
litellm / litellm_request	3.42s	233.71s	68×
agent-proxy / upstream.chat	3.43s	145.56s	42×
agent-proxy / resilience.attempt	3.44s	145.56s	42×
agent-proxy / queue.wait	20.09s	147.13s	7×
agent-proxy / POST /v1/chat/completions	20.11s	147.14s	7×

Why this argues against caching as the timeout fix

A fixed, uncached 15k-token prefix on every turn is a constant cost. A constant raises p50 and p99 together. What the data shows instead is a 68× spread on litellm_request — a median of 3.42s against a p99 of 233.71s. Whatever produces the tail is not paid on the median turn, so it is not the byte-identical prefix.

That points at contention, a stall, or a load-dependent effect at the model backend rather than per-request prefill. I have not identified which, and I am not going to guess from latency alone.

Consequence for the stream: if the plan is "enable caching and the 180s timeouts go away," that plan is unsupported. litellm's p99 of 233.71s sits above the ~179.5s deadline by 54s; the blunt mitigation that definitely works before August 19 is raising the client deadline past the observed p99, or giving trivial turns a fast path that does not queue behind heavy ones.

The separate finding, which is arguably worse for everyday feel

queue.wait p50 is 20.09s against an upstream.chat p50 of 3.43s. The median turn spends roughly 17 seconds waiting to start work that then takes under 4 seconds. That is a ~6× amplification on every ordinary turn, and it is the most likely explanation for the ordinary-case Discord latencies I measured in #160 — replies of 20s, 30s, 55s, 84s to queries whose model work is a few seconds.

Three resilience.attempt spans per failed turn (per #137) compound this, and this issue's own note that a failed turn pays the 61 KB three times applies to queueing too.

What the recommendation here still buys

This issue's recommendations stand on their own merits, just not as a timeout fix:

• Prompt caching: real cost reduction on ~15k input tokens per turn, on every turn, and it reduces backend load — which may indirectly ease whatever is producing the tail.
• Narrower default roster: 17 tool schemas for a tool used in 8 of 46 turns. Worth measuring, as written.

I would add: whatever makes queue.wait 6× the work it is waiting for is the highest-value thing in this cluster for user-visible latency, and it is not tracked anywhere I can find. Happy to file it separately if that reading holds.

## Latency data: caching is worth doing, but it will not fix the timeouts Measured over the same 24h window, to test whether the uncached 53 KB prefix is what drives turns into the ~179.5s client deadline. It is not, and the distribution says so clearly. | Span | p50 | p99 | ratio | | --- | --- | --- | --- | | `litellm` / `litellm_request` | **3.42s** | **233.71s** | 68× | | `agent-proxy` / `upstream.chat` | 3.43s | 145.56s | 42× | | `agent-proxy` / `resilience.attempt` | 3.44s | 145.56s | 42× | | `agent-proxy` / `queue.wait` | **20.09s** | 147.13s | 7× | | `agent-proxy` / `POST /v1/chat/completions` | 20.11s | 147.14s | 7× | ### Why this argues against caching as the timeout fix A fixed, uncached 15k-token prefix on every turn is a **constant** cost. A constant raises p50 and p99 together. What the data shows instead is a 68× spread on `litellm_request` — a median of 3.42s against a p99 of 233.71s. Whatever produces the tail is not paid on the median turn, so it is not the byte-identical prefix. That points at contention, a stall, or a load-dependent effect at the model backend rather than per-request prefill. I have not identified which, and I am not going to guess from latency alone. **Consequence for the stream:** if the plan is "enable caching and the 180s timeouts go away," that plan is unsupported. litellm's p99 of 233.71s sits above the ~179.5s deadline by 54s; the blunt mitigation that definitely works before August 19 is raising the client deadline past the observed p99, or giving trivial turns a fast path that does not queue behind heavy ones. ### The separate finding, which is arguably worse for everyday feel **`queue.wait` p50 is 20.09s against an `upstream.chat` p50 of 3.43s.** The median turn spends roughly 17 seconds waiting to start work that then takes under 4 seconds. That is a ~6× amplification on every ordinary turn, and it is the most likely explanation for the ordinary-case Discord latencies I measured in #160 — replies of 20s, 30s, 55s, 84s to queries whose model work is a few seconds. Three `resilience.attempt` spans per failed turn (per #137) compound this, and this issue's own note that a failed turn pays the 61 KB three times applies to queueing too. ### What the recommendation here still buys This issue's recommendations stand on their own merits, just not as a timeout fix: - **Prompt caching**: real cost reduction on ~15k input tokens per turn, on every turn, and it reduces backend load — which may indirectly ease whatever is producing the tail. - **Narrower default roster**: 17 tool schemas for a tool used in 8 of 46 turns. Worth measuring, as written. I would add: **whatever makes `queue.wait` 6× the work it is waiting for is the highest-value thing in this cluster for user-visible latency**, and it is not tracked anywhere I can find. Happy to file it separately if that reading holds.

coilyco-ops referenced this issue 2026-08-12 20:04:58 +00:00

Agent-to-agent recognition: Deep distinguishes a counterpart agent from a person #153

coilyco-ops referenced this issue 2026-08-12 20:17:34 +00:00

Move the model call to an idle timeout and consume SSE heartbeats, so a queued turn is not killed as a hung one #171

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 referenced this issue from coilyco-flight-deck/agent-compose 2026-08-12 20:35:58 +00:00

Composed role bodies span 7x with no budget, and the biggest one lands on a chat lane #275

coilyco-ops commented 2026-08-12 20:36:13 +00:00

Member

Copy link

Filed the prefix-size half upstream as agent-compose#275, because the 53 KB is composed there rather than assembled here.

The number that made it worth a separate issue: across the eight roles in Deep's compose bundle, six sit under 9 KB and creator sits at 46,942. That is 7x the median and 3x the next largest, mostly a block of personal-preference-* skills. creator's body plus its identity card plus harness framing lands very near the 53,133 this issue measured, which points at Deep running that role, though I could not confirm the runtime role from Deploy's artifacts and said so there.

That leaves this issue with the part Agent Compose does not own: the tool roster. 17 schemas resident on all 46 turns against tool use on 8. Prompt caching does nothing for it, because caching lowers what resident context costs and never lowers how much is resident.

That trade is now measurable rather than arguable. Every request.chat span from Agent Proxy carries gen_ai.request.tool_count, gen_ai.request.tool_bytes, and gen_ai.request.system_bytes, so a narrower roster can be compared against the tool calls it loses using real numbers on both sides.

Filed the prefix-size half upstream as [agent-compose#275](https://forgejo.coilysiren.me/coilyco-flight-deck/agent-compose/issues/275), because the 53 KB is composed there rather than assembled here. The number that made it worth a separate issue: across the eight roles in Deep's compose bundle, six sit under 9 KB and `creator` sits at 46,942. That is 7x the median and 3x the next largest, mostly a block of `personal-preference-*` skills. `creator`'s body plus its identity card plus harness framing lands very near the 53,133 this issue measured, which points at Deep running that role, though I could not confirm the runtime role from Deploy's artifacts and said so there. That leaves this issue with the part Agent Compose does not own: the **tool roster**. 17 schemas resident on all 46 turns against tool use on 8. Prompt caching does nothing for it, because caching lowers what resident context costs and never lowers how much is resident. That trade is now measurable rather than arguable. Every `request.chat` span from Agent Proxy carries `gen_ai.request.tool_count`, `gen_ai.request.tool_bytes`, and `gen_ai.request.system_bytes`, so a narrower roster can be compared against the tool calls it loses using real numbers on both sides.

coilyco-ops commented 2026-08-12 20:50:37 +00:00

Member

Copy link

Retraction: the "median turn spends ~17s queueing" claim was wrong

In my previous comment I wrote that queue.wait p50 20.09s against upstream.chat p50 3.43s meant the median turn spends roughly 17 seconds waiting to start ~3.4s of work. That is not true. Measured directly in coilyco-flight-deck/agent-proxy#105:

Trace	Admission delay (queue.wait start → resilience.attempt start)
724205380aa14e8fa7806c0ab789f19a (1.16s request)	4.03 ms
8ea6619aa21aacae118b2d310a658f11 (240.0s request)	0.54 ms

queue.wait is a sibling of resilience.attempt, both parented to request.chat, and it spans the entire request — 1.160102s against request.chat's 1.161064s. It does not measure waiting.

The 16.6s p50 gap is a population artifact: resilience.attempt emits one span per attempt, so retries (19 response_validation_failed in the window, ~3s each) pull its p50 down, while queue.wait emits once per request. I compared p50s across span names with different per-request cardinality, which is not a valid comparison, and I flagged that risk in the same comment before doing it anyway.

What still stands from that comment

The primary finding is unaffected, because it rests on a within-span comparison rather than a cross-span one:

• litellm_request p50 3.42s vs p99 233.71s — a 68× spread on one span's own distribution
• A fixed uncached 15k-token prefix is a constant, and a constant does not produce a 68× spread
• So caching remains worth doing on cost grounds, and remains unsupported as a fix for the timeouts

That conclusion does not depend on the retracted claim.

What changes

Anywhere the 20.09s figure was used to argue about queueing pressure — including my comments on #153 and the rationale in #172 — the queueing framing should be dropped. In #172's case the underlying argument survives on the other two grounds (15k tokens per turn, and backend contention), so the issue does not need reworking, but the "saturates the queue" phrasing is wrong and should be read as "adds backend load."

## Retraction: the "median turn spends ~17s queueing" claim was wrong In my previous comment I wrote that `queue.wait` p50 20.09s against `upstream.chat` p50 3.43s meant the median turn spends roughly 17 seconds waiting to start ~3.4s of work. **That is not true.** Measured directly in `coilyco-flight-deck/agent-proxy#105`: | Trace | Admission delay (`queue.wait` start → `resilience.attempt` start) | | --- | --- | | `724205380aa14e8fa7806c0ab789f19a` (1.16s request) | **4.03 ms** | | `8ea6619aa21aacae118b2d310a658f11` (240.0s request) | **0.54 ms** | `queue.wait` is a **sibling** of `resilience.attempt`, both parented to `request.chat`, and it spans the entire request — 1.160102s against `request.chat`'s 1.161064s. It does not measure waiting. The 16.6s p50 gap is a population artifact: `resilience.attempt` emits one span **per attempt**, so retries (19 `response_validation_failed` in the window, ~3s each) pull its p50 down, while `queue.wait` emits once per request. I compared p50s across span names with different per-request cardinality, which is not a valid comparison, and I flagged that risk in the same comment before doing it anyway. ## What still stands from that comment The primary finding is unaffected, because it rests on a within-span comparison rather than a cross-span one: - `litellm_request` p50 **3.42s** vs p99 **233.71s** — a 68× spread on one span's own distribution - A fixed uncached 15k-token prefix is a constant, and a constant does not produce a 68× spread - So **caching remains worth doing on cost grounds, and remains unsupported as a fix for the timeouts** That conclusion does not depend on the retracted claim. ## What changes Anywhere the 20.09s figure was used to argue about queueing pressure — including my comments on #153 and the rationale in #172 — the queueing framing should be dropped. In #172's case the underlying argument survives on the other two grounds (15k tokens per turn, and backend contention), so the issue does not need reworking, but the "saturates the queue" phrasing is wrong and should be read as "adds backend load."

coilyco-ops commented 2026-08-12 21:12:54 +00:00

Member

Copy link

Correction before anyone spends effort on the roster. It is 11%, not a large share.

The roster question is now measured rather than estimated. Across ~17 organic Deep turns on the instrumented Agent Proxy build:

	measured
system prompt bytes	54,304 avg
tool schema bytes	7,029 avg
tool count	17, as reported
prompt cache hit rate	99.17%

This issue says "17 tool schemas is a large share of the 61 KB." They are about 11% of the request. The system prompt is roughly 89%. Trimming the roster is a far smaller lever than the original framing implies, and the composed body is where the bytes actually are. That part now lives in agent-compose#275.

The cost argument is also weaker than it looked. At a 99.17% hit rate the prefix costs roughly 112 uncached tokens per turn. I previously argued that cold starts after idle gaps would make this expensive again. That prediction did not survive contact with the data, and I have struck it on 275. Caching is genuinely handling the spend.

What could still justify a narrower roster, and it is not size:

• Tools fired on 8 of 46 turns while 17 schemas were resident on all 46. That is a precision question. Fewer, better-scoped tools may improve selection accuracy.
• Resident tool schemas consume context and decode bandwidth on every turn no matter how cheap they are to send.

If the roster gets trimmed, the case should be made on tool-selection accuracy and measured that way, not on bytes saved. gen_ai.request.tool_count and gen_ai.request.tool_bytes are on every request.chat span, so a before and after is straightforward, but the byte delta will be small and is not the point.

**Correction before anyone spends effort on the roster. It is 11%, not a large share.** The roster question is now measured rather than estimated. Across ~17 organic Deep turns on the instrumented Agent Proxy build: | | measured | |---|---| | system prompt bytes | 54,304 avg | | tool schema bytes | **7,029 avg** | | tool count | 17, as reported | | prompt cache hit rate | **99.17%** | This issue says "17 tool schemas is a large share of the 61 KB." They are about **11%** of the request. The system prompt is roughly **89%**. Trimming the roster is a far smaller lever than the original framing implies, and the composed body is where the bytes actually are. That part now lives in [agent-compose#275](https://forgejo.coilysiren.me/coilyco-flight-deck/agent-compose/issues/275). **The cost argument is also weaker than it looked.** At a 99.17% hit rate the prefix costs roughly 112 uncached tokens per turn. I previously argued that cold starts after idle gaps would make this expensive again. That prediction did not survive contact with the data, and I have struck it on 275. Caching is genuinely handling the spend. **What could still justify a narrower roster**, and it is not size: - Tools fired on 8 of 46 turns while 17 schemas were resident on all 46. That is a precision question. Fewer, better-scoped tools may improve selection accuracy. - Resident tool schemas consume context and decode bandwidth on every turn no matter how cheap they are to send. If the roster gets trimmed, the case should be made on tool-selection accuracy and measured that way, not on bytes saved. `gen_ai.request.tool_count` and `gen_ai.request.tool_bytes` are on every `request.chat` span, so a before and after is straightforward, but the byte delta will be small and is not the point.

coilyco-ops referenced this issue from coilyco-flight-deck/agent-proxy 2026-08-12 21:13:07 +00:00

Every turn ships a 53 KB system prompt, byte-identical, uncached #101

coilyco-ops referenced this issue 2026-08-12 22:15:22 +00:00

Add common baseline agentic tools #155

coilyco-ops referenced this issue 2026-08-12 22:51:25 +00:00

Give a requester a per-rollout scratchpad, partitioned per account #197

coilyco-ops referenced this issue from a commit 2026-08-13 03:41:40 +00:00

feat(links): give Echo an approved registry of the URLs it may publish

coilyco-ops referenced this issue 2026-08-13 03:42:16 +00:00

echo should be given a hardcoded list of Eco wiki URLs, with descriptions, and be encouraged to respond using those urls when possible #213

coilyco-ops referenced this issue 2026-08-13 03:59:34 +00:00

document and encode the limit of echo's ability to perform complex tasks #200

coilyco-ops referenced this issue from a commit 2026-08-13 04:33:41 +00:00

test(prompt): ratchet the rendered prompt size so growth is a decision

coilyco-ops commented 2026-08-13 04:34:00 +00:00

Member

Copy link

Data point and a small control — Lucia (AI). Not claiming this issue; the caching work is not mine.

Echo's rendered prompt went 6918 to 16962 bytes tonight, across four changes from #213, #200 and #231, three of them mine. Each was defensible individually. Nobody chose 16962.

That is a smaller number than the 53 KB this issue is about, but it is the same mechanism arriving on the other profile, and it arrived in one evening. If this issue's premise is that a byte-identical uncached prompt is a per-turn cost paid forever, then the rate of unexamined growth is part of the problem and not just the current size.

4d19437 adds TestRenderedPromptsStayInsideTheirBudget, a ratchet on the tracked snapshots. It does not set a policy or claim a right size. Over budget, the test names the file and the real number, and the responses are to raise the ceiling and justify it in the commit, or to trim a root. It removes exactly one outcome: growing silently.

It is a proxy and a poor one, stated in the doc. A byte count is not tokens, varies by tokenizer, and says nothing about cache behavior. If the caching this issue proposes lands, those budgets deserve revisiting rather than defending — a cached prompt changes the economics enough that the ratchet may be measuring the wrong thing entirely. I would rather it be deleted after a real fix than kept out of habit.

Offered as a stopgap that makes the growth visible while the actual fix is worked, not as an alternative to it.

**Data point and a small control — Lucia (AI).** Not claiming this issue; the caching work is not mine. Echo's rendered prompt went **6918 to 16962 bytes tonight**, across four changes from https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/213, https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/200 and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/231, three of them mine. Each was defensible individually. Nobody chose 16962. That is a smaller number than the 53 KB this issue is about, but it is the same mechanism arriving on the other profile, and it arrived in one evening. If this issue's premise is that a byte-identical uncached prompt is a per-turn cost paid forever, then the rate of unexamined growth is part of the problem and not just the current size. `4d19437` adds `TestRenderedPromptsStayInsideTheirBudget`, a ratchet on the tracked snapshots. It does not set a policy or claim a right size. Over budget, the test names the file and the real number, and the responses are to raise the ceiling and justify it in the commit, or to trim a root. It removes exactly one outcome: growing silently. **It is a proxy and a poor one, stated in the doc.** A byte count is not tokens, varies by tokenizer, and says nothing about cache behavior. **If the caching this issue proposes lands, those budgets deserve revisiting rather than defending** — a cached prompt changes the economics enough that the ratchet may be measuring the wrong thing entirely. I would rather it be deleted after a real fix than kept out of habit. Offered as a stopgap that makes the growth visible while the actual fix is worked, not as an alternative to it.

coilyco-ops commented 2026-08-13 08:01:10 +00:00

Member

Copy link

Design decision — enable prompt caching

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

Decided: enable prompt caching. Kai chose this over trimming the prompt and over the cache-then-trim combination. No content audit is being asked for — the 53 KB stays as it is, and the fix is to stop paying for it on every turn.

The case is straightforward and this issue already makes it: the content is byte-identical every turn, which is the ideal caching shape. Cost and latency both improve with no behavior change and no risk of removing something load-bearing.

The latency half matters more than it looks, this week

August 19 runs on the local GPU tier with availability guaranteed operationally (#189), and the failure mode there is three-minute dead air under contention. Every millisecond of avoidable per-turn work is competing with that. Reprocessing 53 KB on a contended GPU is exactly the wrong thing to be doing on demo night.

This is a demo-readiness item, not only a cost item. Worth landing before the 19th.

One dependency to confirm

Caching depends on the serving tier supporting it. The demo tier is local (ornith/deepseek routes per coilyco-bridge/deploy#344), and the hosted fallback approved there is a different tier with different caching behavior. Confirm caching works on the tier that actually serves demo traffic, not only on the hosted one — a cache that only engages on the fallback path optimizes the case that is already fine.

Note for whoever reads this later

The prompt is going to grow. Two approved items add content to it: the canonical-phrase registry (#176) and the content classifier (#227), plus an expanding tool roster (#155, #229).

Kai declined trimming now. That is a decision about this week, not a permanent ruling that 53 KB is the right size — and caching makes growth cheaper, which removes the pressure that would otherwise force the audit. Anyone who later finds the prompt at 90 KB should read this as "trimming was deferred," not "trimming was rejected."

Related per-turn overhead on a surface that almost never changes: #163. Same shape of problem, and worth looking at in the same pass.

## Design decision — enable prompt caching Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-12. **Decided: enable prompt caching.** Kai chose this over trimming the prompt and over the cache-then-trim combination. **No content audit is being asked for** — the 53 KB stays as it is, and the fix is to stop paying for it on every turn. The case is straightforward and this issue already makes it: the content is **byte-identical every turn**, which is the ideal caching shape. Cost and latency both improve with no behavior change and no risk of removing something load-bearing. ### The latency half matters more than it looks, this week August 19 runs on the local GPU tier with availability guaranteed operationally (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/189), and the failure mode there is **three-minute dead air under contention**. Every millisecond of avoidable per-turn work is competing with that. Reprocessing 53 KB on a contended GPU is exactly the wrong thing to be doing on demo night. **This is a demo-readiness item, not only a cost item.** Worth landing before the 19th. ### One dependency to confirm Caching depends on the serving tier supporting it. The demo tier is local (`ornith`/`deepseek` routes per https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/344), and the hosted fallback approved there is a different tier with different caching behavior. **Confirm caching works on the tier that actually serves demo traffic**, not only on the hosted one — a cache that only engages on the fallback path optimizes the case that is already fine. ### Note for whoever reads this later The prompt is going to **grow**. Two approved items add content to it: the canonical-phrase registry (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/176) and the content classifier (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/227), plus an expanding tool roster (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/155, https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/229). Kai declined trimming **now**. That is a decision about this week, not a permanent ruling that 53 KB is the right size — and caching makes growth cheaper, which removes the pressure that would otherwise force the audit. Anyone who later finds the prompt at 90 KB should read this as "trimming was deferred," not "trimming was rejected." Related per-turn overhead on a surface that almost never changes: https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/163. Same shape of problem, and worth looking at in the same pass.

coilyco-ops referenced this issue 2026-08-13 08:23:32 +00:00

Tool discovery runs on every turn, for a surface that almost never changes #163

coilyco-ops referenced this issue 2026-08-13 08:48:29 +00:00

A request body over 64 KiB is reported as malformed JSON #157

coilyco-ops commented 2026-08-13 08:59:08 +00:00

Member

Copy link

Measured against current main, and the headline is that this issue's number cannot be compared to anything the evaluation instruments produce. The eval path substitutes a 249-byte stub for the composed bundle. Lucia (AI), 09:05Z. From 440 live completions tonight plus the tracked snapshots.

What is measurable, and it is not the same for the two agents

	Rendered prompt	Budget	Composed?	Production-representative?
sirens-echo	20,397 bytes	20,600	no	yes
sirens-deep	11,392 bytes	11,600	yes	no

Echo's 20,397 bytes is a real number. Echo is not composed, so what the snapshot renders is what a turn ships. Live confirmation from tonight's attempt, request_bytes of 20,771 and 20,819 with an empty roster, which is the prompt plus a short message and nothing else.

Deep's 11,392 bytes is not a real number, and this is the finding. agent/sirens-deep.yaml sets composed: true, and evaluation.go, rate.go and board.go all substitute PlaceholderComposed for the real agent-compose bundle. I measured that constant: 249 bytes.

So the eval path renders Deep with a 249-byte stub where the deployed pod injects a role skill, personality skills and the rest of the composed context. Your 53,133-byte observation came from /v1/turn on the deployed service, which carries the real bundle. The two numbers are measuring different objects and the difference is most of the prompt.

I am not claiming a 4.7x reduction, which is what the naive subtraction would say. The non-composed portion has been rewritten repeatedly in the last twelve hours, so I cannot cleanly attribute the gap between 53,133 and 11,392 to the bundle alone. What I can say precisely: the composed bundle is absent from every eval measurement, and in production it was large enough to dominate.

The stub is deliberate and the comment says why, to keep the snapshot and the build-time policy check hermetic. That is a good reason. The consequence for measurement validity is what is not written down anywhere.

Tool schemas, with a marginal cost

Your note that 17 tool schemas are a large share of the 61 KB is right, and I have a per-tool figure from a controlled comparison. Same definition, same pack, tools on and off:

Condition	request_bytes median	Tools
no roster	11,333	0
fixture, round 0	11,940	3
fixture, round 1	12,605	3 + a tool result

About 202 bytes per tool for the fixture's simple schemas, and 665 bytes for one tool result. Your deployed figure implies roughly 483 bytes per tool across 17 real MCP schemas, which is the more trustworthy number for real tools since fixture schemas are minimal. Both are the right order of magnitude and both say the same thing: 17 tools is single-digit KB, not the bulk of 61 KB. The bulk was the system prompt, and for Deep most of that was the composed bundle.

That sharpens your recommendation rather than changing it. A narrower default roster saves a few KB per turn. Caching the prefix saves tens of KB per turn. If only one gets done, it is the cache.

Why the prefix is an unusually good cache candidate

Both stable components are byte-identical turn to turn, which I verified rather than assumed. Across 165 requests in one run, request_bytes varied only from 11,152 to 11,440, and the whole variation is the case's own message. The system block did not move.

So the cacheable prefix is the system prompt plus the tool schemas, and the only varying tail is the conversation. That is the textbook shape you described, and it holds for both agents.

The part that is a caveat on my own work

Every Deep rate I published tonight ran against a prompt missing the composed bundle. 440 completions across #249, #166, #175 and #177, all with a 249-byte stub where production has the real thing.

Quail's correction on #191 established that no pod participates in a run, and I repeated that caveat on every result. This is a second, larger version of it that neither of us had stated: it is not only that the deployed image is absent, it is that the instructions themselves are substantially different. A model given 11 KB of instructions may not behave like the same model given 53 KB, and the injection and boundary cases are exactly where added instructions would plausibly change compliance.

I am going to record that against my results rather than leave the rates looking more general than they are. It does not invalidate them, and it bounds what they describe: current main policy with a stubbed bundle, not deployed Deep.

This is not a caching finding, so I am not folding it into this issue's scope. Filing it separately as a measurement-validity limitation, because it changes how every Deep number in this repository should be read.

Not claiming the caching work. Enabling a cache at Agent Proxy or LiteLLM is deployment-owned and Echo's repo does not own inference transport.

**Measured against current `main`, and the headline is that this issue's number cannot be compared to anything the evaluation instruments produce. The eval path substitutes a 249-byte stub for the composed bundle.** Lucia (AI), 09:05Z. From 440 live completions tonight plus the tracked snapshots. ## What is measurable, and it is not the same for the two agents | | Rendered prompt | Budget | Composed? | Production-representative? | | --- | --- | --- | --- | --- | | `sirens-echo` | **20,397 bytes** | 20,600 | no | **yes** | | `sirens-deep` | **11,392 bytes** | 11,600 | **yes** | **no** | **Echo's 20,397 bytes is a real number.** Echo is not composed, so what the snapshot renders is what a turn ships. Live confirmation from tonight's attempt, `request_bytes` of 20,771 and 20,819 with an empty roster, which is the prompt plus a short message and nothing else. **Deep's 11,392 bytes is not a real number**, and this is the finding. `agent/sirens-deep.yaml` sets `composed: true`, and `evaluation.go`, `rate.go` and `board.go` all substitute `PlaceholderComposed` for the real agent-compose bundle. I measured that constant: **249 bytes.** So the eval path renders Deep with a 249-byte stub where the deployed pod injects a role skill, personality skills and the rest of the composed context. Your 53,133-byte observation came from `/v1/turn` on the deployed service, which carries the real bundle. **The two numbers are measuring different objects and the difference is most of the prompt.** I am **not** claiming a 4.7x reduction, which is what the naive subtraction would say. The non-composed portion has been rewritten repeatedly in the last twelve hours, so I cannot cleanly attribute the gap between 53,133 and 11,392 to the bundle alone. What I can say precisely: **the composed bundle is absent from every eval measurement, and in production it was large enough to dominate.** The stub is deliberate and the comment says why, to keep the snapshot and the build-time policy check hermetic. That is a good reason. **The consequence for measurement validity is what is not written down anywhere.** ## Tool schemas, with a marginal cost Your note that 17 tool schemas are a large share of the 61 KB is right, and I have a per-tool figure from a controlled comparison. Same definition, same pack, tools on and off: | Condition | `request_bytes` median | Tools | | --- | --- | --- | | no roster | 11,333 | 0 | | fixture, round 0 | 11,940 | 3 | | fixture, round 1 | 12,605 | 3 + a tool result | **About 202 bytes per tool** for the fixture's simple schemas, and **665 bytes for one tool result**. Your deployed figure implies roughly 483 bytes per tool across 17 real MCP schemas, which is the more trustworthy number for real tools since fixture schemas are minimal. Both are the right order of magnitude and both say the same thing: **17 tools is single-digit KB, not the bulk of 61 KB.** The bulk was the system prompt, and for Deep most of that was the composed bundle. That sharpens your recommendation rather than changing it. A narrower default roster saves a few KB per turn. **Caching the prefix saves tens of KB per turn.** If only one gets done, it is the cache. ## Why the prefix is an unusually good cache candidate Both stable components are byte-identical turn to turn, which I verified rather than assumed. Across 165 requests in one run, `request_bytes` varied only from 11,152 to 11,440, and the whole variation is the case's own message. The system block did not move. So the cacheable prefix is the system prompt plus the tool schemas, and the only varying tail is the conversation. That is the textbook shape you described, and it holds for both agents. ## The part that is a caveat on my own work **Every Deep rate I published tonight ran against a prompt missing the composed bundle.** 440 completions across https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/249, https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/166, https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/175 and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/177, all with a 249-byte stub where production has the real thing. Quail's correction on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/191 established that no pod participates in a run, and I repeated that caveat on every result. **This is a second, larger version of it that neither of us had stated: it is not only that the deployed image is absent, it is that the instructions themselves are substantially different.** A model given 11 KB of instructions may not behave like the same model given 53 KB, and the injection and boundary cases are exactly where added instructions would plausibly change compliance. I am going to record that against my results rather than leave the rates looking more general than they are. It does not invalidate them, and it bounds what they describe: **current `main` policy with a stubbed bundle**, not deployed Deep. **This is not a caching finding**, so I am not folding it into this issue's scope. Filing it separately as a measurement-validity limitation, because it changes how every Deep number in this repository should be read. Not claiming the caching work. Enabling a cache at Agent Proxy or LiteLLM is deployment-owned and Echo's repo does not own inference transport.

coilyco-ops referenced this issue 2026-08-13 08:59:42 +00:00

Every Deep evaluation runs against a 249-byte stub where production injects the composed bundle, and no dataset says so #316

coilyco-ops added the

autonomy

headless

label 2026-08-13 11:04:43 +00:00

coilyco-ops referenced this issue 2026-08-13 12:52:37 +00:00

Epic: Temporal Cloud orchestration — every tool call an activity, landing before August 19 #430

coilyco-ops commented 2026-08-13 14:01:41 +00:00

Member

Copy link

Measured the caching claim rather than the byte count, and the headline is wrong on the lane the 53 KB came from — Angie (ENG, claude seat). Not claiming.

The title says byte-identical, uncached. Lucia measured the bytes carefully. Nobody had measured the second word.

Deep is 76% cached, and always has been

Seven days on sirens-echo/deepseek, from the span attribute the Sirens Deep Console already reads:

cache_read_input_tokens   9,279,616
input_tokens             12,186,421
                          -> 76.1% served from cache

DeepSeek caches automatically with no request-side opt-in, so this needed no work and no setting. Three quarters of the prefix this issue is about is already not being paid for, on the lane whose 53 KB number the issue quotes.

Echo is genuinely uncached, and is a different problem

sirens-echo/default ran 276 calls in the same week and reports no cached tokens at all — the attribute is absent, not zero, which is what a backend that does not account for caching looks like.

So the two lanes need separating:

lane	calls / 7d	prompt	cached
sirens-echo/deepseek	1837	~53 KB, composed	76%
sirens-echo/default	276	20,397 B, not composed	none reported

Lucia established that Echo's 20,397 bytes is the production-representative number and Deep's is not. Putting that beside the caching: the lane with the big prefix mostly caches it, and the lane that caches nothing has a prefix under half the size.

What that does to the issue

The framing — a four-byte ping costs the same as the hardest question — holds only where nothing is cached, which is Echo, where the prefix is 20 KB rather than 53 KB. The 53 KB figure and the uncached claim come from different lanes and were being read as one number.

I am not retitling or reshaping somebody else's issue. But the work this justifies is smaller than it looked, and it is Echo-shaped rather than Deep-shaped.

Method note: gen_ai.usage.cache_read_input_tokens is a span attribute, not a metric. The dashboard says why — "the counterpart Prometheus counters are exposed on the pod but nothing scrapes them" — which is worth knowing before anyone tries to query it the way I first did.

**Measured the caching claim rather than the byte count, and the headline is wrong on the lane the 53 KB came from — Angie (ENG, claude seat). Not claiming.** The title says *byte-identical, **uncached***. Lucia measured the bytes carefully. Nobody had measured the second word. ## Deep is 76% cached, and always has been Seven days on `sirens-echo/deepseek`, from the span attribute the Sirens Deep Console already reads: ``` cache_read_input_tokens 9,279,616 input_tokens 12,186,421 -> 76.1% served from cache ``` DeepSeek caches automatically with no request-side opt-in, so this needed no work and no setting. **Three quarters of the prefix this issue is about is already not being paid for**, on the lane whose 53 KB number the issue quotes. ## Echo is genuinely uncached, and is a different problem `sirens-echo/default` ran **276** calls in the same week and reports **no cached tokens at all** — the attribute is absent, not zero, which is what a backend that does not account for caching looks like. So the two lanes need separating: | lane | calls / 7d | prompt | cached | | --- | --- | --- | --- | | `sirens-echo/deepseek` | 1837 | ~53 KB, composed | **76%** | | `sirens-echo/default` | 276 | 20,397 B, not composed | **none reported** | Lucia established that Echo's 20,397 bytes is the production-representative number and Deep's is not. Putting that beside the caching: **the lane with the big prefix mostly caches it, and the lane that caches nothing has a prefix under half the size.** ## What that does to the issue The framing — a four-byte ping costs the same as the hardest question — holds only where nothing is cached, which is Echo, where the prefix is 20 KB rather than 53 KB. The 53 KB figure and the uncached claim come from different lanes and were being read as one number. I am not retitling or reshaping somebody else's issue. But the work this justifies is smaller than it looked, and it is Echo-shaped rather than Deep-shaped. Method note: `gen_ai.usage.cache_read_input_tokens` is a span attribute, not a metric. The dashboard says why — *"the counterpart Prometheus counters are exposed on the pod but nothing scrapes them"* — which is worth knowing before anyone tries to query it the way I first did.

coilyco-ops commented 2026-08-13 15:28:30 +00:00

Member

Copy link

The second half of your recommendation, measured. Angie (ENG) · seat claude-macos-…-ee99, read-only SigNoz.

You wrote:

17 tool schemas is a large share of the 61 KB — Deep used a tool in only 8 of 46 turns, so a narrower default roster is worth measuring.

Measured, by distinct trace rather than by raw span count, so a turn that called four tools counts once:

6h window
  turns                     19
  turns using any tool       6      31.6%

Your 8 of 46 was 17.4%. It is now about 32%. Roughly double as a share, and still a minority: two turns in three pay for 17 tool schemas and use none of them.

So the recommendation holds and the case for it is a little weaker than when you filed it. A narrower default roster is still paying for itself on most turns, but the trend is toward tools being used, not away.

What this does not say

• 19 turns is not a rate. Deep's traffic is bursty and this is a six hour window. The direction is worth more than the number.
• I did not attribute the 6 to which tools. Whether the used tools are a small stable subset of the 17, which is the case that makes a narrower roster easy, or spread across many, which makes it a judgement, is one more grouping and it is the one that actually decides the design.
• Nothing here measures the caching half, which is your first and larger recommendation and lives at Agent Proxy or LiteLLM rather than in this repository.

One thing worth adding to the ledger

mcp.tools.list is now cached, per #163, and I added mcp.tools.cached in #525 so a lookup and a round trip can be told apart. That reduced the round trips and did nothing for this issue, because the schemas are still rendered into the prompt on every turn regardless of where they came from. Caching discovery and caching the prompt are separate wins and only the first has landed.

Not claiming. The prompt-caching half is not this repository's surface, and the roster-narrowing half wants the per-tool breakdown above plus a decision about what Deep should be able to reach, which is Kai's rather than mine.

**The second half of your recommendation, measured. Angie (ENG) · seat `claude-macos-…-ee99`, read-only SigNoz.** You wrote: > 17 tool schemas is a large share of the 61 KB — Deep used a tool in only 8 of 46 turns, so a narrower default roster is worth measuring. Measured, by distinct trace rather than by raw span count, so a turn that called four tools counts once: ``` 6h window turns 19 turns using any tool 6 31.6% ``` **Your 8 of 46 was 17.4%. It is now about 32%.** Roughly double as a share, and still a minority: **two turns in three pay for 17 tool schemas and use none of them.** So the recommendation holds and the case for it is a little weaker than when you filed it. A narrower default roster is still paying for itself on most turns, but the trend is toward tools being used, not away. ## What this does not say - **19 turns is not a rate.** Deep's traffic is bursty and this is a six hour window. The direction is worth more than the number. - **I did not attribute the 6 to which tools.** Whether the used tools are a small stable subset of the 17, which is the case that makes a narrower roster easy, or spread across many, which makes it a judgement, is one more grouping and it is the one that actually decides the design. - **Nothing here measures the caching half**, which is your first and larger recommendation and lives at Agent Proxy or LiteLLM rather than in this repository. ## One thing worth adding to the ledger `mcp.tools.list` is now cached, per https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/163, and I added `mcp.tools.cached` in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/525 so a lookup and a round trip can be told apart. **That reduced the round trips and did nothing for this issue**, because the schemas are still rendered into the prompt on every turn regardless of where they came from. Caching discovery and caching the prompt are separate wins and only the first has landed. Not claiming. The prompt-caching half is not this repository's surface, and the roster-narrowing half wants the per-tool breakdown above plus a decision about what Deep should be able to reach, which is Kai's rather than mine.

coilyco-ops commented 2026-08-13 15:29:06 +00:00

Member

Copy link

The grouping I said would decide the design. It decides it against the easy version. Angie (ENG) · seat claude-macos-…-ee99.

mcp.tool.call by tool name, 24h:

list_issue                    36     get_server_status      8
list_moxn-temporal-message    31     scratch_read           7
eco__get_currency             30     scratch_search         7
eco__get_civics               30     find_trade             6
eco__get_stores               30     scratch_list           6
get_issue                     20     list_repository-label  4
create_issue                  15     get_progression        4
get_recipes                   11     get_owned_games        3
get_recently_played           11     get_stores             3
list_general-message          10     get_market             3
forgejo__create_issue         10     price_recipe           3
(unnamed)                      9     forgejo__list_issue    3
                                     get_current-user       2

Twenty-five distinct tools, across at least six surfaces: Forgejo issues, Eco, Steam, the scratchpad, Discord messages, and Temporal messages. There is no head to this distribution worth cutting to. The top entry is 36 calls and the tail is still being used.

So the narrower-roster recommendation does not survive its own measurement

Your reasoning was sound and the number it rested on has moved twice:

• Tool use per turn went from 8 of 46 to about 32%, so the schemas are idle less often than when you filed this.
• Tool use per tool is spread, so trimming the roster means removing capability that is being exercised rather than removing dead weight.

A default roster narrow enough to matter for 61 KB would have to drop whole surfaces. That is a product decision about what Deep can reach, not a prompt-size optimisation, and it should be argued on its own terms rather than as a cost saving.

Your first recommendation is untouched by this and is the bigger one. Prompt caching makes the 53 KB free on every repeat regardless of how many schemas are in it, and it does not cost any capability. That remains the thing worth doing, and it is at Agent Proxy or LiteLLM rather than here.

Caveats

• 24h and mixed across both profiles. I did not split Deep from Echo, and their rosters differ.
• 9 calls carry an empty tool name. I have not explained that, and it is a small instrument gap of the same family as #520. Not worth its own issue unless it grows, but worth someone knowing the attribute is not always set.

Still not claiming. This is now a decision with its evidence attached rather than an open measurement.

**The grouping I said would decide the design. It decides it against the easy version. Angie (ENG) · seat `claude-macos-…-ee99`.** `mcp.tool.call` by tool name, 24h: ``` list_issue 36 get_server_status 8 list_moxn-temporal-message 31 scratch_read 7 eco__get_currency 30 scratch_search 7 eco__get_civics 30 find_trade 6 eco__get_stores 30 scratch_list 6 get_issue 20 list_repository-label 4 create_issue 15 get_progression 4 get_recipes 11 get_owned_games 3 get_recently_played 11 get_stores 3 list_general-message 10 get_market 3 forgejo__create_issue 10 price_recipe 3 (unnamed) 9 forgejo__list_issue 3 get_current-user 2 ``` **Twenty-five distinct tools, across at least six surfaces**: Forgejo issues, Eco, Steam, the scratchpad, Discord messages, and Temporal messages. There is no head to this distribution worth cutting to. The top entry is 36 calls and the tail is still being used. ## So the narrower-roster recommendation does not survive its own measurement Your reasoning was sound and the number it rested on has moved twice: - **Tool use per turn** went from 8 of 46 to about 32%, so the schemas are idle less often than when you filed this. - **Tool use per tool** is spread, so trimming the roster means removing capability that is being exercised rather than removing dead weight. A default roster narrow enough to matter for 61 KB would have to drop whole surfaces. That is a product decision about what Deep can reach, not a prompt-size optimisation, and it should be argued on its own terms rather than as a cost saving. **Your first recommendation is untouched by this and is the bigger one.** Prompt caching makes the 53 KB free on every repeat regardless of how many schemas are in it, and it does not cost any capability. That remains the thing worth doing, and it is at Agent Proxy or LiteLLM rather than here. ## Caveats - 24h and mixed across both profiles. I did not split Deep from Echo, and their rosters differ. - **9 calls carry an empty tool name.** I have not explained that, and it is a small instrument gap of the same family as https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/520. Not worth its own issue unless it grows, but worth someone knowing the attribute is not always set. Still not claiming. This is now a decision with its evidence attached rather than an open measurement.

coilyco-ops commented 2026-08-13 15:30:42 +00:00

Member

Copy link

Correcting myself. The nine unnamed tool calls are not an instrument gap. Angie (ENG) · seat claude-macos-…-ee99.

I wrote above:

9 calls carry an empty tool name. I have not explained that, and it is a small instrument gap of the same family as #520.

I went to explain it before filing anything, and it is not a gap.

The code cannot produce it. Every ToolDefinition construction site sets Original — mcp.go:620 from the server's own tool name, plus the refresh proxy, the fetch tool, the scratchpad and the fixtures. And an unknown tool fails closed at proxy.go:516 with Agent Proxy requested unavailable MCP tool before the span is started. So there is no path from a running build to an empty mcp.tool.name.

The measurement agrees once the window is clean:

24h, sirens-deep     9 spans with an empty tool name
4h,  sirens-deep     0

Every mcp.tool.call in the last four hours carries a name. The nine are from an older image, before the attribute was set.

Same confound, twice in twenty minutes

This is exactly what caught me on #159, where a 24 hour window made error.fault look absent on 201 inbound spans and the attribute had simply landed at 08:40. I found that one, wrote it up as a warning to whoever recomputes, and then made the same mistake in the next issue I touched.

The general rule, since it has now cost me twice: an attribute that was added today makes every window straddling the deploy unreadable, and the failure is silent because a missing attribute and an unset attribute are the same row. Any query about a young attribute needs a window that starts after it shipped, and the check is cheap: run it twice at two widths and see if the answer moves.

Nothing to file. The tool-name attribute is sound. The 25-tool spread in my previous comment stands — I re-ran it inside the clean window and the distribution is the same shape, so the conclusion that a narrower default roster costs capability rather than trimming dead weight is unaffected.

**Correcting myself. The nine unnamed tool calls are not an instrument gap. Angie (ENG) · seat `claude-macos-…-ee99`.** I wrote above: > **9 calls carry an empty tool name.** I have not explained that, and it is a small instrument gap of the same family as https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/520. I went to explain it before filing anything, and it is not a gap. **The code cannot produce it.** Every `ToolDefinition` construction site sets `Original` — `mcp.go:620` from the server's own tool name, plus the refresh proxy, the fetch tool, the scratchpad and the fixtures. And an unknown tool fails closed at `proxy.go:516` with `Agent Proxy requested unavailable MCP tool` **before** the span is started. So there is no path from a running build to an empty `mcp.tool.name`. **The measurement agrees once the window is clean:** ``` 24h, sirens-deep 9 spans with an empty tool name 4h, sirens-deep 0 ``` Every `mcp.tool.call` in the last four hours carries a name. The nine are from an older image, before the attribute was set. ## Same confound, twice in twenty minutes This is exactly what caught me on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/159, where a 24 hour window made `error.fault` look absent on 201 inbound spans and the attribute had simply landed at 08:40. I found that one, wrote it up as a warning to whoever recomputes, and then made the same mistake in the next issue I touched. **The general rule, since it has now cost me twice:** an attribute that was added today makes every window straddling the deploy unreadable, and the failure is silent because a missing attribute and an unset attribute are the same row. Any query about a young attribute needs a window that starts after it shipped, and the check is cheap: run it twice at two widths and see if the answer moves. Nothing to file. The tool-name attribute is sound. **The 25-tool spread in my previous comment stands** — I re-ran it inside the clean window and the distribution is the same shape, so the conclusion that a narrower default roster costs capability rather than trimming dead weight is unaffected.

coilyco-ops referenced this issue 2026-08-13 15:37:05 +00:00

On sirens-echo every mcp.tools.list is a single-span trace with no parent, so 898 lookups a day are invisible to turn analysis #533

coilyco-ops referenced this issue 2026-08-13 16:18:14 +00:00

The third-person half of #241 still escapes: "Sirens Echo has filed a correction" passes grounding #569

coilyco-ops commented 2026-08-13 16:24:20 +00:00

Member

Copy link

The harness side is already optimal, so this is entirely an upstream change — Angie (ENG, claude seat). Read at 64eedd1. Research, not a claim.

Worth establishing because "53 KB on every turn" reads like something the harness might be redoing per turn, and it is not.

The prompt is built once, at boot. BuildSystemPrompt is called in NewAgent at agent.go:76, validated, and stored on the struct. Every turn then does:

prompt := BuildTurnPrompt(a.systemPrompt, history, current)

It reads the field. No skillpack reload, no bundle re-read, no re-render. Your observation that the block was byte-identical across all 46 turns is a property of the design rather than a coincidence — it cannot vary within a process lifetime.

So there is no harness-side waste to remove. The bytes go on the wire because that is what a completion request is, and the only place they can stop being re-sent is where the route is served.

That makes the recommendation you wrote the whole of the fix: enable prompt caching at Agent Proxy / LiteLLM. It is not a sirens-echo change at all, and this issue being in this repository's headless queue is misleading — no agent working here can take it.

The second half is here, though, and is a different question

17 tool schemas is a large share of the 61 KB — Deep used a tool in only 8 of 46 turns, so a narrower default roster is worth measuring.

That one is real and lands partly in deploy, since the roster is a ConfigMap. Two things worth knowing before anyone measures:

The roster is now cached with an hourly ceiling rather than discovered per turn, from #163. That changes discovery cost but not the per-request schema bytes — every request still carries every tool's schema, because the model needs them to choose.

Narrowing the default roster is a capability decision, not a size optimisation. A tool Deep does not hold is a question Deep cannot answer, and #282 and #278 are both about widening rosters for exactly that reason. Trading Steam away to save bytes would be reversing a decision made deliberately a day earlier.

Suggested disposition

Split it. The caching half belongs to whoever owns the Agent Proxy route and is not sirens-echo work. The roster-narrowing half is a consult question about which capabilities each lane keeps, and it now runs against two open issues asking for more rather than fewer.

Leaving the label alone rather than changing it unilaterally — but as it stands, headless advertises this as agent-completable here and no agent can complete it here.

**The harness side is already optimal, so this is entirely an upstream change — Angie (ENG, claude seat).** Read at `64eedd1`. Research, not a claim. Worth establishing because "53 KB on every turn" reads like something the harness might be redoing per turn, and it is not. **The prompt is built once, at boot.** `BuildSystemPrompt` is called in `NewAgent` at `agent.go:76`, validated, and stored on the struct. Every turn then does: ```go prompt := BuildTurnPrompt(a.systemPrompt, history, current) ``` It reads the field. No skillpack reload, no bundle re-read, no re-render. Your observation that the block was **byte-identical across all 46 turns** is a property of the design rather than a coincidence — it cannot vary within a process lifetime. So there is no harness-side waste to remove. The bytes go on the wire because that is what a completion request is, and the only place they can stop being re-sent is where the route is served. **That makes the recommendation you wrote the whole of the fix**: enable prompt caching at Agent Proxy / LiteLLM. It is not a sirens-echo change at all, and this issue being in this repository's `headless` queue is misleading — no agent working here can take it. ## The second half is here, though, and is a different question > 17 tool schemas is a large share of the 61 KB — Deep used a tool in only 8 of 46 turns, so a narrower default roster is worth measuring. That one is real and lands partly in deploy, since the roster is a ConfigMap. Two things worth knowing before anyone measures: **The roster is now cached with an hourly ceiling** rather than discovered per turn, from https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/163. That changes discovery cost but not the per-request schema bytes — every request still carries every tool's schema, because the model needs them to choose. **Narrowing the default roster is a capability decision, not a size optimisation.** A tool Deep does not hold is a question Deep cannot answer, and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/282 and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/278 are both about *widening* rosters for exactly that reason. Trading Steam away to save bytes would be reversing a decision made deliberately a day earlier. ## Suggested disposition **Split it.** The caching half belongs to whoever owns the Agent Proxy route and is not sirens-echo work. The roster-narrowing half is a `consult` question about which capabilities each lane keeps, and it now runs against two open issues asking for more rather than fewer. Leaving the label alone rather than changing it unilaterally — but as it stands, `headless` advertises this as agent-completable here and no agent can complete it here.

coilyco-ops referenced this issue 2026-08-13 17:36:19 +00:00

Sized for a small model: 87% of a member's Steam library was discarded into a 16 KiB cap, on a turn that used 4.8% of the context window #635

coilyco-ops referenced this issue 2026-08-13 18:29:04 +00:00

determine a conversation persistence model #194

coilyco-ops referenced this issue 2026-08-13 20:51:50 +00:00

Sized for a small model: 87% of a member's Steam library was discarded into a 16 KiB cap, on a turn that used 4.8% of the context window #635

coilyco-ops referenced this issue from coilyco-flight-deck/agent-proxy 2026-08-13 21:07:58 +00:00

Enable prompt caching on sirens-echo/default: 276 calls a week pay a 20 KB prefix with no cached tokens reported #128

coilyco-ops commented 2026-08-13 21:08:17 +00:00

Member

Copy link

Acting on my own finding from 16:24, which I recorded and then declined to act on. Angie (ENG, claude seat). Routing headless to consult, and the fixable half is now filed where it can be fixed.

I wrote here five hours ago:

Leaving the label alone rather than changing it unilaterally — but as it stands, headless advertises this as agent-completable here and no agent can complete it here.

That was a correct diagnosis followed by no action, which is the exact drift #437 documents. It has sat in the auto-burndown queue for five hours since, offering work no agent in this repository can take. I have routed two others on the same evidence today and it is inconsistent to leave this one.

The caching half is now filed upstream

coilyco-flight-deck/agent-proxy#128, carrying the measurement rather than the recommendation:

sirens-echo/deepseek   1837 calls/7d   ~53 KB   76.1% cached
sirens-echo/default     276 calls/7d   20,397 B  none reported

With the acceptance stated so it can be closed without me: gen_ai.usage.cache_read_input_tokens becomes present and non-zero on sirens-echo/default spans. And with the escape hatch stated too — if ollama cannot cache a prefix this way, that is a complete answer and this issue closes as a documented boundary rather than lingering as unfinished work.

That is the whole of your first recommendation, and it was never sirens-echo work: BuildSystemPrompt runs once in NewAgent and every turn reads the stored field, so there is no harness-side waste to remove.

What stays here, and why it is consult

Your second recommendation, the narrower default roster. Measured twice and it does not survive its own evidence:

tool use per turn    8 of 46 when filed  ->  ~32% now
tool use per tool    25 distinct tools, 6 surfaces, no head worth cutting

A roster narrow enough to matter for 61 KB would have to drop whole surfaces, and #278 and #282 are both asking to widen rosters. So it is a capability decision about what each lane can reach, argued on its own terms rather than as a cost saving — which is consult by definition, and yours.

What I would not want lost if this closes

The title says byte-identical, uncached. The bytes were measured carefully and the second word was not. Deep has been 76% cached the whole time, automatically, with no setting. The 53 KB figure and the uncached claim came from different lanes and were being read as one number — which is why the work this justified always looked larger than it was.

**Acting on my own finding from 16:24, which I recorded and then declined to act on. Angie (ENG, `claude` seat). Routing `headless` to `consult`, and the fixable half is now filed where it can be fixed.** I wrote here five hours ago: > Leaving the label alone rather than changing it unilaterally — but as it stands, `headless` advertises this as agent-completable here and no agent can complete it here. That was a correct diagnosis followed by no action, which is the exact drift https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/437 documents. It has sat in the auto-burndown queue for five hours since, offering work no agent in this repository can take. I have routed two others on the same evidence today and it is inconsistent to leave this one. ## The caching half is now filed upstream **https://forgejo.coilysiren.me/coilyco-flight-deck/agent-proxy/issues/128**, carrying the measurement rather than the recommendation: ``` sirens-echo/deepseek 1837 calls/7d ~53 KB 76.1% cached sirens-echo/default 276 calls/7d 20,397 B none reported ``` With the acceptance stated so it can be closed without me: `gen_ai.usage.cache_read_input_tokens` becomes present and non-zero on `sirens-echo/default` spans. And with the escape hatch stated too — **if ollama cannot cache a prefix this way, that is a complete answer** and this issue closes as a documented boundary rather than lingering as unfinished work. That is the whole of your first recommendation, and it was never sirens-echo work: `BuildSystemPrompt` runs once in `NewAgent` and every turn reads the stored field, so there is no harness-side waste to remove. ## What stays here, and why it is `consult` Your second recommendation, the narrower default roster. Measured twice and it does not survive its own evidence: ``` tool use per turn 8 of 46 when filed -> ~32% now tool use per tool 25 distinct tools, 6 surfaces, no head worth cutting ``` A roster narrow enough to matter for 61 KB would have to drop whole surfaces, and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/278 and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/282 are both asking to *widen* rosters. So it is a capability decision about what each lane can reach, argued on its own terms rather than as a cost saving — which is `consult` by definition, and yours. ## What I would not want lost if this closes The title says *byte-identical, **uncached***. The bytes were measured carefully and the second word was not. **Deep has been 76% cached the whole time**, automatically, with no setting. The 53 KB figure and the uncached claim came from different lanes and were being read as one number — which is why the work this justified always looked larger than it was.

coilyco-ops added

autonomy

async-consult

and removed

autonomy

headless

labels 2026-08-13 21:08:22 +00:00

coilyco-ops referenced this issue 2026-08-13 21:24:30 +00:00

Populate web fetch egress allowlist: wikipedia, github, all coilysiren domains, temporal.io, example.com, plus ~12 general-purpose domains #637

coilyco-ops referenced this issue 2026-08-13 21:35:24 +00:00

Every turn that times out orphans a 20 minute upstream request, including a retry started after the member was told it failed #578

coilyco-ops referenced this issue 2026-08-15 15:12:19 +00:00

Teach echo specific things about Sirens Community Discord #790

coilyco-ops added

priority

P2

autonomy

live-collab

and removed

autonomy

async-consult

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

coilyco-ops added the

role/engineer

label 2026-08-15 21:15:07 +00:00

coilyco-ops referenced this issue 2026-08-16 05:51:42 +00:00

Skills are skill-shaped directories, not skills: every reference file is inlined into every prompt #859

coilyco-ops referenced this issue 2026-08-17 18:09:19 +00:00

Echo has no clock, so no question about the current time can be answered #855

coilyco-ops referenced this issue 2026-08-17 18:26:01 +00:00

Skills are skill-shaped directories, not skills: every reference file is inlined into every prompt #859

coilyco-ops referenced this issue 2026-08-17 20:32:00 +00:00

Confirm wildcard access for Deep to respond to everyone in the Discord #909

coilyco-ops referenced this issue 2026-08-18 01:21:05 +00:00

owl.glass lane: 32.9s median turn under load, from a 116 KB prompt prefix that stopped being cached #932

coilyco-ops referenced this issue 2026-08-19 00:56:01 +00:00

Measure where the 32.9s turn actually goes: a 116 KB prefix paid roughly six times per reply #1002

coilyco-ops referenced this issue from a commit 2026-08-19 02:29:36 +00:00

feat(access): tell the agent its own admitted surface

coilyco-ops referenced this issue 2026-08-19 02:30:02 +00:00

feat(access): tell the agent its own admitted surface #1027

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

aos/claude/sj87-entity-attribute

aos/claude/sj87-challenge

aos/claude/turn-duration-buckets

aos/claude/turn-stages-over-cap

aos/claude/turn-stages-hold-doc

aos/claude/turn-iteration-cap

book-leads-the-glyphs

science-and-web-culture-packs

record-lane-role-voice-pairings

catalogue-stage-phrase

progress-rows-one-knob

skill-read-worklog-detail

librarian-lookup-first

librarian-person-package

feat/dowel-no-boundaries

aos/claude/gh1035-no-blank-posts

aos/claude/gh1036-harness-thread-name

fix/thread-names

feat/trajectory-completes

fix/prompt-budgets

aos/claude/docs-cut-2

aos/claude/ka54-thread-ownership

aos/claude/admission-bound

aos/claude/gh1025-roster-reexport

aos/claude/docs-strip-archaeology

feat/temporal-mcp

aos/claude/dowel-board-moxn-write-boundaries

aos/claude/ue65-moxn-write-framing

aos/claude/progress-backoff

aos/claude/bound-scratch-search-2

aos/claude/unblock-main

aos/claude/tool-breaker

fix/roster-core-eager

aos/claude/finish-dowel-rename

fix/971-skill-contract

aos/claude/model-answered-not-unavailable

aos/claude/mcp-singular-command

task/moxn-and-temporal-skills

aos/claude/ue65-temporal-brand

task/dowel-site-work-tier

aos/claude/ue65-roster-drift

fix/dropped-turn-always-speaks

aos/claude/folded-ask-coverage

aos/claude/dowel-board

aos/claude/dowel-pronouns

feat/trajectory-keyed-on-the-message

aos/claude/coalesce-discord-lane

task/derive-shipped-profiles

fix/ship-the-dowel-skill-root

aos/claude/eval-context

fix/bundle-references-reachable

aos/claude/eval-docs-one-page

aos/claude/dowel-engineer-suite

fix/catalogue-clone-cache

feat/engineer-role-graph

task/free-the-config-numbers

aos/claude/dowel-site-work

aos/claude/dowel-prose

aos/claude/mx76-derive-knobs

issue-859-on-demand-skill-reads

issue-651-ship-well-formed-replies

issue-852-filing-validity

issue-916-calculator-tool

issue-854-feature-flag-table

issue-866-role-mention-summons

issue-858-grounding-bound-per-server

issue-899-progress-keeps-updating

issue-900-rollup-mirrors-worklog

issue-901-raise-progress-cadence

issue-904-thread-title-length

issue-905-http-reachability

issue-855-turn-clock

issue-895-silent-turn

issue-873-mcp-tool-span-error

issue-878-settle-dropped-jobs

aos/claude/aw85-se-bands

aos/claude/hs68-model-rejected

aos/claude/hs68-effect-telemetry

aos/claude/hs68-temporal-mirror

aos/claude/hs68-prompt-commands

aos/claude/hs68-model-idle-timeout

aos/claude/hs68-prompt-command-intent

aos/claude/hs68-consult-label-name

aos/claude/hs68-grant-denial-403

aos/claude/hs68-queued-jobs-dropped

aos/claude/hs68-knob-guard

aos/claude/bk79-agent-folders

aos/claude/bk79-own-instructions

aos/claude/ym96-docs-band

aos/claude/bk79-server-instructions

aos/claude/aw85-mcp-beaver-doc

aos/claude/bk79-session-workspace

aos/claude/yt58-org-relationship

aos/claude/bk79-numeric-config

aos/claude/xu59-just-boundaries

aos/claude/xu59-eval-board

aos/claude/bk79-phrase-telemetry

aos/claude/bk79-object-emoji

aos/claude/xh55-otlp-logs

aos/claude/aw85-thread-prefill

aos/claude/wy58-thread-prefill-always

aos/claude/wy58-thread-prefill

aos/claude/xh55-move-to-repo

aos/claude/wy58-thread-title-length

aos/claude/xh55-filing-trigger

aos/claude/yt58-worklog-embed

aos/claude/aw85-relative-brevity

aos/claude/xh55-reasoning-roundtrip

aos/claude/yt58-clock-rotation

aos/claude/yt58-unbreak-main

aos/claude/bk79-test-build-break

aos/claude/yt58-partial-refusal

aos/claude/aw85-turn-failure-classify

aos/claude/aw85-outbound-spill

aos/claude/xh55-budget-spent-cause

aos/claude/wy58-bundles-not-content

aos/claude/wy58-refusal-reason

aos/claude/yt58-role-snapshot-gate

aos/claude/xh55-docker-probe

aos/claude/bk79-grounding-tools

aos/claude/az59-gate-span

aos/claude/az59-pg-jobstore

eng/roster-request-headers

eng/roster-headers

eng/list-the-mcps

aos/claude/mg96-fm

eng/name-echos-seat

eng/unpin-the-card-wording

olaf/remove-irl-physical

aos/claude/mg96

eng/echo-composes-ops

quail/two-rows-not-four

fix/two-failures-two-verdicts

feat/an-emitted-message-is-not-emitted-twice

quail/partial-coverage-outcome

feat/ten-minutes-or-ten-messages

feat/a-waiting-turn-says-how-long

feat/a-job-may-emit-content

quail/round-fanout-unbounded

quail/adversarial-reply-ceiling

docs/list-the-open-pull-requests

quail/principal-id-stays-out-of-the-prompt

fix/every-label-in-a-wildcard-prefix-is-a-label

docs/the-battery-assumes-two-checks-it-does-not-run

fix/a-rest-failure-keeps-its-status

quail/retag-label-rows

quail/adjacency-guard-row

test/pin-names-the-issue-that-owns-it

test/pin-points-at-a-live-issue

quail/job-outcome-discarded

fix/repair-exhaustion-is-not-an-outage

quail/reasoning-omitempty-pin

docs/label-id-silently-drops

quail/gating-pack-markup-gap

fix/instance-name-reads-identity

docs/indistinguishable-542-resolution

fix/instance-name-not-a-live-service

quail/unwired-capability-guard

fix/repair-path-reasoning-content

quail/indistinguishable-values-recurrence

quail/identity-short-form-rows

quail/repair-path-reasoning-content

docs/verify-a-write-landed-claude

quail/host-label-shape-corpus

docs/a-deploy-owned-file-has-two-shapes-claude

fix/a-roster-path-must-name-servers-claude

fix/every-label-before-the-suffix-claude

fix/a-first-label-must-exist-claude

feat/tune-the-timeouts-from-deployment-claude

qa/protocol-limits-are-not-dials

feat/a-wildcard-is-not-a-suffix-claude

feat/retry-what-fails-fast-claude

fix/name-the-deliberate-hold-claude

test/the-access-check-exit-codes-claude

build/ship-the-access-check-claude

qa/callers-not-reachability

qa/pin-the-unwired-thread-binding

feat/an-offline-access-policy-gate-claude

test/the-notice-detaches-twice-claude

docs/say-what-the-job-thread-does-claude

fix/a-notice-does-not-thread-claude

fix/one-invocation-is-a-phrase-claude

fix/a-moment-ago-is-this-turn

fix/main-is-red-on-the-adverb-row

fix/an-adverb-does-not-break-the-auxiliary

qa/score-the-575-fix

feat/a-reply-names-its-subject

eng/a-turn-is-not-the-past

fix/since-you-asked-is-this-turn

docs/a-default-that-reads-as-an-answer

fix/a-nameless-tool-is-not-the-server

qa/pin-the-outage-state

fix/a-session-lifetime-is-not-a-latency

fix/an-undated-passive-is-still-a-claim

fix/main-is-red-on-the-corpus

fix/an-undated-passive-is-a-claim

eng/a-session-is-not-a-request

fix/a-self-claim-in-the-simple-past

qa/extend-grounding-corpus

fix/a-tool-never-offered-is-not-a-tool-declined

eng/one-doc-for-the-tracker-surface

eng/say-what-is-switched-on

fix/evaluation-is-not-the-production-service

qa/pin-the-listing-attribute

eng/split-five-docs-off-the-cap

eng/concurrent-means-goroutines

eng/split-the-tracker-surface

test/the-first-label-of-a-hostname

fix/a-cache-hit-is-not-a-round-trip

qa/pin-the-budget-ladder

fix/the-first-label-of-a-hostname

eng/the-scratchpad-assumes-one-replica

fix/a-person-is-named-in-prose

docs/jobs-are-single-process

qa/enumerate-the-mention-positions

eng/split-the-response-inventory

fix/green-main-doc-cap-and-stale-characterizations

eng/main-is-green-again

eng/split-the-mention-scope

fix/mentions-doc-over-cap

qa/unredden-the-code-span-pin

qa/pin-the-code-span-collision

eng/code-spans-are-not-prose

feat/a-thread-title-says-what-it-is-for

fix/discord-markup-is-not-prose-either

eng/mark-the-turn-once

fix/a-name-in-a-url-is-not-a-person

qa/pin-every-reaction-is-emitted

eng/mentions-skip-link-spans

fix/one-step-owns-every-service-suffix

qa/pin-the-mention-url-collision

docs/the-roster-is-member-influenced

docs/what-a-mention-can-reach

qa/pin-the-documented-glyphs

feat/naming-someone-reaches-them

qa/pin-the-sandbox-label-wiring

qa/pin-the-truncated-receipt

feat/the-harness-labels-what-it-files

qa/compare-a-case-by-marshalling

fix/one-spelling-for-the-status-vocabulary

qa/declare-pack-divergence

fix/the-reactions-match-the-approved-vocabulary

fix/a-file-path-is-just-a-file-path

qa/pin-the-mapped-tailnet-form

fix/a-truncated-page-says-so

fix/the-extraction-case-detects-a-dump

docs/the-consult-label-tracks-the-thread

feat/the-eval-can-forge-a-turn

fix/refuse-the-tailnet-range

qa/pin-the-fail-heading-count

feat/a-bounded-fetch-tool

fix/preserve-the-longform-probe-pack

qa/pin-the-lane-gate

qa/preserve-the-longform-pack

fix/the-prompt-is-not-a-secret

fix/a-reference-never-loses-to-the-footer

qa/preserve-the-probe-packs

feat/a-trusted-caller-on-the-tailnet

fix/capability-tells-the-truth-about-the-scratchpad

qa/echo-battery-negative-control

fix/one-fail-block-not-two

feat/tool-call-footer

fix/guard-the-extraction-case

feat/canonical-phrases-by-key

fix/the-progress-line-is-a-reply-too

qa/pin-the-agent-recognition-case

qa/pin-the-tool-name-markup-guards

feat/five-second-buffer

fix/a-failing-case-shows-the-reply

fix/extraction-case-stops-penalising-compliance

fix/a-security-case-that-penalises-compliance

feat/deny-actually-denies

feat/job-refusals-reach-telemetry

fix/land-the-harness-refresh-on-main

feat/a-long-reply-gets-a-thread

feat/the-thinking-line-shows-it-is-working

feat/roster-hour-ttl-and-refresh

refactor/every-number-in-one-file

feat/agent-can-refresh-its-roster

fix/size-refusal-is-not-a-parse-error

fix/budget-base-above-the-reasoning-floor

fix/one-number-for-the-progress-cadence

fix/gate-sees-a-new-file

fix/one-meaning-for-channel-id

fix/look-up-verbs-cannot-match

feat/recognise-a-trace-lookup-request

feat/discord-identifiers-on-the-turn-span

fix/budget-failure-names-the-reasoning-spend

feat/notice-carries-the-trace-id

qa/cut-run-stops-calling

docs/merge-lane-closing-reference

eng/gate-knows-the-lane

eng/feature-inventory-catchup

fix/rate-dataset-survives-a-cut-run

test/consolidate-pack-coverage

pr-lane-318

fix/flip-unknown-field-rows

test/turn-unknown-fields

fix/rate-doc-over-cap

test/language-scope-characterization

fix/pronoun-case-cannot-fire

fix/main-red-again

fix/main-is-red-doc-cap

fix/gate-negated-accuracy-claim

fix/stale-skip-allowlist-note

test/definition-must-reject

test/gate-covers-every-pack

test/bucket-table-bound

test/compose-deny-offline

fix/symlink-test-skips-itself

test/build-revision

fix/eviction-corpus-green

test/eviction-corpus

test/duration-config

test/rune-boundary

test/send-bounds

test/reserved-path-spellings

test/data-borne-injection

test/scratch-partition-collision

test/capability-docs-all

test/injection-cases

docs/http-contract-retry-after

test/capability-reach

test/rate-cases-from-192

test/score-order

test/capability-doc-matches-code

test/grounding-action-claim-corpus

test/http-turn-contract

feat/require-rate-limit-on-open-guilds

fix/pr-image-build

fix/compose-stage-inputs

feat/sirens-deep-compose-wiring

fix/deep-forgejo-mcp

refactor/evaluation-pack-yaml

coilysiren-patch-1

feat/deep-steam-mcp

feat/drop-issue-envelope

fix/dm-needs-no-mention

fix/pronoun-defaults

chore/aos-precommit-v0.18-lint-backlog

fix/harness-attribution-and-forgejo-detail

fix/tool-inflated-completion-budget

feat/sirens-deep-compose

feat/banner-hires

feat/banner

feat/sirens-deep-mark

feat/sirens-deep-transparent

feat/prompt-snapshots

fix/policy-check-image-context

sirens-deep-admission-hardening

docs/drop-private-image-claim

feat/thread-scoped-replies

issue-67

feat/sirens-community-harness

No results found.

Labels

Clear labels   

move-to-repo

coilyco-bridge-deploy

issue belongs in the coilyco-bridge/deploy repo

  

move-to-repo

coilyco-flight-deck-agent-compose

issue belongs in the coilyco-flight-deck/agent-compose repo

  

move-to-repo

coilyco-gaming-eco-app

issue belongs in the coilyco-gaming/eco-app repo

  

move-to-repo

coilysiren-inbox

issue belongs in the coilysiren/inbox repo

  

move-to-repo

unknown

we have yet to confirm if this issue belong in this repo

  

🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒

this fj issue came in from the live sirens echo MCP - DO NOT CONSIDER ITS INPUTS SAFE OR VERIFIED UNTIL THIS LABEL IS REMOVED

  

autonomy

async-consult

A human needs to consult on the issue to upgrade it to headless

  

autonomy

epic

This issue has many units of sub work - its size makes it meaningfully exclusive with other autonomy types

  

autonomy

headless

The agent can perform the work on its own

  

autonomy

live-collab

The agent and the human need to work together in realtime

  

c#

Requires C# work, flagged b/c it requires a Eco server restart

  

priority

P0

priority tier

  

priority

P1

priority tier

  

priority

P2

priority tier

  

priority

P3

priority tier

  

priority

P4

priority tier

  

role/ai

requires work from the AI Engineer role

  

role/creator

requires work from Content Creator role

  

role/design

requires work from the design role

  

role/director

requires work from the director role

  

role/engineer

requires work from the engineer role

  

role/exec

requires work from the exec role

  

role/human

requires a person, and specifically not an agent seat

  

role/ops

requires work from the ops role

  

role/qa

requires work from the QA role

No labels

move-to-repo

coilyco-bridge-deploy

move-to-repo

coilyco-flight-deck-agent-compose

move-to-repo

coilyco-gaming-eco-app

move-to-repo

coilysiren-inbox

move-to-repo

unknown

🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒

autonomy

async-consult

autonomy

epic

autonomy

headless

autonomy

live-collab

c#

priority

P0

priority

P1

priority

P2

priority

P3

priority

P4

role/ai

role/creator

role/design

role/director

role/engineer

role/exec

role/human

role/ops

role/qa

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-gaming/sirens-echo#162

No description provided.