Feature Description
I've implemented a footer displaying information I think it's nice to have.
This is clearly an MVP for now and the features are:
- Standalone Package (internal/ui/footer):
• Isolates status bar layout and rendering state from internal/ui/model.go.
• Existing codebase remains untouched; AppModel delegates cleanly to footer.Render.
- Customizable Fields & Toggle:
• Supported fields: mode, model, context, bar, cache, cost, clock, timer.
• Users can enable/disable footer or pick specific field combinations.
- Slash Command (/footer):
• /footer: Display status and active fields.
• /footer on | /footer off: Enable/disable status bar.
• /footer toggle: Toggle visibility.
• /footer fields mode,model,cost: Customize field selection.
• /footer show / /footer hide : Enable/disable specific field.
• /footer reset: Restore default layout.
- Persistence:
• Settings persist in ~/.config/kit/preferences.yml (footer_enabled, footer_fields).
- Responsive Truncation:
• Retains 5-tier fallback cascade to guarantee single-line fit on small terminal windows.
The code has been generated by an agent and I applied the repo's Agents.md, so it's aligned with the PR requirements if this feature is seen useful for the broader audience.
Here's the output:
Checklist & Best Practices Applied
··································
- Clean Modular Architecture (internal/ui/footer):
• Isolates all footer logic in its own package without mutating existing UI state structures or spreading changes across existing files.
• Preserved internal/ui/model.go delegating to footer.Render.
- Persistence Compatibility (internal/ui/prefs/preferences.go):
• Uses atomic write (~/.config/kit/preferences.yml) so user settings persist cleanly across sessions without touching project-level config or comment-
formatting.
- Complete Code Quality Verification:
• Formattings & Linter: Ran go fmt ./... and go vet ./... clean.
• Race Conditions: Ran full test suite with -race (go test -race ./...) — 100% pass across all packages (internal/ui/footer, internal/ui, pkg/kit,
etc.).
• Clean Commit Boundaries: Single focused commit without clutter.
Here's two screenshots:
- Footer showing the information during a session
- Footer options in a new session
Motivation / Use Case
Kit prompt is located at the bottom, allowing some space between the text box and the terminal window border.
I thought this space could be used for a footer providing key information around the model used and pricing, when using a Frontier model as shown in the screenshot.
And for local models (i.e. Ollama), then the context can be really helpful. And the time used might allow to monitor exactly how much time it takes for the model to provide the output.
Proposed Implementation
My implementation is in `https://github.com/nunix/kit/tree/feat/modular-footer ` and to have a better idea, here's the features and which files are impacted:
Dependencies Breakdown by Field
·······························
1. context & bar (Context Tokens & Progress Bar)
• Data source: ut.contextTokens and modelInfo.Limit.Context.
• Dependency: Uses existing UsageTracker.SetContextTokens() and model definitions from internal/models.
• New methods: Requires lightweight thread-safe getters (GetContextTokens(), GetContextLimit()) added to UsageTracker.
2. cache (Prompt Cache Stats)
• Data source: ut.sessionStats.TotalCacheReadTokens and TotalInputTokens.
• Dependency: Uses token counts already captured by UsageTracker.UpdateUsage().
• New methods: Requires GetCacheStats() getter on UsageTracker.
3. cost (Session & Turn Cost Breakdown)
• Data source: ut.sessionStats.TotalCost and ut.lastRequest.TotalCost.
• Dependency: Calculated from standard ModelInfo.Cost pricing.
• New methods: Requires GetCostBreakdown() and IsOAuth() getters on UsageTracker.
4. timer (Turn / Session Duration)
• Data source: turnStartTime, lastTurnDuration, totalTurnDuration.
• Dependency: Tracked natively inside AppModel.Update() state machine on stateWorking / stateInput transitions.
5. mode (Mode Tag)
• Data source: RenderData.ModeTag.
• Dependency: Defaults to [CAVEMAN]; can default to "" or [KIT] upstream when no custom persona/mode is active.
6. model & clock (Model Name & Local Time)
• Data source: Native m.modelName / m.providerName and standard library time.Now().
*Files*
All methods are 100% self-contained in this branch. No external branch, PR, or dependency is needed.
Included in feat/modular-footer Branch:
·······································
1. internal/ui/footer/ (new modular package with config.go, render.go, footer_test.go).
2. internal/ui/usage_tracker.go: thread-safe getters (GetContextTokens, GetContextLimit, GetCacheStats, GetCostBreakdown, IsOAuth).
3. internal/ui/model.go: turn-timer hooks & rendering delegation.
4. internal/ui/commands/commands.go: /footer slash command registration & tab-completion.
5. internal/ui/prefs/preferences.go: persistence for footer settings.
6. internal/ui/footer_render_test.go: unit tests.
Alternatives Considered
Checklist
Feature Description
I've implemented a footer displaying information I think it's nice to have.
This is clearly an MVP for now and the features are:
• Isolates status bar layout and rendering state from internal/ui/model.go.
• Existing codebase remains untouched; AppModel delegates cleanly to footer.Render.
• Supported fields: mode, model, context, bar, cache, cost, clock, timer.
• Users can enable/disable footer or pick specific field combinations.
• /footer: Display status and active fields.
• /footer on | /footer off: Enable/disable status bar.
• /footer toggle: Toggle visibility.
• /footer fields mode,model,cost: Customize field selection.
• /footer show / /footer hide : Enable/disable specific field.
• /footer reset: Restore default layout.
• Settings persist in ~/.config/kit/preferences.yml (footer_enabled, footer_fields).
• Retains 5-tier fallback cascade to guarantee single-line fit on small terminal windows.
The code has been generated by an agent and I applied the repo's
Agents.md, so it's aligned with the PR requirements if this feature is seen useful for the broader audience.Here's the output:
Checklist & Best Practices Applied
··································
• Isolates all footer logic in its own package without mutating existing UI state structures or spreading changes across existing files.
• Preserved internal/ui/model.go delegating to footer.Render.
• Uses atomic write (~/.config/kit/preferences.yml) so user settings persist cleanly across sessions without touching project-level config or comment-
formatting.
• Formattings & Linter: Ran go fmt ./... and go vet ./... clean.
• Race Conditions: Ran full test suite with -race (go test -race ./...) — 100% pass across all packages (internal/ui/footer, internal/ui, pkg/kit,
etc.).
• Clean Commit Boundaries: Single focused commit without clutter.
Here's two screenshots:
Motivation / Use Case
Kit prompt is located at the bottom, allowing some space between the text box and the terminal window border.
I thought this space could be used for a footer providing key information around the model used and pricing, when using a Frontier model as shown in the screenshot.
And for local models (i.e. Ollama), then the context can be really helpful. And the time used might allow to monitor exactly how much time it takes for the model to provide the output.
Proposed Implementation
Alternatives Considered
Checklist