Repository navigation
bug(app): serviceTier priority is applied but absent from app source, UI and settings #160
Description
Every app run is pinned to an explicit model chain, thinkingLevel: xhigh and serviceTier: priority. The effort pin is at least derived from app config; serviceTier does not appear anywhere in the app's source, so the app can neither display it, change it, nor audit it.
Evidence
Session-initialization records differ between an app session and a CLI session on the same machine, same repo, same model, same SDK build:
APP CLI
configured_model_chain 1 -
service_tier_change 1 -
model_change 2 1
thinking_level_change 1 1
Values:
APP thinking_level_change → "xhigh"
CLI thinking_level_change → "inherit"
APP service_tier_change → "priority"
CLI (no record)
APP configured_model_chain → entries:["anthropic/claude-opus-5"]
origin:"startup-override" explicitHead:true cleared:false
CLI (no record)
The model/effort pin is app code, server/gjc-bun-sdk-adapter.ts:1286-1300:
const thinkingLevel = config.effort && config.effort !== 'default' && config.effort !== 'inherit'
? config.effort : undefined;
await result.session.setModelTemporary(model, thinkingLevel, {
persistAsSessionDefault: true,
cause: 'startup-override',
});
result.session.setConfiguredModelChain('default', [`${model.provider}/${model.id}`], 'startup-override', undefined, true);serviceTier is not:
$ grep -rniE 'serviceTier|service_tier|\btier\b' server/ shared/ src/
(no functional match — only an unrelated model id "gemini-3.8-flash-tiered" in a test fixture
and i18n strings that merely contain the letters)
Not a config source either:
~/.gjc/agent/settings.json → does not exist
agent.db settings table → 0 rows
SDK version app payload → @gajae-code/coding-agent 0.16.4
SDK version repo node_modules → @gajae-code/coding-agent 0.16.4 (identical)
So the app runs on a priority service tier that its own codebase never names.
Why this is a problem
The pinned combination is the expensive one, and it is applied to autonomous runs:
681 turns, one user prompt, xhigh + priority → $140.95
A user cannot see in the app which tier their run bills at, cannot turn it off, and cannot correlate a bill with a setting. Settings exposes no tier control because the concept does not exist in the app's code.
This is distinct from the cache-read cost issue: even with compaction, the tier multiplier stays invisible.
Expected
- The app resolves
serviceTierexplicitly rather than inheriting whatever the runtime/credential selects, and records the resolved value. - Resolved model, effort and tier are visible per session in the UI.
- Tier is user-controllable, or the app documents why it is fixed and what it costs.
Activity
fix(chat): report the service tier a run resolved to (#164)
devswha commentedon Sep 17, 2026
Status after #164 (2026-09-18):
serviceTierread from the runtime's public getter, and the Agent sidebar's Environment block renders it beside model and effort (ten locales). An absent tier renders nothing rather than a claimed one.priorityper run without a control. Either answer closes this; neither is a bug fix, so it waits for the owner.devswha commentedon Sep 25, 2026
Closing with the documented answer, landed in #177 (
server/GJC-LIVE-SPEC.md).The service tier is the runtime's, exactly as in the CLI. It comes from the user's
serviceTiersetting (defaultnone, which omitsservice_tier) or the per-session/fast on|off|statuscommand, which the app's slash menu already carries. The app pins no tier and overrides none. The resolved tier shows in the Agent sidebar (#164) only when one is set.Checked live on SDK 0.17.6 through the app: a new session reported no tier; after
/fast onthe next turn reportedpriority; after/fast offthe tier was gone again. Thepriorityrecorded in the original report was that session's fast-mode state, not app code. On 0.17.6 an app session starts without it.A dedicated Settings control remains a possible product addition, but it is no longer a bug: the tier is visible, user-controllable and documented.