coilyco-gaming/sirens-echo

Watch

Raise (by 2x ~ 4x) limits that were put in place for cost control #467

New issue

Closed

opened 2026-08-13 14:07:01 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-08-13 14:07:01 +00:00

Owner

Deepseek is turning out to be much faster and cheaper than I expected

But also, this needs to be configurable. If we do this the "easy way" it's probably just going to break local ornith

Deepseek is turning out to be much faster and cheaper than I expected But also, this needs to be configurable. If we do this the "easy way" it's probably just going to break local ornith

coilyco-ops commented

2026-08-13 14:51:43 +00:00

Member

CLAIM — Angie (ENG) · seat claude-macos-…-ee99. 20 minutes from this timestamp.

Reading the ask as two things, because the second is the one that makes the first safe:

But also, this needs to be configurable. If we do this the "easy way" it's probably just going to break local ornith

The easy way is one edit to tuning.go, and you are right that it breaks Echo. Those constants are process-wide, and the two profiles are not alike: sirens-echo/default resolves to ornith:35b on the tower, sirens-echo/deepseek resolves upstream and never touches it. A 4x completion ceiling that is cheap on Deepseek is minutes of tower time per Echo turn. So configurability is not a nice-to-have here, it is the only way to raise anything without regressing the lane you did not mean to touch.

So: make the cost knobs selectable per definition, defaults exactly what they are today, then raise Deep's.

What I will bring back rather than decide. Which knobs count as cost control is a judgement, and I will enumerate what is in tuning.go with current values and what 2x and 4x would mean for each, so you are picking from a list rather than trusting my read of "limits that were put in place for cost control".

One tension I am not going to quietly resolve. coilyco-bridge/deploy#431 says Deep's stated per-turn cost understates real spend by about 9x, and that the rate limits were set against the understated figure. If that holds, a 2x to 4x raise sits on top of a number already 9x optimistic. You may well have priced that in, since you say Deepseek is cheaper than you expected and you are the one seeing the bill. I am flagging it once so the raise is a decision rather than an accident, and then building what you asked for.

Also overlapping, and I will not double-land it: #367 is a decision about maxCompletionTokens specifically, the same 3600 this touches. I will build the mechanism so 367 becomes a one-line value change rather than another code change, and leave the number itself to that thread.

**CLAIM — Angie (ENG) · seat `claude-macos-…-ee99`. 20 minutes from this timestamp.** Reading the ask as two things, because the second is the one that makes the first safe: > But also, this needs to be configurable. If we do this the "easy way" it's probably just going to break local ornith **The easy way is one edit to `tuning.go`, and you are right that it breaks Echo.** Those constants are process-wide, and the two profiles are not alike: `sirens-echo/default` resolves to `ornith:35b` on the tower, `sirens-echo/deepseek` resolves upstream and never touches it. A 4x completion ceiling that is cheap on Deepseek is minutes of tower time per Echo turn. So configurability is not a nice-to-have here, it is the only way to raise anything without regressing the lane you did not mean to touch. So: make the cost knobs selectable per definition, defaults exactly what they are today, then raise Deep's. **What I will bring back rather than decide.** Which knobs count as cost control is a judgement, and I will enumerate what is in `tuning.go` with current values and what 2x and 4x would mean for each, so you are picking from a list rather than trusting my read of "limits that were put in place for cost control". **One tension I am not going to quietly resolve.** https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/431 says Deep's stated per-turn cost understates real spend by about 9x, and that the rate limits were set against the understated figure. If that holds, a 2x to 4x raise sits on top of a number already 9x optimistic. You may well have priced that in, since you say Deepseek is cheaper than you expected and you are the one seeing the bill. I am flagging it once so the raise is a decision rather than an accident, and then building what you asked for. **Also overlapping, and I will not double-land it:** https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/367 is a decision about `maxCompletionTokens` specifically, the same 3600 this touches. I will build the mechanism so 367 becomes a one-line value change rather than another code change, and leave the number itself to that thread.

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 14:57:16 +00:00

feat(tuning): a definition may name its own model-call ceilings, and Deep raises them #517

coilyco-ops commented

2026-08-13 14:57:42 +00:00

Member

Built. #517, ward exec gate green, carrying closes #467.

The enumeration I owed you

Every model-call number in tuning.go, what it is now, and what I shipped for Deep. Echo names no budget and is untouched, which is the whole point of doing it this way.

Knob	Default (Echo keeps)	Deep now	Multiple
`tool_rounds`	6	12	2x
`base_completion_tokens`	1800	3600	2x
`max_completion_tokens`	3600	14400	4x
`budget_raises`	1	2	see below
`tool_result_bytes`	8192	16384	2x

budget_raises is not a cost knob and I raised it anyway, so I want that on the record. The ladder doubles: 1800 to 3600 with one raise. Setting a 14400 ceiling with one raise gives a ladder that stops at 7200 and a ceiling that is decoration. Two raises make 3600 to 7200 to 14400 reachable. TestARaisedLadderReachesItsCeiling pins that, because a ceiling nothing can climb to is the kind of thing that reads fine and does nothing.

Deliberately not in the table: maxResponseRepairs, the MCP and fetch timeouts, the progress cadence, and the attachment and grounding caps. Those bound latency, correctness or Discord's own limits rather than spend. Say the word if you want any of them per-definition too and it is one field each now.

What I did not decide

The default ceiling. Still 3600. #367 is the thread that owns that number, and it is now a value change rather than a code change, so that decision costs a line.

The cost tension, restated once and then left with you. coilyco-bridge/deploy#431 reports per-turn cost understating real spend by about 9x, and that the rate limits were set against the understated figure. A 4x ceiling on top of that is the compounding case. You are the one seeing the bill and you said Deepseek is cheaper than you expected, so this is very likely priced in. Flagging it once so it is a decision, not an accident, and I am not holding the change on it.

A ceiling is not spend. Raising max_completion_tokens raises what a turn may use, not what it does. The change is bounded by turns that were previously hitting the cap, which per 367 was a 43% silent-failure rate, so most of the extra tokens buy answers that previously did not arrive.

What is verified

An unset budget resolves to the packaged defaults, field by field.
A ProxyClient built without one, which is every test and the evaluation runner, behaves as before.
Echo's shipped definition names no budget and resolves to today's ceiling.
Deep's raise sits inside your 2x to 4x, asserted as a ratio so a later edit outside that range fails rather than passing quietly.
A negative field and a ceiling below the floor are both refused at load.

Retuning

Edit model_budget in agent/sirens-deep.yaml. No Go change, no new field.

**Built. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/517, `ward exec gate` green, carrying `closes #467`.** ## The enumeration I owed you Every model-call number in `tuning.go`, what it is now, and what I shipped for Deep. **Echo names no budget and is untouched**, which is the whole point of doing it this way. | Knob | Default (Echo keeps) | Deep now | Multiple | | --- | --- | --- | --- | | `tool_rounds` | 6 | 12 | 2x | | `base_completion_tokens` | 1800 | 3600 | 2x | | `max_completion_tokens` | 3600 | 14400 | 4x | | `budget_raises` | 1 | 2 | see below | | `tool_result_bytes` | 8192 | 16384 | 2x | **`budget_raises` is not a cost knob and I raised it anyway, so I want that on the record.** The ladder doubles: 1800 to 3600 with one raise. Setting a 14400 ceiling with one raise gives a ladder that stops at 7200 and a ceiling that is decoration. Two raises make 3600 to 7200 to 14400 reachable. `TestARaisedLadderReachesItsCeiling` pins that, because a ceiling nothing can climb to is the kind of thing that reads fine and does nothing. **Deliberately not in the table:** `maxResponseRepairs`, the MCP and fetch timeouts, the progress cadence, and the attachment and grounding caps. Those bound latency, correctness or Discord's own limits rather than spend. Say the word if you want any of them per-definition too and it is one field each now. ## What I did not decide **The default ceiling.** Still 3600. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/367 is the thread that owns that number, and it is now a value change rather than a code change, so that decision costs a line. **The cost tension, restated once and then left with you.** https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/431 reports per-turn cost understating real spend by about 9x, and that the rate limits were set against the understated figure. A 4x ceiling on top of that is the compounding case. You are the one seeing the bill and you said Deepseek is cheaper than you expected, so this is very likely priced in. Flagging it once so it is a decision, not an accident, and I am not holding the change on it. **A ceiling is not spend.** Raising `max_completion_tokens` raises what a turn *may* use, not what it does. The change is bounded by turns that were previously hitting the cap, which per 367 was a 43% silent-failure rate, so most of the extra tokens buy answers that previously did not arrive. ## What is verified - An unset budget resolves to the packaged defaults, field by field. - A `ProxyClient` built without one, which is every test and the evaluation runner, behaves as before. - Echo's shipped definition names no budget and resolves to today's ceiling. - Deep's raise sits inside your 2x to 4x, asserted as a ratio so a later edit outside that range fails rather than passing quietly. - A negative field and a ceiling below the floor are both refused at load. ## Retuning Edit `model_budget` in `agent/sirens-deep.yaml`. No Go change, no new field.

coilyco-ops closed this issue

2026-08-13 14:59:12 +00:00

coilyco-ops referenced this issue from a commit

2026-08-13 14:59:13 +00:00

feat(tuning): a definition may name its own model-call ceilings, and Deep raises them

coilyco-ops referenced this issue

2026-08-13 14:59:56 +00:00

Decision: raise the completion ceiling above 3600, which costs ~10-22% more tokens and removes a 43% silent-failure rate #367

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 referenced this issue