DEV Community: Ted Kupolov

Lightweight Spring Boot Monitoring Without Prometheus and Grafana

Ted Kupolov — Tue, 21 Jul 2026 15:10:00 +0000

Running one Spring Boot application, or a handful of them, on a VPS still requires basic visibility.

You need to know:

Is the application healthy?
Are errors increasing?
Are requests slowing down?
Is memory usage growing?
Did the application restart?

You may not need a complete monitoring platform to answer those questions.

Spring Boot Actuator already exposes much of the necessary information. StatLite turns it into a focused dashboard for health, HTTP activity, latency, memory, uptime, and restarts.

It runs as a single Go binary and stores its history in SQLite.

View StatLite on GitHub · Installation instructions

Why not just use Actuator directly?

Actuator exposes useful health and Micrometer metrics endpoints, but repeatedly opening JSON responses is not a convenient monitoring workflow.

Prometheus and Grafana are excellent when you need:

Many services or hosts
Flexible metric queries
Long retention
Alert routing
Shared organizational dashboards

Spring Boot Admin provides broader application administration and monitoring features.

For a few services on one VPS, however, a smaller dashboard may be enough. StatLite reads the Actuator endpoints you already have and presents the operational signals needed for routine checks.

Quick comparison

Tool	Complexity	Best fit
Raw Actuator endpoints	Low	Occasional manual checks
Spring Boot Admin	Medium	Application administration
Prometheus and Grafana	High	Larger observability deployments
StatLite	Very low	A few Spring Boot services on a VPS

These approaches can coexist. Starting with StatLite does not prevent moving to Prometheus and Grafana later.

Set up StatLite

The following example uses the runnable Spring Actuator demo included in the StatLite repository.

1. Expose Actuator health and metrics

Add the required endpoint exposure to your Spring Boot configuration:

management:
  endpoints:
    web:
      exposure:
        include: health,metrics
  endpoint:
    health:
      show-details: always

Keep Actuator restricted to trusted networks and add authentication when required.

Start the demo application:

cd examples/spring-actuator-demo
mvn spring-boot:run

Confirm that its endpoints respond:

curl -s http://127.0.0.1:8080/actuator/health
curl -s http://127.0.0.1:8080/actuator/metrics

2. Install StatLite

The installation guide covers the release installer and Homebrew.

You can also build it from source:

git clone https://github.com/pvrlabs/statlite.git
cd statlite
go build -o statlite ./cmd/statlite

3. Configure a target

Create statlite.yaml beside the binary:

server:
  listen: "127.0.0.1:9090"

storage:
  sqlite_path: "./statlite.sqlite"

polling:
  interval: "10s"
  timeout: "5s"

targets:
  - name: "spring-demo"
    actuator_base_url: "http://127.0.0.1:8080/actuator"

This configuration:

Keeps the dashboard bound to localhost
Stores history in statlite.sqlite
Polls the application every ten seconds
Reads metrics from the application’s Actuator base URL

For Basic Auth, multiple applications, retention, and production security, see the configuration documentation.

The demo leaves Actuator unauthenticated because it binds to loopback for local testing. Do not expose the same configuration publicly without appropriate network and authentication controls.

4. Open the dashboard

Start StatLite:

./statlite --config ./statlite.yaml

Then open:

http://127.0.0.1:9090

The demo includes a traffic generator for populating the request, latency, and error charts:

./examples/spring-actuator-demo/generate-traffic.sh

It generates successful, slow, database, 400, 404, and 500 responses. StatLite updates after the next configured polling interval.

Why StatLite stays small

StatLite intentionally uses a narrow architecture:

One Go binary
SQLite storage
No monitoring agent
No custom instrumentation beyond Actuator
Multiple Spring Boot targets in one configuration
Straightforward systemd deployment

It is Actuator-first: your application exposes Actuator, and StatLite provides a focused view over that data.

When StatLite is not enough

Use a broader observability platform when you need distributed tracing, centralized logs, advanced queries, alert routing, long-term retention, or dashboards spanning a large number of systems.

StatLite is not intended to replace enterprise observability. It is for the smaller operational job: monitoring a few Spring Boot services without running a full Prometheus and Grafana stack.

To try it, visit the StatLite repository and follow the installation instructions.

Can AI Badger Reduce Local Coding Agent Token Usage?

Ted Kupolov — Fri, 10 Jul 2026 22:10:16 +0000

In this single dogfooding experiment, using a compact handoff produced by AI Badger's /design mode plus an external compression step reduced OpenCode's active tokens by 32.1%, reasoning tokens by 85.6%, and runtime by 54.5% compared with sending the feature prompt directly.

Including cache reads, total token movement dropped by 63.2%.

Important caveat: this is directional evidence from one run per workflow. The implementations differed, and external-chat compression cost is not included.

What this experiment measures

AI Badger's /design mode performed a local heuristic scan of the project; it made no LLM call. An external AI chat then compressed that context into a terse implementation handoff, which was passed to OpenCode.

The measurements below cover only the OpenCode execution sessions. They do not include the external compression step. There was one run per workflow, and /plan is a possible future direction rather than an existing Badger feature.

The test app

The fixture is a small note-taking app built with no framework, no build system, and no dependencies.

I updated the underlying app so it better reflects the original requirements before running the comparison.

It has the usual local-app pieces: note creation, editing, deletion, search, tag filtering, sort order, settings persistence, and localStorage persistence. That makes it small enough to inspect but still rich enough to expose context-selection and handoff quality.

Both workflows produced working implementations of the requested settings feature and retained the core create, edit, delete, search, and filtering flows in manual review. The outputs differed in UI details and internal organization, and both had minor issues identified afterward. This experiment therefore compares execution efficiency, not equivalent final-code quality.

The screenshot is left unedited. The raw fixture snapshots remain the reproducible source of truth.

The feature

Both workflows were asked to add the same settings panel:

Add a settings panel to this existing note-taking app.

Requirements:
- Add theme setting: light, dark, or system.
- Add sort order setting: newest updated, oldest updated, title A-Z.
- Persist settings in localStorage.
- Apply settings on page load.
- Preserve existing note create/edit/delete/search behavior.
- Keep the app plain HTML/CSS/JS with no dependencies.

The original app requirements were broader, but the feature under test was intentionally narrow: add settings without disturbing the existing note workflow.

Two workflows

Workflow A is direct OpenCode prompting with no Badger AI in the loop. Workflow B uses Badger Design plus a compact handoff.

Workflow A: direct OpenCode prompt

OpenCode received the feature prompt directly.

Workflow A: Direct OpenCode

Session:

ses_0b324acf7ffeKNd3hIFbTD9d5v

Captured session data:

input:              38,995
output:              8,359
reasoning:           9,151
cache_read:      1,137,664
cache_write:             0
active_total:       56,505
cache_total:     1,137,664
total_with_cache: 1,194,169
duration_ms:       207,401

Workflow B: Badger Design + compact handoff + OpenCode

This workflow used Badger's existing /design output first, then an external AI chat step compressed that context into a terse local-agent handoff, which was then pasted into OpenCode.

The compression prompt was:

Design the complete implementation, then produce a compact local-agent implementation plan with concrete changes only. Omit rationale, risks, open questions, acceptance criteria, and broad testing notes. Optimize the output for low token usage.

Workflow B: Badger Design + compact handoff

Session:

ses_0b30e208bffeJjWAhWtoHY7IEX

Captured session data:

input:              30,143
output:              6,896
reasoning:           1,317
cache_read:        401,664
cache_write:             0
active_total:       38,356
cache_total:       401,664
total_with_cache:  440,020
duration_ms:        94,394

Measurement approach

I compared the exported session data for the two OpenCode runs. That keeps the comparison tied to the exact local-agent sessions used in the experiment.

Active-token usage provides the cleaner primary comparison because cache-read accounting and pricing vary across models and providers. The comparison below measures only OpenCode execution. The Badger /design step is local and free of LLM cost. The external compression step is separate and typically much cheaper than local-agent reasoning tokens.

Session-level results

Summary: 32.1% fewer active tokens, 85.6% fewer reasoning tokens, 54.5% faster, and 63.2% less total token movement.

Metric	Direct OpenCode	Badger Design + Handoff -> OpenCode	Change
Active total	56,505	38,356	-32.1%
Reasoning	9,151	1,317	-85.6%
Duration	207.4s	94.4s	-54.5%
Total with cache	1,194,169	440,020	-63.2%
Input	38,995	30,143	-22.7%
Output	8,359	6,896	-17.5%
Cache read	1,137,664	401,664	-64.7%

Chart 1: total token movement

Chart 2: active token breakdown

Chart 3: cache read comparison

Chart 4: duration comparison

The headline result in this experiment is simple: the Badger Design + compact handoff workflow reduced OpenCode token movement by about 63% and runtime by about 55%.

On this run, Workflow B was the more token-efficient path.

Reasoning tokens dropped by about 86%, which is consistent with reduced agent-side exploration.

What changed

The useful artifact was not a verbose implementation spec.

The useful artifact was a compact local-agent handoff:

concrete file/function changes only
no rationale
no risks
no open questions
no acceptance criteria
no broad testing notes

That is the shape I want a future Badger focus mode to automate.

Why this is not the same as "chat writes the whole app"

For a tiny app, AI chat can sometimes generate the entire implementation without using a local coding agent at all, which is not the comparison here. That workflow can work well for small changes, but it does not scale cleanly to larger repositories. The more scalable path is the one used here: Badger exposes the relevant project context, external chat compresses it, and the local coding agent still performs the edit inside the repo.

Product implication: automating the compact handoff

This experiment used Badger's existing /design workflow, not a dedicated plan mode.

That suggests a future Badger focus:

/design  -> local topology/context summary for design discussion
/review  -> inspect code or changes
/plan    -> produce compact implementation handoff for a local coding agent

/plan is one possible name for a future mode that could automate this compact handoff. This article is a product-direction signal, not a claim that the feature already exists.

A future /plan mode could automate the compression step. But I do not want to rush it. The manual workflow has a safety valve: I can inspect the topology summary before asking for a compact handoff. An automated /plan mode would need enough confidence that the right context was found before handing instructions to a local agent.

The experiment therefore points to a sequence:

Ship the article.
Gather feedback.
See whether people want this workflow.
Improve confidence in Badger's design/topology scan.
Then consider implementing /plan.

Caveats

One app.
One feature.
One model.
One local agent.
No repeated runs yet.
summary.files reported 0 in both exported sessions, so file-derived token metrics were ignored.
Results may differ for trivial changes, very large changes, or tasks that require broad exploration.
The compact handoff was produced in an external AI chat, not by Badger itself.
Automating /plan too early could be risky if the topology scan misses key files.

The main claim stays narrow: in this experiment, a compact Badger-assisted implementation handoff reduced OpenCode token movement and runtime compared with prompting OpenCode directly.

Supporting materials

The repository includes the experiment fixtures and the helper used to normalize the OpenCode session exports:

The raw/ directories contain the exact fixture snapshots used for the measured OpenCode sessions. The screenshots are copied separately for article display. No cleaned/ copy is needed for this writeup.

Conclusion

This experiment does not prove that Badger always saves tokens.

It is consistent with something more useful:

A compact implementation handoff can reduce local-agent exploration. Badger Design is useful as a local context-generation step, but the final artifact passed to a local coding agent should be terse, concrete, and execution-oriented.

That is a reasonable reason to keep exploring a future /plan focus, after there is more confidence in the topology and context-selection heuristics.

Bypassing the Claude Code "Token Tax": Smart Code Reviews with Local Mapping

Ted Kupolov — Tue, 07 Jul 2026 15:10:00 +0000

Autonomous coding agents are powerful, but they often come with a steep token tax. Tools like Claude Code can rapidly consume your usage limits during reviews by rescanning projects, pulling broad context, and running background operations.

AI Badger offers a better way: map your codebase locally, extract only the precise snippets needed, and conduct thoughtful reviews inside your favorite web chat.

Two Ways You Save Tokens

Dramatically more efficient usage - Badger eliminates noisy full-repo scans and recursive context loops. The AI receives clean, surgical context instead of everything.
Leverage fixed-cost web chats — Most web interfaces run on flat-rate monthly subscriptions (like ChatGPT Plus or Claude Pro) or offer generous free daily tiers. By offloading heavy discussions to the web chat, you leverage a fixed-cost window and avoid burning through your metered API balances or rolling agent limits.

Even on platforms where limits are shared, Badger helps you stay efficient and avoid the faster-burning autonomous modes.

Best Code Reviews with `badger review`

AI Badger shines in review mode. Here's a complete walkthrough using a simple React todo app.

Step 1: Launch Review Mode

cd my-react-app
badger review

Badger pre-loads your git diff with a default prompt. Edit it before submitting:

Review the following change for concrete bugs, edge cases, 
maintainability issues, and unintended behavior changes. 
Focus on issues I should fix before committing.

Step 2: Copy Prompt 1 (Compact Map)

Badger outputs a lightweight project topology (structure, key files, your diff summary). Paste into Claude Web, ChatGPT, DeepSeek, or any other chat.

Step 3: Targeted Extraction

The AI replies with precise selectors:

FILE:src/App.tsx
NEAR:src/App.tsx#function handleSubmit
PREFIX:src/components/TodoItem.tsx#return

Paste them back into Badger. It extracts only the relevant code.

Step 4: Paste Focused Prompt 2

Badger assembles clean context. Paste into your web chat — get high-quality review feedback without token waste.

Step 5: Apply Changes

Paste the AI's suggestions back into Badger. Review the write plan and apply fixes with confidence.

Trivial React Example

Consider a small change in a todo app:

// Missing key + potential re-render issues
{todos.map(todo => <TodoItem todo="{todo}"/>)}

Why this matters (even for non-React devs): When rendering lists in React, each item should have a unique key. Without it, the UI can behave strangely when items are added or removed. A good code review also flags small performance and accessibility improvements.

Badger + web chat quickly flags:

Missing key prop
Opportunities for React.memo or useCallback
Accessibility improvements

All while using far fewer tokens than a full autonomous agent.

Why This Workflow Wins

Precision-first — Only requested files/spans are sent
Fixed-cost advantage — Maximize value from subscriptions like ChatGPT Plus and Claude Pro
Review-optimized — Focuses the AI on risks and correctness
Privacy & control — Fully local until you copy; explicit consent for writes
Universal — Works with React, Go, Java, Node.js, Python, etc.

Install and Try It

brew tap pvrlabs/aibadger
brew install pvrlabs/aibadger/badger

Or:

curl -fsSL [https://raw.githubusercontent.com/PVRLabs/aibadger/main/install.sh](https://raw.githubusercontent.com/PVRLabs/aibadger/main/install.sh) | sh

Run badger review in any repo with changes.

Full documentation: docs/usage.md

If this workflow looks useful, consider giving AI Badger a ⭐ on GitHub - it helps other developers discover the project.