Skip to content

bug(app): serviceTier priority is applied but absent from app source, UI and settings #160

Closed
Closed
bug(app): serviceTier priority is applied but absent from app source, UI and settings#160
Labels
bugSomething isn't working

Description

@devswha
devswha
opened on Sep 16, 2026

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.

Activity

  1. devswha
    added
    bugSomething isn't working
    on Sep 16, 2026
  2. devswha
    added a commit that references this issue on Sep 16, 2026

    fix(chat): report the service tier a run resolved to (#164)

    e79924e

  3. devswha commented on Sep 17, 2026

    @devswha
    devswha
    on Sep 17, 2026
    OwnerAuthor

    Status after #164 (2026-09-18):

    • Resolved and recorded — the session snapshot now carries serviceTier read 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.
    • Still open, and it is a product decision — whether the tier is user-selectable in Settings or documented as fixed with its cost. The app currently pins priority per run without a control. Either answer closes this; neither is a bug fix, so it waits for the owner.

  4. devswha commented on Sep 25, 2026

    @devswha
    devswha
    on Sep 25, 2026
    OwnerAuthor

    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 serviceTier setting (default none, which omits service_tier) or the per-session /fast on|off|status command, 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 on the next turn reported priority; after /fast off the tier was gone again. The priority recorded 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.

  5. devswha
    closed this as completedon Sep 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions