alies.dev

Stop Wasting 89% of Your AI Agent's Tokens on CLI Noise

2026-03-25T00:00:00Z

PHPUnit 12.5.14 by Sebastian Bergmann and contributors.

Runtime: PHP 8.4.19 Configuration: /var/www/html/phpunit.xml

............................................................... 63 / 500 ( 12%) ............................................................... 126 / 500 ( 25%) ............................................................... 189 / 500 ( 37%) ..................................F............................ 252 / 500 ( 50%) ............................................................... 315 / 500 ( 63%) ............................................................... 378 / 500 ( 75%) ............................................................... 441 / 500 ( 87%) ........................................................... 500 / 500 (100%)

~250 tokens of PHPUnit output — 45% is noise from progress dots

AI coding agents - Claude Code, Cursor, GitHub Copilot, Windsurf - run your CLI tools and feed the output back into the LLM context window. The problem: most CLI tools were built for humans staring at terminals, not for machines parsing results.

Progress bars, color codes, box-drawing borders, ASCII art banners - all meaningless noise for an LLM. And you're paying for every token of it.

The numbers #

Over ~2,900 CLI commands measured by rtk-ai, 11.6M input tokens were consumed, of which 10.3M (89.2%) were noise. A typical 2-hour AI coding session generates ~210K tokens of raw CLI output - enough to overflow a 200K context window with mostly garbage.

A team of 10 developers wastes approximately $1,750/month on noise tokens alone.

A PHPUnit example #

Here's the default PHPUnit output for a test suite with 500 tests, 1 failure:

PHPUnit 12.5.14 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.4.19
Configuration: /var/www/html/phpunit.xml

...............................................................   63 / 500 ( 12%)
...............................................................  126 / 500 ( 25%)
...............................................................  189 / 500 ( 37%)
..................................F............................  252 / 500 ( 50%)
...............................................................  315 / 500 ( 63%)
...............................................................  378 / 500 ( 75%)
...............................................................  441 / 500 ( 87%)
...........................................................      500 / 500 (100%)

Time: 00:12.345, Memory: 256.00 MB

There was 1 failure:

1) Tests\Unit\AppHelperTest::get_morph_class_accepts_model_instance
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'App\Models\Role'
+'App\Models\Role---error'

/var/www/html/tests/Unit/AppHelperTest.php:20

FAILURES!
Tests: 500, Assertions: 1200, Failures: 1.

~250 tokens. The progress lines, banner, timing, and memory stats account for most of it. The actual failure information is only ~85 tokens.

Now the same result with --no-progress:

PHPUnit 12.5.14 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.4.19
Configuration: /var/www/html/phpunit.xml

Time: 00:12.345, Memory: 256.00 MB

There was 1 failure:

1) Tests\Unit\AppHelperTest::get_morph_class_accepts_model_instance
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'App\Models\Role'
+'App\Models\Role---error'

/var/www/html/tests/Unit/AppHelperTest.php:20

FAILURES!
Tests: 500, Assertions: 1200, Failures: 1.

~140 tokens. Same failure details. The banner and footer are still there (PHPUnit doesn't let you suppress them), but the 500 progress dots are gone. ~45% reduction - and on a 5,000-test suite, the savings are even larger.

What wastes the most tokens #

Token waster	Impact
Progress bars (`████`, dots)	500-2000 tokens per run
Box-drawing borders (`+---+`)	2-5x more tokens than plain text
ASCII art banners	50-200 tokens per logo
Repeated dots (PHPUnit)	~1 token per dot, hundreds per suite

Note: ANSI color codes (\x1b[31m) are often cited as a waste, but most CLI tools auto-detect TTY and disable colors when output is piped - which is always the case with AI agents. Flags like --colors=never, --no-ansi, and --monochrome are usually redundant. The flags below focus on what actually matters.

The fix: one flag per tool #

Every PHP quality tool has flags to disable the noise. Here's the cheat sheet:

# PHPUnit / ParaTest
--no-progress

# PHPStan - use raw format (file:line:message, one per line)
--no-progress --error-format=raw

# Psalm - use text format (file:line:col:severity, one per line)
# Psalm 7: use --output-format=compact (one-line, relative paths, no URLs)
--no-progress --no-suggestions --output-format=text

# phpcs - use emacs format (file:line:col:severity, one per line)
--report=emacs -q

# PHP-CS-Fixer
--show-progress=none -q -n

# Rector
--no-progress-bar --output-format=github

# Pint - use agent format (auto-detected in Claude Code/OpenCode)
./vendor/bin/pint --test --format agent

# Composer
composer install -q

PHPStan 2.x note: When CLAUDECODE=1 is set (always true in Claude Code), PHPStan injects a ~940-byte preamble with AI instructions and adds [identifier=X] suffixes to every error. This agent detection overhead can be larger than the format difference itself. If it bothers you, set CLAUDECODE=0 before running PHPStan.

Where to put these flags #

Don't memorize them. Put them in your CLAUDE.md or AGENTS.md file - this is read by Claude Code, Cursor, Gemini CLI, OpenCode, and others:

## Running Tools

Always use these flags when running CLI tools:

- Tests: `vendor/bin/phpunit --no-progress`
- PHPStan: `vendor/bin/phpstan analyse --no-progress --error-format=raw`
- Psalm: `vendor/bin/psalm --no-progress --no-suggestions --output-format=text`
- phpcs: `vendor/bin/phpcs --report=emacs -q`
- PHP-CS-Fixer: `vendor/bin/php-cs-fixer fix --show-progress=none -q -n`
- Rector: `vendor/bin/rector process --no-progress-bar --output-format=github`

The pattern #

Across all tools, the pattern is the same:

Disable progress bars - the #1 token waster
Use one-line-per-error format - raw, text, emacs, github or compact
Don't switch to JSON - it has ~50% overhead from key repetition. Plain text is more token-efficient for error lists
Skip color flags - most tools auto-detect TTY and disable colors when piped

Do this once, save thousands of tokens per session, and stop feeding your AI agent junk.

Token counts in this article are measured with the cl100k_base tokenizer (GPT-4). Claude, Gemini, and other models use different tokenizers, so exact counts will vary — but the ratios and savings hold across models.

What's else? #

This article covers PHP, but the same problem exists in every ecosystem. I've collected quiet-mode flags for Node, Python, Go, Rust, Ruby, Java, Kotlin, Swift, and .NET in one place: awesome-ai-friendly-cli — a curated list of CLI flags that cut token waste across languages and tools.

If you want to go further, check out rtk - a CLI proxy that sits between your AI agent and your tools, automatically filtering noise tokens in real time. No flags to remember, no CLAUDE.md to maintain. It measured the 89% waste number at the top of this article.

First hour of a new Laravel project

2024-07-05T00:00:00Z

INFO Preparing database.

Creating migration table .............................................. 2.71ms DONE

INFO Running migrations.

0001_01_01_000000_create_users_table .................................. 2.88ms DONE
0001_01_01_000001_create_cache_table .................................. 1.00ms DONE
0001_01_01_000002_create_jobs_table ................................... 2.08ms DONE

~/code/alies-dev/new-project ⮀ ⭠ main ⮀

Great! You've just created a new Laravel project and want to do everything right from the start, correct? This guide will walk you through essential steps to optimize your new Laravel project in its first hour.

Configure Eloquent Strictness #

Laravel provides the Model::shouldBeStrict method that does three things:

Prevents lazy loading (addressing the N+1 problem). See Preventing Lazy Loading
Prevents silently discarding attributes (throws an exception when attempting to fill an unfillable attribute)
Prevents accessing missing attributes

The "lazy loading" prevention often depends on database data, so it's better to avoid throwing an exception in production. For the other two, you can enable them in all environments:

// AppServiceProvider.php or any other service provider
public function boot(): void
{
    Model::preventLazyLoading(! $this->app->isProduction());
    Model::preventSilentlyDiscardingAttributes();
    Model::preventAccessingMissingAttributes();
}

Choose Primary Key Type #

There are three common types of primary keys:

Auto-incrementing integer (technically, by default it's an UNSIGNED BIGINT)
UUID (example: 6e48762e-8c54-43ab-b2f2-09eebb59ad9b)
ULID (example: 01j2qxp0rg5618brj9c9kmrk6h)

Choosing the right type is a big topic (you can start by reading the Laravel documentation). If you choose UUID or ULID, you can instruct Laravel to use the proper morph key type when you use $table->morphs() and $table->nullableMorphs() in migrations:

// AppServiceProvider.php or any other service provider
public function boot(): void
{
    Builder::morphUsingUuids(); // for UUID
    Builder::morphUsingUlids(); // for ULID
}

Other packages may (and should) also respect this setting (e.g., Laravel Nova).

Enforce Morph Map #

If you plan to rename your Models (rename a class or change a namespace), I recommend enforcing a morph map to avoid data corruption. This way, Laravel will not store the fully qualified class name (FQCN) in the database, but a short alias instead. If an alias is not set, Laravel will throw a \Illuminate\Database\ClassMorphViolationException exception.

// AppServiceProvider.php or any other service provider
public function boot(): void
{
    Relation::enforceMorphMap([
        'user' => User::class,
        'team' => Team::class,
    ]);
}

Prohibit Destructive Commands on Production #

To avoid accidental data loss, you can prohibit destructive commands on production. Laravel provides a handy DB::prohibitDestructiveCommands method to do this:

// AppServiceProvider.php or any other service provider
public function boot(): void
{
    DB::prohibitDestructiveCommands($this->app->environment('production'));
}

Use immutable dates #

By default, Laravel uses mutable Carbon instances. In practice, that means to avoid changing values of created_at and updated_at attributes, you need to first clone Carbon objects:

$monthAfterRegistration = $user->created_at->clone()->addMonth();

You can instruct Laravel to always create immutable Carbon instances:

// AppServiceProvider.php or any other service provider
use Carbon\CarbonImmutable;
use Illuminate\Support\Facades\Date;

public function boot(): void
{
    Date::use(CarbonImmutable::class);
}

With a small cost of memory consumption, you can avoid many bugs related to mutable dates and eliminate the need to call the clone() method.

- $monthAfterRegistration = $user->created_at->clone()->addMonth();
+ $monthAfterRegistration = $user->created_at->addMonth();

Install Composer Packages #

Clockwork #

In my opinion, Clockwork is the best tool of the "Laravel debug bar" type, as it doesn't change your HTML output.

composer require itsgoingd/clockwork --dev

Larastan #

Larastan is an essential static analysis tool for Laravel projects. With a minimal time investment, you can get a great reporting tool for potential bugs.

composer require larastan/larastan --dev

Paratest #

Paratest enables parallel testing for PHPUnit/Pest, which will make your tests run faster (proportional to the number of cores in your CPU).

composer require brianium/paratest --dev

After installation, please check the official Laravel documentation on Running Tests in Parallel.

Composer Dependency Analyser #

Composer Dependency Analyser provides fast detection of composer dependency issues such as:

Unused dependencies
Shadow dependencies
Misplaced dependencies
Dev dependency on production code
Production dependency that is only in dev code

composer require --dev shipmonk/composer-dependency-analyser

Set up a CI/CD Pipeline #

Set up a CI/CD pipeline with GitHub Actions, GitLab CI, or any other CI/CD service. I've prepared a simple Laravel GitHub workflows starting pack that includes three workflows:

Main (runs tests, security checks, and deploys)
Code quality (non-blocking deployment)
Code style check (non-blocking deployment)

Document Your Project #

Create a comprehensive README.md and list all commands needed to run, test, develop, and deploy the project. Even if you're the only developer, your future self will thank you for this thorough documentation.

Conclusion #

Since we're limited to one hour, I'll conclude here. These initial steps will set a solid foundation for your development process. There are many more ways to improve your Laravel project, most of which are project-specific.

sscanf simplifies your regex

2024-07-04T00:00:00Z

The sscanf PHP function offers a powerful alternative to regular expression functions like preg_match for parsing strings. While less flexible than regex, sscanf can be more readable and efficient for simple parsing tasks.

Surprisingly, sscanf is a hidden gem in PHP, and many developers are unaware of its existence. It's a wrapper around the C library function, and it's available in PHP since the early days.

Basic examples #

Example 1: Basic usage

$input = 'John 25 New York';
sscanf($input, '%s %d %s', $name, $age, $city);

Example 2: Parsing a date string

$date = '2023-07-08';
sscanf($date, '%d-%d-%d', $year, $month, $day);

Example 3: Parsing a complex log entry

$logEntry = "2023-07-08 14:30:45 [WARNING] User authentication failed: username=johndoe, ip=192.168.1.100";
$pattern = "%d-%d-%d %d:%d:%d [%s] %[^:]: username=%[^,], ip=%s";
sscanf($logEntry, $pattern, $year, $month, $day, $hour, $minute, $second, $level, $message, $username, $ip);

sscanf vs preg_match #

Parsing a URL example, diff:

-preg_match('/^(\S+):\/\/([^\/]+)\/(.*)$/', $url, $matches);
-$scheme = $matches[1];
-$domain = $matches[2];
-$path = $matches[3];
+sscanf($url, "%[^:]://%[^/]/%s", $scheme, $domain, $path);

4 lines vs. 1 line!! Of course, it’s a simplified example (for real URL parsing, please use parse_url), but shares the idea. While sscanf isn't a complete replacement for regex, it can simplify many common string parsing tasks in PHP.

Still need to write a regex? Check out a great Writing better Regular Expressions in PHP article.