DEV Community: Nicholas Drone

[Boost]

Nicholas Drone — Tue, 23 Jun 2026 13:21:05 +0000

Nicholas Drone

Jun 23

Building a Custom Status Line for Claude Code

#ai #productivity #tutorial #claude

5 min read

Building a Custom Status Line for Claude Code

Nicholas Drone — Tue, 23 Jun 2026 13:20:37 +0000

I spend most of my day in Claude Code. It's my pair programmer, code reviewer, and rubber duck all rolled into one. After a few days of using it, I realized I had no idea how many tokens I'd burned, how much the session was costing, or how close I was to filling the context window.

Every once in a while I'd run /cost, think "that's higher than I expected," and go back to work.

That lasted about a day.

I like dashboards. If I'm consuming resources or spending money, I want to see it happening in real time. I don't want another command I have to remember to run. I want to glance at the bottom of my terminal and immediately know what's going on.

So I built a custom status line.

Why

There were three things I wanted to see.

Cost

Claude Opus isn't free, and long sessions can get surprisingly expensive. Having a running total visible all the time changes how I work. It's the difference between checking your bank account once a month and having your balance on your phone's home screen.

When I see:

session:$1.47

I immediately know whether I'm still in "keep going" territory or whether it's time to wrap up the current task and start fresh.

Context

Claude Code automatically compacts conversations when you get close to the context limit, but I'd rather make that decision myself.

Watching:

ctx:81% left

slowly become

ctx:32% left

during a long refactor tells me it's probably time to commit what I have and open a new session before I lose momentum.

Note: The context percentage reported by the status line is the raw value Claude Code provides. In my experience, Claude will start warning that the context window is getting low when the status line still shows roughly 28% remaining. The warning itself says about 14% is left. My guess is Claude is intentionally conservative and reserves part of the context window for compaction and generating responses, so it alerts you well before you actually hit the limit. I haven't found official documentation confirming this behavior, but it's been consistent enough that I plan around the status line value rather than waiting for the warning.

Orientation

I'm constantly jumping between repositories and branches.

At a glance I want to know:

What project am I in?
What branch am I on?
Which model am I using?
How long has this session been running?

It's the same reason every shell prompt shows the current git branch. Reducing context switching is free productivity.

How It Works

The status line API is almost disappointingly simple.

You point Claude Code at a shell script. Every few seconds it pipes a JSON document to the script's stdin, and whatever the script prints becomes the status line.

That's it.

No SDK.

No framework.

No API.

Just stdin and stdout.

Even better, it costs nothing. Everything runs locally. Claude Code sends your script session information over local IPC, your script formats it, and the result gets rendered in the terminal. Refresh it every second for an entire workday if you want—it won't consume a single token.

Here's the JSON I'm interested in (trimmed down a bit):

{
  "cwd": "/Users/nsdrone/gitrepos/my-project",
  "model": {
    "id": "claude-opus-4-6",
    "display_name": "Opus"
  },
  "cost": {
    "total_cost_usd": 1.47,
    "total_duration_ms": 342000
  },
  "context_window": {
    "remaining_percentage": 81.8,
    "current_usage": {
      "input_tokens": 89400,
      "output_tokens": 12300,
      "cache_read_input_tokens": 64200
    }
  }
}

My script parses the JSON with a single jq call, formats everything, and prints:

~/gitrepos/my-project (main) »    Opus | 5m | in:89.4k out:12.3k cache:64.2k | ctx:81% left | session:$1.47

That's everything I care about and nothing I don't.

Step 1: Create the Script

Create ~/.claude/statusline.sh:

#!/bin/bash
# Claude Code status line — renders session info at the bottom of the terminal.
# Claude Code pipes session JSON to stdin every refreshInterval seconds;
# whatever this script prints to stdout becomes the status bar.

INPUT=$(cat)

# Single jq call extracts all fields at once. @sh produces shell-safe quoted
# strings so eval can assign them without word-splitting issues.
eval "$(echo "$INPUT" | jq -r '
  @sh "CWD=\(.cwd // empty)",
  @sh "GIT_BRANCH=\(.git.branch // empty)",
  @sh "MODEL=\(.model.display_name // .model // empty)",
  @sh "INPUT_TOKENS=\(.context_window.current_usage.input_tokens // 0)",
  @sh "OUTPUT_TOKENS=\(.context_window.current_usage.output_tokens // 0)",
  @sh "CACHE_READ=\(.context_window.current_usage.cache_read_input_tokens // 0)",
  @sh "COST_USD=\(.cost.total_cost_usd // 0)",
  @sh "CTX_REMAINING=\(.context_window.remaining_percentage // 100)",
  @sh "DURATION_MS=\(.cost.total_duration_ms // 0)"
