Skip to content

feat: Feature Proposal: Modular & Configurable Status Bar Footer (/footer) #95

Description

@nunix

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:

  1. 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.
  2. Customizable Fields & Toggle:
    • Supported fields: mode, model, context, bar, cache, cost, clock, timer.
    • Users can enable/disable footer or pick specific field combinations.
  3. 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.
  4. Persistence:
    • Settings persist in ~/.config/kit/preferences.yml (footer_enabled, footer_fields).
  5. 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
··································

  1. 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.
  2. 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.
  3. 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:

  1. Footer showing the information during a session
Image
  1. Footer options in a new session
Image

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

  • I've considered workarounds or alternative approaches

Checklist

  • I've searched existing issues and this hasn't been requested yet
  • This feature aligns with Kit's design philosophy (TUI-first, extension-based)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions