DEV Community: lef237

Track Codex, Claude, and OpenCode Usage Limits on One Screen with costsee

lef237 — Sun, 02 Aug 2026 03:21:53 +0000

Many people probably use all three of these tools: Codex, Claude Code, and OpenCode.

For each tool, you need to check how much usage you have left today, how much of the five-hour window you have consumed, whether you still have room in your weekly limit, and whether you have exceeded your monthly budget.

Although all of these are fundamentally the same kind of information—remaining usage capacity—they must be checked in different places.

I created costsee to solve this problem. It is a TUI application written in Rust that displays all of these usage limits together on a single terminal screen.

Know the Most Constrained Limit the Moment You Launch It

First, take a look at the actual interface.

 COSTSEE   most constrained Claude Code · 7 days  93%             updated 18:08

┌ Codex · team ──────────────────────── Codex App Server · updated 07/31 18:08 ┐
│        5 hours  ███░░░░░░░░░░░░░░░░░░   12%  left 2h 59m   reset 07-31 21:08 │
│         7 days  █████████░░░░░░░░░░░░   41%  left 4d 23h   reset 08-05 18:08 │
│  spend control  █░░░░░░░░░░░░░░░░░░░░    4%  left 19d 23h  reset 08-20 18:08 │
└──────────────────────────────────────────────────────────────────────────────┘
┌ Claude Code ────────────────── reported by Claude Code · updated 07/31 18:08 ┐
│        5 hours  ████████████████░░░░░   78%  left 59m      reset 07-31 19:08 │
│         7 days  ████████████████████░   93%  left 1d 23h   reset 08-02 18:08 │
└──────────────────────────────────────────────────────────────────────────────┘

I'll also show you a screenshot.

The bar and percentage columns use fixed widths shared by every tool. This lets you compare Codex’s 7 days limit with Claude Code’s 7 days limit simply by moving your eyes horizontally across the screen.

Even if each tool used a different width, you would still be able to read the individual numbers. However, you would no longer be able to compare them visually. Because the entire purpose of this tool is to view multiple tools side by side, consistent widths were a non-negotiable requirement.

Naming the Most Constrained Limit in the Header

The most constrained Claude Code · 7 days 93% message at the top of the screen serves this purpose. Before you read through each block individually, it tells you which limit is most likely to be reached first.

When the terminal is narrow, the message is shortened in stages according to the importance of the information. It first becomes 93% Claude Code · 7 days, and on an even narrower screen, simply 93%.

Changing Colors at Specific Thresholds

When usage exceeds 70%, the display turns yellow. When it exceeds 90%, it turns red.

The border around the entire block changes color, not just the individual row. This makes it possible to notice a problem as a change at the edge of your vision, even when you are not looking directly at the screen.

Showing the Time Remaining Until Reset

If the interface displayed only an absolute timestamp such as reset 08-02 18:08, the reader would need to calculate the difference from the current time mentally.

For that reason, costsee also displays the remaining time, such as left 1d 23h.

When deciding whether to continue working, the information you actually need is not the reset time itself, but how much time remains until the reset occurs.

It Also Works as a Claude Code Status Line

One somewhat unusual aspect of costsee is that it can run as Claude Code’s status line while also feeding the data it receives there into its own dashboard.

You can connect it with the following command:

costsee setup

This adds a statusLine entry to ~/.claude/settings.json. From that point onward, Claude Code calls costsee for every message, and costsee returns the following two lines:

Opus[high] · costsee(main) · ctx ███░░░░░░░  28% · $1.23
5h ████████░░  78% left 58m · 7d █████████░  93% left 1d 22h

The first line shows the state of the current session: the model name and its configuration, the working directory and branch, context consumption, and cost.

The second line shows the subscription usage limits.

Existing Status Lines Are Never Overwritten

If statusLine is already configured, costsee exits with an error without modifying the existing settings in any way.

It then explains how to add costsee capture-claude to the existing script and pass standard input to it.

Values Update Without Interrupting Your Work

Because the cache is updated whenever you interact with Claude Code, costsee monitors the modification time of that file.

When it detects a change, it automatically retrieves the latest data and displays ✓ auto-refreshed in the footer.

Leave costsee open in an adjacent pane, and the values will continue to update simply as you use Claude Code.

To refresh manually, press r.

One detail here is that communication with the Codex App Server can sometimes take time. For this reason, costsee draws refreshing… before it begins collecting data.

This avoids leaving the user in front of an apparently unresponsive screen without any indication that processing is underway.

When the refresh completes, ✓ refreshed appears for three seconds and then quietly disappears.

Press q or Esc to exit.

Using It from Scripts

There are also situations where you want to retrieve only the numbers without opening the TUI.

In that case, use the following command:

costsee report

tool        window   used   reset                       status
Codex       7 days   2.0%   2026-08-05T20:59:27+09:00  ok
Claude Code 5 hours  23.5%  2026-07-29T22:00:00+09:00  ok

Privacy Is a Design Requirement

Because this tool handles usage information, I established clear boundaries from the beginning regarding the data it is allowed to access.

For Codex, costsee temporarily starts the official App Server over stdio and reads only the result of account/rateLimits/read. It does not read session logs or authentication credentials. Codex’s own authentication is used directly, so costsee never takes possession of an API key.
For OpenCode, costsee opens the local SQLite database in read-only mode and reads only timestamps, providers, and costs. It never accesses conversation content.
For Claude Code, costsee caches only usage percentages and reset times. The model name, directory, context usage, and cost shown in the status line are rendered directly from the input and are never written to disk. Session IDs and transcript paths are neither displayed nor stored.
No telemetry is transmitted.

One additional point regarding OpenCode is that there is currently no official API that can accurately aggregate usage by time window without reading conversation text.

For this reason, access to the local database is isolated to the smallest possible scope. When costsee encounters an unexpected data format, it gives up rather than producing an estimated value.

Configuration

Codex is detected without any additional configuration.

OpenCode, however, supports multiple providers and therefore does not have the concept of a single shared usage limit. You must configure the spending limits yourself.

First, generate the configuration file:

costsee init

Then enter the official OpenCode Go limits in the generated ~/.config/costsee/config.toml file:

[allowances.opencode_go]
five_hour_usd = 12.0
weekly_usd = 30.0
monthly_usd = 60.0

The configuration-file path is standardized as ~/.config/costsee/config.toml on every operating system.

If the location varied between operating systems, it would create difficulties for people who share dotfiles across multiple environments.

You can also use the --config option to specify any path you prefer.

If codex is not included in your PATH, you can specify the executable path as follows:

[commands]
codex = "/path/to/codex"

One point to be aware of is that the exact reset times for the five-hour and weekly OpenCode Go limits cannot be determined from local history.

For those two limits, costsee displays unknown.

Here again, the policy is to state clearly when something is unknown.

Installation

Building costsee requires Rust 1.89 or later because it uses std::fs::File::lock when updating the Claude Code cache.

cargo install costsee
costsee

The main dependencies include ratatui 0.30, crossterm, rusqlite with the bundled feature, clap, and chrono.

At approximately 2,600 lines of source code, it is a relatively small tool.

Conclusion

The biggest change since I started keeping this tool open is that I now spend almost no time worrying about usage limits.

Previously, I would check three separate locations whenever I felt uneasy, but now I can simply verify the information on one terminal screen.

If the display has turned red after exceeding 90%, I can decide within seconds to postpone a resource-intensive task until the following day.

The repository is available below. Feedback and issue reports after trying it are welcome.

lef237 / costsee

costsee

A Rust TUI that shows how much of your Codex, Claude Code, and OpenCode allowances you have used—all in one place.

 COSTSEE   most constrained Claude Code · 7 days  93%             updated 18:08
┌ Codex · team ──────────────────────── Codex App Server · updated 07/31 18:08 ┐
│        5 hours  ███░░░░░░░░░░░░░░░░░░   12%  left 2h 59m   reset 07-31 21:08 │
│         7 days  █████████░░░░░░░░░░░░   41%  left 4d 23h   reset 08-05 18:08 │
│  spend control  █░░░░░░░░░░░░░░░░░░░░    4%  left 19d 23h  reset 08-20 18:08 │
└──────────────────────────────────────────────────────────────────────────────┘
┌ Claude Code ────────────────── reported by Claude Code · updated 07/31 18:08 ┐
│        5 hours  ████████████████░░░░░   78%  left 59m      reset 07-31 19:08 │
│         7 days  ████████████████████░   93%  left 1d 23h   reset 08-02 18:08 │
└──────────────────────────────────────────────────────────────────────────────┘

Bar widths are consistent across tools, so usage can be compared directly between blocks. Borders turn yellow above 70% usage and red above 90%.

Supported allowances

Codex: usage percentages for…

View on GitHub

Use gst to safely get an overview of all git states

lef237 — Thu, 04 Jun 2026 11:56:32 +0000

Checking changed files with git status, looking at history with git log, checking diffs with git diff...

When you repeatedly jump back and forth between these commands while working, you sometimes start thinking, “It would be nice if I could see all the information I want right now in one place.”

So I created gst, a CLI tool that lets you check the state of a Git repository at a glance.

lef237/gst: Read-only Git status visualizer

Why I built it

I was teaching Git to an acquaintance who had just started programming, and they said things like:

I don’t really understand git status

It’s hard to remember so many different commands

I’ve heard of tools like lazygit, but I’m scared I might accidentally change the repository state

That made me think: why not build a tool that solves those problems?

That was the starting point for this project.

What You Can See

When you launch gst, you can view your current branch, differences from remote repositories, modified files, staged changes, working directory diffs, stashes, and the commit graph—all from your terminal.

Demo video

A picture is worth a thousand words, so we have also prepared a video demonstration.

Watching it will give you a better sense of how gst works in practice and why it can be useful.

Installation

There are two ways to install it.

If you use Go, run:

go install github.com/lef237/gst/cmd/gst@latest

It also supports Homebrew. You can install it with:

brew install lef237/tap/gst

Usage

Normally, run the following command inside a repository:

gst

If you want to display the information once and then exit, use --once:

gst --once

In the TUI, you can move between views using the Tab key and arrow keys.

Press r to reload, and q to quit.

Read-Only

gst is a tool for checking the state of a repository.

It does not perform operations that modify the repository state, such as push, pull, checkout, commit, merge, or rebase.

Even if you are not very familiar with Git, there is less risk of accidentally changing something, so I think it is easy to use as a tool for checking repository status.

Diff display

In Git, staged changes and unstaged changes in the working tree are managed separately.

In gst, changed files are displayed with markers such as INDEX, WORKTREE, NEW, and CONFLICT.

This makes it easier to understand which files are staged and which files still only have changes in the working tree.

In the diff view, you can switch between the working tree diff and the staged diff.

This is useful when you want to check what will be included in the next commit, or when you want to organize your changes before splitting them into separate commits.

Copying diffs

In the diff view, you can copy the current diff directly to the clipboard.

Press y to copy working directory diffs, and i to copy staged diffs.

Pressing a copies a patch that includes all changes from HEAD to the current working directory.

The copied content is in patch format, so it can be applied with git apply.

I think this is very useful!

Summary

gst is not a tool intended to replace Git operations.

Rather, it is a tool for checking “what state is this repository in right now?” before you perform an operation.

Please give it a try :)

lef237 / gst

Read-only Git status visualizer

gst

gst is a read-only Git status visualizer for people who want to understand the shape of a repository before they run Git commands.

Demo: https://youtu.be/EMO3DaNkqT0

Motivation

Git beginners often struggle because the current state is split across several places:

commits and branches form a graph
local branches and remote tracking branches can point at different commits
the index and working tree can each contain different file changes

gst puts those pieces into one terminal dashboard. It does not push, pull checkout, commit, merge, rebase, or mutate the repository.

Install

go install github.com/lef237/gst/cmd/gst@latest

Or with Homebrew:

brew install lef237/tap/gst

For local development:

go run ./cmd/gst

To build a local binary:

go build -o tmp/gst ./cmd/gst

Release steps are documented in docs/release.md.

Usage

gst
gst --interval 1s
gst --once
gst --no-color

By default, gst opens the interactive TUI.

Interactive controls:

Move between views with tab, the left/right arrow keys…

View on GitHub

clauhist: browse full Claude Code history and resume sessions across projects

lef237 — Sat, 28 Mar 2026 04:43:38 +0000

Claude Code can already help you resume work from a project if you move into that working directory and use /resume there.

The limitation is that this is tied to the current working directory. If you want to look back across all of your past work, including sessions from other repositories and directories, that gets awkward.

clauhist is a small CLI tool for that case. It shows your Claude Code history in fzf, lets you browse sessions across working directories, and resume one from the list.

What it shows

Sessions are sorted by recent activity. Each row includes:

the last activity time
the project path
whether the path still exists
a preview of the first message
the message count

There is also a preview pane with the session ID, timestamps, and message list. Once you find the one you want, press Enter.

How it works

clauhist reads ~/.claude/history.jsonl, groups entries by session, and passes the result to fzf.

After you select a session, it runs:

claude --resume <session-id>

It does not keep its own database or add another history layer. It is just a thin local browser over Claude Code's existing history file.

Installation

cargo install clauhist

Or install from source:

git clone https://github.com/lef237/clauhist.git
cd clauhist
cargo install --path .

You also need fzf and Claude Code installed.

Usage

clauhist

Main controls:

Enter: resume the selected session
type: filter the list
Ctrl-/: toggle preview
Ctrl-C: exit

It is displayed on the terminal like this:

╭───────────────────────────────────────────────────────────────────────────────────────╮
│ Claude Code History Browser  [Enter: resume  Ctrl-/: toggle preview  Ctrl-C: cancel]  │
├───────────────────────────────────────────────────────────────────────────────────────┤
│ Search:                                                                               │
│ > 2026-03-18 09:12  ✓ ~/projects/myapp      Tell me about Rust error handling…  (12)  │
│   2026-03-17 22:45  ✓ ~/sandbox/api-client  Generate client from OpenAPI schema  (8)  │
│   2026-03-17 14:30  ✗ ~/old-project         Database migration steps             (3)  │
╰───────────────────────────────────────────────────────────────────────────────────────╯

✓ means the project directory still exists. ✗ means it was moved or deleted. You can still resume the session, but cd into the original directory may fail.

Shell integration

If you add this to your shell config:

eval "$(clauhist init zsh)"

then clauhist will now change to the project directory within your current shell before launching Claude Code.

This allows you to immediately return to your original directory with cd -.

Without this, clauhist uses a subshell for the directory change, so exit to return to your original shell.

Local-only

clauhist only reads ~/.claude/history.jsonl and launches claude --resume. It does not send your history anywhere.

That is the whole tool: a simple way to browse past Claude Code sessions across projects and reopen one without moving directory by directory.

GitHub

You can find the repository here :)

lef237 / clauhist

Browse Claude Code history across working directories and resume sessions

clauhist

Browse Claude Code history across working directories and resume sessions.

╭───────────────────────────────────────────────────────────────────────────────────────╮
│ Claude Code History Browser  [Enter: resume  Ctrl-/: toggle preview  Ctrl-C: cancel]  │
├───────────────────────────────────────────────────────────────────────────────────────┤
│ Search:                                                                               │
│ > 2026-03-18 09:12  ✓ ~/projects/myapp      Tell me about Rust error handling…  (12)  │
│   2026-03-17 22:45  ✓ ~/sandbox/api-client  Generate client from OpenAPI schema  (8)  │
│   2026-03-17 14:30  ✗ ~/old-project         Database migration steps             (3)  │
╰───────────────────────────────────────────────────────────────────────────────────────╯

(Example output — actual appearance depends on your terminal and fzf version)

Claude Code can already resume work from the current project directory. clauhist solves a different problem: browsing the full history across all of your working directories from one place.

Select a session and press Enter — clauhist opens claude --resume in the project directory. When you exit Claude, you return to your original shell.

Why clauhist exists

If you cd into a project and use Claude Code's /resume there, you can inspect…

View on GitHub

https://github.com/lef237/clauhist

One-Time Editor, an editor for drafts before sending

lef237 — Mon, 09 Mar 2026 13:16:35 +0000

I've created an app called "One-Time Editor".

The image above shows dark mode. Here's what it looks like in light mode.

What kind of app is it, you ask? It's a text editor that can be used for drafting messages before sending them in a chat.

By using this app, you can avoid the worry of accidentally sending a message prematurely by hitting Enter.

To quickly understand how it works, I recommend watching the video, which I've attached below.

https://youtu.be/qwj9fr77vQg

How to Install

For macOS, use Homebrew. You can start using it right away by typing the following commands in your terminal.

brew tap lef237/tap
brew install --cask one-time-editor

Since it's an Electron-based app, it's also cross-platform compatible.

Windows and Linux users can install the pre-built app from here.

https://github.com/lef237/one-time-editor/releases

Windows users should select the .exe file, and Linux users should select the AppImage to install it. ¹

Features

The main highlight is that you can toggle (show/hide) the window using a keyboard shortcut.

What's more, it automatically copies the content you've entered as soon as you toggle it, allowing for instant pasting.

Open One-Time Editor with a keyboard shortcut.
Type the content you want to send.
Close it with the keyboard shortcut.
- The content will be automatically copied.
- On macOS, focus will automatically return to the window you were previously using.
Paste and then send.

It also supports switching between light and dark modes. I think the design is also stylish.

Of course, you can also customize the keyboard shortcut! The default is Ctrl+J, but feel free to assign any shortcut you like.

Why I Made It

Many people have probably experienced indecision about whether to use Enter, Shift+Enter, or Ctrl+Enter to send a chat message.

And then, accidentally sending a message in the middle of writing...

Using some kind of editor for drafting isn't bad, but it can be a bit cumbersome to constantly be asked to create a new file or to manage windows.

This app is designed for throwaway writing, and it allows for displaying/hiding the window and copying content with a single shortcut, making it quite fast.

Challenges During Development

There were several challenges.

However, the most difficult problem was dealing with code signing and notarization.

When you create an app with Electron, it works fine on your local machine, but if you upload it to the internet and download it, the app becomes corrupted.

You might have seen this warning when downloading things like Docker:

Therefore, you need to use the xattr command.

Fix macOS app is damaged and can't be opened" Error - Complete Guide - osxhub

osxhub.com

This means you need to run the command xattr -rc "/Applications/hoge.app" after installation, which is a bit troublesome.

When I looked into simplifying this, I realized that using postflight could automate this process if installed via homebrew-tap.

https://github.com/lef237/homebrew-tap/blob/main/Casks/one-time-editor.rb

If you're looking to distribute Electron apps, please use this as a reference!

GitHub

GitHub is also public.

If you have any feature requests, please open an Issue. 🐘

lef237 / one-time-editor

A lightweight scratchpad that lives one shortcut away

One-Time Editor

A lightweight scratchpad that lives one shortcut away. Draft a message, hit the shortcut again, and it's already on your clipboard — ready to paste anywhere.

Built for the workflow of writing chat messages, AI prompts, and quick notes that you type once and send.

https://youtu.be/qwj9fr77vQg

Install

macOS (Homebrew)

brew tap lef237/tap
brew install --cask one-time-editor

Manual download

Pre-built binaries for macOS, Windows, and Linux are available on the Releases page.

If you download manually on macOS, the app is not signed with an Apple Developer certificate, so macOS may show a warning. To allow it, run:

xattr -cr "/Applications/One-Time Editor.app"

How it works

Press Ctrl+J to summon the editor
Type your text
Press the shortcut again — the window disappears and your text is copied to clipboard
Paste wherever you need it

That's it. No save dialog, no file management, no friction.

The shortcut is…

View on GitHub

https://github.com/lef237/one-time-editor

If it doesn't work on Windows or other OSs, please comment on GitHub! ↩

Writing a Domain Model in Ruby Without Using class

lef237 — Wed, 13 Aug 2025 10:47:28 +0000

Introduction

From Ruby 3.2, the Data class has been introduced, allowing us to explore ways of representing domain models without using class. In this article, I’ll examine how we can do that.

When writing business logic in Ruby, we naturally tend to use class.

We set attributes in initialize, and change state via instance methods. Especially if you’ve been writing Rails code, this feels natural.

However, whether managing logic with a stateful class is suitable for every case is debatable. For domain logic where we want to avoid side effects, class-based design might not always be optimal. In recent years, designs influenced by functional programming have gained attention, and as has been discussed on X (formerly Twitter), the mainstream approach in TypeScript is moving toward avoiding classes entirely.

With the Data class introduced in Ruby 3.2, we can represent domains while keeping structural data and logic separate. In this article, I’ll show you how.

Note: This article focuses on representing domain logic, separate from Rails' ActiveRecord models.

I’m specifically looking at a style that works purely with plain Ruby syntax, without being tied to the Rails environment. This is driven more by curiosity than by real-world constraints, so please keep that in mind.

What Is the `Data` Class?

The Data class introduced in Ruby 3.2 lets you define immutable data structures easily. It’s similar to the Struct that Ruby already had, but all fields are immutable — to change a value, you must create a new instance.

class Data - Documentation for Ruby

To use a loose analogy: Struct is like a hash, while Data is like a read-only hash.

Let’s actually design a domain model using the Data class.

Example Domain Model

First, let’s think of an example.

We’ll imagine a Customer model with the following attributes:

id
email
first_name / last_name
is_active
created_at / updated_at

We want to be able to perform operations such as:

Changing the name
Changing the email address
Activating/deactivating the customer
Getting the full name

Especially the first three operations would naturally become methods that change state.

A Class-Based Implementation

First, let’s design it in the usual class-based way. You might find there are too many instance variables, among other nitpicks, but let’s just write it out as a sample.

class Customer
  attr_reader :id, :email, :first_name, :last_name, :is_active, :created_at, :updated_at

  def initialize(id:, email:, first_name:, last_name:, is_active: true)
    validate_name!(first_name, last_name)
    validate_email!(email)
    @id = id
    @email = email
    @first_name = first_name
    @last_name = last_name
    @is_active = is_active
    @created_at = Time.now
    @updated_at = Time.now
  end

  def change_name(first_name, last_name)
    validate_name!(first_name, last_name)
    @first_name = first_name
    @last_name = last_name
    touch
  end

  def change_email(email)
    validate_email!(email)
    @email = email
    touch
  end

  def deactivate
    return unless @is_active
    @is_active = false
    touch
  end

  def activate
    return if is_active
    @is_active = true
    touch
  end

  def full_name
    "#{first_name} #{last_name}"
  end

  private

  def touch
    @updated_at = Time.now
  end

  def validate_name!(first_name, last_name)
    if first_name.strip.empty? || last_name.strip.empty?
      raise ArgumentError, "Invalid name"
    end
  end

  def validate_email!(email)
    unless email.match?(/\A[^@\s]+@[^@\s]+\z/)
      raise ArgumentError, "Invalid email format"
    end
  end
end

This can be used as follows:

customer = Customer.new(
  id: "c1",
  email: "alice@example.com",
  first_name: "Alice",
  last_name: "Anderson"
)

customer.change_name("Bob", "Brown")
customer.deactivate
puts customer.full_name # => "Bob Brown"

Here, we create an instance with new and call methods to change its state — a very common approach.

The `Data` Class Available from Ruby 3.2

In Ruby 3.2, the Data class was introduced.

It feels similar to Struct, but all fields are immutable.

Customer = Data.define(
  :id, :email, :first_name, :last_name,
  :is_active, :created_at, :updated_at
)

To change a value, you use .with to create a new instance.

Suppose customer1 has first_name set to Bob:

customer1 = Customer.new(
  id: "c1",
  email: "bob@example.com",
  first_name: "Bob",
  last_name: "Johnson",
  is_active: true,
  created_at: Time.now,
  updated_at: Time.now
)

To change first_name to Carol:

customer2 = customer1.with(first_name: "Carol")

customer1 remains unchanged; customer2 is a new object with only first_name different.

puts customer1.first_name  # => "Bob"
puts customer2.first_name  # => "Carol"

With Data.with, we handle state not by mutation but by replacement, avoiding unintended side effects.

Writing Domain Logic with `Data` and Functions

Let’s rewrite the earlier class-based code using Data.

We’ll define a CustomerService module, separate from Customer, to hold our domain operations as functions.

Customer = Data.define(
  :id, :email, :first_name, :last_name,
  :is_active, :created_at, :updated_at
)

module CustomerService
  module_function

  def create_customer(id:, email:, first_name:, last_name:)
    validate_name!(first_name, last_name)
    validate_email!(email)

    now = Time.now
    Customer.new(
      id,
      email.strip,
      first_name.strip,
      last_name.strip,
      true,
      now,
      now
    )
  end

  def change_name(customer, first_name:, last_name:)
    validate_name!(first_name, last_name)
    customer.with(
      first_name: first_name.strip,
      last_name: last_name.strip,
      updated_at: Time.now
    )
  end

  def change_email(customer, email:)
    validate_email!(email)
    customer.with(email: email.strip, updated_at: Time.now)
  end

  def deactivate(customer)
    return customer unless customer.is_active
    customer.with(is_active: false, updated_at: Time.now)
  end

  def activate(customer)
    return customer if customer.is_active
    customer.with(is_active: true, updated_at: Time.now)
  end

  def full_name(customer)
    "#{customer.first_name} #{customer.last_name}"
  end

  def validate_name!(first_name, last_name)
    if first_name.strip.empty? || last_name.strip.empty?
      raise ArgumentError, "Invalid name"
    end
  end

  def validate_email!(email)
    unless email.match?(/\A[^@\s]+@[^@\s]+\z/)
      raise ArgumentError, "Invalid email format"
    end
  end
end

Here, create_customer is used as a factory in CustomerService. By defining domain operations as functions, we can handle changes to state in a way that minimizes side effects.

Each function doesn’t change the Customer data structure directly — it uses .with to create a new instance. This preserves data immutability and brings the design closer to a functional style.

Also, by using module_function, we can call these functions without creating an instance of the module. Validation is performed inside the functions where needed.

This cleanly separates data (Customer) from behavior (functions).

Example Usage

customer = CustomerService.create_customer(
  id: "c1",
  email: "alice@example.com",
  first_name: "Alice",
  last_name: "Anderson"
)

customer = CustomerService.change_name(customer, first_name: "Bob", last_name: "Brown")
customer = CustomerService.deactivate(customer)

puts CustomerService.full_name(customer) # => "Bob Brown"

Note that when reassigning, we return a new object instead of modifying the original. I considered naming them customer_updated, customer_updated2, etc., but left it as-is for now.

By not using instance variables and passing all state through arguments, we avoid side effects. At that point, all that’s left is to store the final state in the database or handle it however needed.

For example, saving with SQLite might look like this:

db.execute(
  "INSERT OR REPLACE INTO customers (id, email, first_name, last_name, is_active, created_at, updated_at) VALUES (?, ?, ?, ?, ?, ?, ?)",
  customer.id,
  customer.email,
  customer.first_name,
  customer.last_name,
  customer.is_active ? 1 : 0,
  customer.created_at.iso8601,
  customer.updated_at.iso8601
)

You can access attributes with customer.xxx, so it feels similar to using a class.

Points to Note

Of course, there’s nothing wrong with using class. For UI logic, controllers, database models like ActiveRecord, and so on, class-based design often makes sense.

In Rails projects, it’s common to extract structured data handling into POROs (Plain Old Ruby Objects) written as classes.

Plain Old Ruby Objects (POROs) in Rails Fat Models - DEV Community

However, as domain logic grows more complex, tracking “state changes” through the code becomes harder. In such cases, a design where “values are immutable and logic is functional” — like the one shown here — can make maintenance easier.

Summary

Ruby is a flexible language, and you can represent domain logic without relying on classes or instance variables.

Ruby 3.2’s Data class can be a useful tool for designing the domain layer as structured data plus explicit functions. You don’t have to use it for every case, but simply knowing it’s an option can broaden your design possibilities.

DEV Community: lef237

Track Codex, Claude, and OpenCode Usage Limits on One Screen with costsee

Know the Most Constrained Limit the Moment You Launch It

Naming the Most Constrained Limit in the Header

Changing Colors at Specific Thresholds

Showing the Time Remaining Until Reset

It Also Works as a Claude Code Status Line

Existing Status Lines Are Never Overwritten

Values Update Without Interrupting Your Work

Using It from Scripts

Privacy Is a Design Requirement

Configuration

Installation

Conclusion

lef237 / costsee

costsee

Supported allowances

Use gst to safely get an overview of all git states

Why I built it

What You Can See

Demo video

Installation

Usage

Read-Only

Diff display

Copying diffs

Summary

lef237 / gst

Read-only Git status visualizer

gst

Motivation

Install

Usage

clauhist: browse full Claude Code history and resume sessions across projects

What it shows

How it works

Installation

Usage

Shell integration

Local-only

GitHub

lef237 / clauhist

Browse Claude Code history across working directories and resume sessions

clauhist

Why clauhist exists

One-Time Editor, an editor for drafts before sending

How to Install

Features

Why I Made It

Challenges During Development

Fix macOS app is damaged and can't be opened" Error - Complete Guide - osxhub

GitHub

lef237 / one-time-editor

A lightweight scratchpad that lives one shortcut away

One-Time Editor

Install

macOS (Homebrew)

Manual download

How it works

Writing a Domain Model in Ruby Without Using class

Introduction

What Is the Data Class?

Example Domain Model

A Class-Based Implementation

The Data Class Available from Ruby 3.2

Writing Domain Logic with Data and Functions

Example Usage

Points to Note

Summary

What Is the `Data` Class?

The `Data` Class Available from Ruby 3.2

Writing Domain Logic with `Data` and Functions