')"

# Collapse /Users/whoever to ~ for a shorter path
CWD="${CWD/#$HOME/~}"

# 1234 → "1.2k", 1234567 → "1.2M", 500 → "500"
format_tokens() {
  local n=$1
  if [ "$n" -ge 1000000 ]; then
    printf "%s.%sM" "$((n / 1000000))" "$((n % 1000000 / 100000))"
  elif [ "$n" -ge 1000 ]; then
    printf "%s.%sk" "$((n / 1000))" "$((n % 1000 / 100))"
  else
    echo "$n"
  fi
}

# Under an hour: "12m". Over an hour: "1h23m".
format_duration() {
  local ms=$1
  local total_sec=$((ms / 1000))
  local min=$((total_sec / 60))
  local hrs=$((min / 60))
  local remaining_min=$((min % 60))
  if [ "$hrs" -ge 1 ]; then
    printf "%dh%dm" "$hrs" "$remaining_min"
  else
    printf "%dm" "$min"
  fi
}

IN=$(format_tokens "$INPUT_TOKENS")
OUT=$(format_tokens "$OUTPUT_TOKENS")
CACHE=$(format_tokens "$CACHE_READ")
COST=$(printf "\$%.2f" "$COST_USD")
DUR=$(format_duration "$DURATION_MS")

# Left side: working directory and branch
LEFT="$CWD"
if [ -n "$GIT_BRANCH" ]; then
  LEFT="$LEFT ($GIT_BRANCH)"
fi
LEFT="$LEFT »"

# Right side: model, duration, tokens, context remaining, cost
RIGHT="$MODEL | $DUR | in:$IN out:$OUT cache:$CACHE | ctx:${CTX_REMAINING}% left | session:$COST"

printf '%s    %s' "$LEFT" "$RIGHT"

Step 2: Make It Executable

chmod +x ~/.claude/statusline.sh

Step 3: Wire It Up

Add this to ~/.claude/settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "refreshInterval": 1
  }
}

The refresh interval is measured in seconds. I use 1 because I like seeing everything update in real time. If that's overkill, bump it to 5.

Step 4: Test It

You don't have to launch Claude Code to verify the script.

echo '{"cwd":"/Users/you/project","git":{"branch":"main"},"model":{"display_name":"Opus"},"context_window":{"current_usage":{"input_tokens":45000,"output_tokens":8000,"cache_read_input_tokens":32000},"remaining_percentage":78},"cost":{"total_cost_usd":0.83,"total_duration_ms":420000}}' | ~/.claude/statusline.sh

Expected output:

~/project (main) »    Opus | 7m | in:45.0k out:8.0k cache:32.0k | ctx:78% left | session:$0.83

Step 5: Restart Claude Code

Start a new session and your status line will be waiting at the bottom of the terminal.

Make It Yours

The best part is that it's just a shell script.

A few ideas:

Add ANSI colors when context gets low.
Show +256/-43 lines changed.
Build a multi-line status bar.
Add git dirty state.
Add a progress bar.
Whatever else you can do in bash.

If you don't want to write any of this yourself, Claude Code already has a shortcut:

/statusline show me model, branch, token counts, context percentage, and cost

It will generate and wire up a status line for you.

Final Thoughts

This was the first thing I customized in Claude Code, and it completely changed how I use it.

Once you realize that status lines, hooks, and other extension points are just shell scripts receiving structured JSON, the whole system starts to click. You stop thinking about "features" and start thinking about automation.

And that's where the fun begins.

Automated Service Principal Password Rotation

Nicholas Drone — Thu, 04 Nov 2021 19:53:26 +0000

Assumptions

Knowledge of Terraform
Knowledge of using Terraform with Azure
Knowledge of GitHub Actions
Knowledge of Bash Scripting

Setup

This code block holds all the Azure resources built out by Terraform. The resource group and key vault are not required. It's only to show the storage of the service principal password and to show that when a terraform apply -replace is done that whatever is consuming the output of that resource is also updated. After the resource group and key vault are two service principals examples for this example.

terraform {
  backend "azurerm" {
    subscription_id      = "xxx-xxx-xxx-xxx"
    resource_group_name  = "tfstate"
    storage_account_name = "dronetfstate"
    container_name       = "tfstate"
    key                  = "sp_rotate.tfstate"
  }
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "2.83.0"
    }
    azuread = {
      source  = "hashicorp/azuread"
      version = "2.8.0"
    }
  }
}

provider "azurerm" {
  features {}
}

provider "azuread" {
}

resource "azurerm_resource_group" "example" {
  name     = "example"
  location = "Eastus2"
}

data "azurerm_client_config" "current" {}

resource "azurerm_key_vault" "example" {
  name                        = "droneexamplekeyvault"
  location                    = azurerm_resource_group.example.location
  resource_group_name         = azurerm_resource_group.example.name
  enabled_for_disk_encryption = true
  tenant_id                   = data.azurerm_client_config.current.tenant_id
  soft_delete_retention_days  = 7
  purge_protection_enabled    = false

  sku_name = "standard"

  access_policy {
    tenant_id = data.azurerm_client_config.current.tenant_id
    object_id = data.azurerm_client_config.current.object_id

    secret_permissions = [
      "Get",
      "List",
      "Set"
    ]
  }
}

data "azuread_client_config" "current" {}

resource "azuread_application" "example1" {
  display_name = "example1"
  owners       = [data.azuread_client_config.current.object_id]
}

resource "azuread_service_principal" "example1" {
  application_id               = azuread_application.example1.application_id
  app_role_assignment_required = false
  owners                       = [data.azuread_client_config.current.object_id]
}

resource "azuread_service_principal_password" "example1" {
  service_principal_id = azuread_service_principal.example1.object_id
}

resource "azurerm_key_vault_secret" "example1" {
  name         = "example1"
  value        = azuread_service_principal_password.example1.value
  key_vault_id = azurerm_key_vault.example.id
}

resource "azuread_application" "example2" {
  display_name = "example2"
  owners       = [data.azuread_client_config.current.object_id]
}

resource "azuread_service_principal" "example2" {
  application_id               = azuread_application.example2.application_id
  app_role_assignment_required = false
  owners                       = [data.azuread_client_config.current.object_id]
}

resource "azuread_service_principal_password" "example2" {
  service_principal_id = azuread_service_principal.example2.object_id
}

resource "azurerm_key_vault_secret" "example2" {
  name         = "example2"
  value        = azuread_service_principal_password.example2.value
  key_vault_id = azurerm_key_vault.example.id
}

When having service principals created its good security practice to rotate those passwords on a regular basis. If you are using GitHub Actions to already apply/execute your resource changes, then adding a workflow to then rotate the password by doing forcing a replacement of the password resource causes a new password to be generated.

Rotation Workflow

name: Rotate Secrets

on:
  schedule:
    - cron: '0 1 1 12/3 *' # run every 4 months.
  workflow_dispatch:

env:
  ARM_SUBSCRIPTION_ID: ${{ secrets.ARM_SUBSCRIPTION_ID }}
  ARM_CLIENT_ID: ${{ secrets.ARM_CLIENT_ID }}
  ARM_CLIENT_SECRET: ${{ secrets.ARM_CLIENT_SECRET }}
  ARM_TENANT_ID: ${{ secrets.ARM_TENANT_ID }}
  TF_IN_AUTOMATION: true

jobs:
  replace:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 1.0.8
      - name: Terraform Init
        run: terraform init -input=false -no-color
        # Pull all the resources from the state file put them in a file for the next step
      - name: Terraform List State Resources
        run: terraform state list > stateList
        # We are going to loop through each line in the file of the resources
        # We only want to replace the service_principal_password resource, so we
        # need to check the start of each resource starts with the correct address.
      - name: Terraform Replace
        run: while read target; do if [[ "${target:0:34}" == "azuread_service_principal_password" ]]; then terraform apply -replace="$target" -input=false -no-color -auto-approve; fi; done < stateList

The last two steps are where the work is really done. First we want to create a temporary file to store all the resources within the state file. Echoing out the created file

data.azuread_client_config.current
data.azurerm_client_config.current
azuread_application.example1
azuread_application.example2
azuread_service_principal.example1
azuread_service_principal.example2
azuread_service_principal_password.example1
azuread_service_principal_password.example2
azurerm_key_vault.example
azurerm_key_vault_secret.example1
azurerm_key_vault_secret.example2
azurerm_resource_group.example

Then the following step we are iterating over all those resources and looking for the ones with the block label of azuread_service_principal_password. When we find those block labels we then want to pass the entire address to Terraform to force a replacement of those resources.

