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
serviceTier explicitly 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.
Every app run is pinned to an explicit model chain,
thinkingLevel: xhighandserviceTier: priority. The effort pin is at least derived from app config;serviceTierdoes 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:
Values:
The model/effort pin is app code,
server/gjc-bun-sdk-adapter.ts:1286-1300:serviceTieris not:Not a config source either:
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:
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.
Settingsexposes 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
serviceTierexplicitly rather than inheriting whatever the runtime/credential selects, and records the resolved value.