while read target; do 
    if [[ "${target:0:34}" == "azuread_service_principal_password" ]]; then 
        terraform apply -replace="$target" -input=false -no-color -auto-approve
    fi
done < stateList

Repositories are not just for Databases

Nicholas Drone — Thu, 14 Nov 2019 23:01:32 +0000

This blog post came out of the necessity of my own mistake. I have been working strictly with databases longer than I care to admit to. So in a project, we were making changes so that a specific application didn't have direct database access to a different application. Simple separation of concerns right, and microservice architecture. All that jazz right? So I brought in an HttpClient into the service layer, removing the repository. It seemed right at the time. Not sure why, several weeks later this pattern was copied by may other developers on the project, and just turn that project to no longer a clean looking platform of microservices. Then one day it hit me. The HTTP crud operations were doing the same thing as the database operations. And both should be treated as a datastore. Whether the data lives in a file of any structure, HTTP request, and or database. The access to that data should all live in the repository layer.

The code in this blog can be seen here. The git repository as of writing this post contains a library module with several sub-modules. The idea is that the libraries are then used by the applications that have yet to be written to further explain why repositories are for datastores not just databases.

Let's ignore the contact-core-test module for now. It contains a base test class. Each ContactRepository implementation test class can extend the base test class, and then only needs to write tests based on their implementation, but should pass all tests in the base class. I may turn that into a blog post of its own.

The contact-core module. This is a small simple module that contains the contact object. The repository interface for the contact object. The exception class for that object, and the validator class. The validator class just validates that the inputs specified in the methods of the interface adhere to the specifications of the javadocs of the interface.

package org.example;

/**
 * A simple ContactRepository. Any implementation of this interface should
 * leverage {@link ContactRepositoryValidator} to validate the overriding methods
 * arguments. The implementations Tests classes should extend ContactRepositoryTests
 *
 * @see contact-core-test module
 */
public interface ContactRepository {

  /**
   * Search for the contact with the existing <code>id</code>
   *
   * @param id of the contact to be searched for
   * @return <code>contact</code> maybe <code>null</code> if <code>contact</code>
   * with the <code>id</code> doesn't exist
   * @throws IllegalArgumentException if <code>id</code> is <code>null</code>
   * @throws ContactException         if an error has occurred
   */
  Contact findContact(Integer id) throws IllegalArgumentException, ContactException;

  /**
   * Searching for <code>contact</code> that exactly matches the parameters
   * passed into the method.
   *
   * @param firstName to be exactly searched with
   * @param lastName  to be exactly searched with
   * @return a collection of <code>contact</code> that match the parameters
   * @throws IllegalArgumentException if both parameters are <code>null</code>
   * @throws ContactException         if an error has occurred
   */
  Iterable<Contact> findContacts(String firstName, String lastName)
      throws IllegalArgumentException, ContactException;

  /**
   * Saves a new or updated contact information. If a <code>contact</code> is passed with the
   * <code>id</code> is <code>null</code>. The contact will be treated as a new contact, and
   * an <code>id</code> will be generated for it. If an <code>contact</code> has an existing
   * <code>id</code> the <code>contact</code> with be updated.
   *
   * @param contact to be saved or updated
   * @return saved <code>contact</code>
   * @throws IllegalArgumentException if a <code>contact</code> with an existing <code>id</code>
   *                                  can not be found.
   * @throws ContactException         if an error has occurred
   */
  Contact saveContact(Contact contact) throws IllegalArgumentException, ContactException;
}

The contact-file, contact-http, and contact-jdbc are all modules that implement the ContactRepository. So an application then can bring in the specific technology implementation and build an application based on the interface.

A hypothetical scenario

As a product team, we are spinning up a contact service. We've requested a database, but that won't be ready for weeks, and the boss wants it done by next week. Well, we still can write that service. The rest application is written to the ContactRepository interface. We bring in the contact-file dependency for the short term while we are waiting on our database to be complete. Once the database is complete we then can swap out the contact-file dependency for the jdbc one, only changing enough code to connect to the database. Then file contents are moved to the database after deployment. The boss shows off your work to another team that wants access to the contact info. Except they can't get past the firewall use the contact-jdbc implementation. Not that you wanted them to. So you create the HTTP implementation to your applications URL endpoints. Then they just need to write code to the interface you just did, but leverage HTTP to get the same data you got from the JDBC implementation. The good news is if your API change, you can control the HTTP implementation too, so you can save your customer the headache of handling the versioning, just give them the new HTTP jar with the versioned changes in it.