How Vector Embeddings Can Slash Your LLM API Costs by 80%

If you’re building applications powered by large language models, you’ve probably noticed something painful: your API bill keeps growing. Not because your application is doing anything particularly complex, but because users keep asking variations of the same questions, and each variation triggers a fresh API call.

This is the hidden tax of working with LLMs, and today I want to show you how to solve it with semantic caching.

The Problem with Traditional Caching

Let’s say you’re building a customer support chatbot. A user asks, “How do I reset my password?” Your application calls the OpenAI API or any other LLMs provider, gets a response, and you wisely decide to cache it. Smart move.

But then another user comes along and asks, “I forgot my password, what should I do?” Your cache looks at this query, compares it character by character with what’s stored, and finds no match. So off goes another API request. You pay again and the user waits again.

Here’s what traditional caching sees:

"How do I reset my password?" ≠ "I forgot my password, what should I do?"

Different strings. Cache miss. End of story.

Now imagine this happening hundreds or thousands of times per day across all the different ways people phrase the same questions. Your cache hit rate stays frustratingly low, and your costs stay frustratingly high.

The fundamental issue is that traditional caching operates on syntax (the exact sequence of characters) when what we really care about is semantics the meaning behind those characters.

Enter Semantic Caching

What if your cache could understand that “How do I reset my password?” and “I forgot my password, what should I do?” are essentially asking the same thing? What if it could recognize meaning, not just text?

This is what semantic caching does. Instead of storing queries as raw strings, it converts them into vector embeddings mathematical representations that capture the semantic meaning of text. When a new query arrives, the system converts it to a vector and searches for similar vectors in the cache. If it finds one above a certain similarity threshold, it returns the cached response without ever touching the LLM API.

This is happens because embedding models are trained to place semantically similar text close together in vector space. “Reset my password” and “forgot my password” end up as neighboring vectors, even though they share few common words.

How It Works Under the Hood

┌─────────────────────────────────────────────────────────────────┐
│                      User Query                                 │
│              "What's the capital of France?"                    │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                   L1 Cache (Exact Match)                        │
│                    Caffeine In-Memory                           │
│                      < 1ms lookup                               │
└─────────────────────────────────────────────────────────────────┘
                              │ Miss
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    Embedding Provider                           │
│            Convert text → [0.023, -0.891, 0.445, ...]           │
│               (ONNX, OpenAI, Ollama, Azure)                     │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                 L2 Cache (Semantic Search)                      │
│              Vector similarity search in storage                │
│              (Redis, Elasticsearch, In-Memory)                  │
│                                                                 │
│   Cached: "Tell me France's capital" → similarity: 0.94 ✓       │
└─────────────────────────────────────────────────────────────────┘
                              │ Hit!
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                     Return: "Paris"                             │
│                  Total time: ~10-50ms                           │
│                  Cost: $0.00                                    │
└─────────────────────────────────────────────────────────────────┘

The dual-level architecture is key:

• L1 Cache: Exact matches with sub-millisecond latency
• L2 Cache: Semantic matches with millisecond latency (Vector storage)

Introducing Semantic LLM Cache for Java

Semantic LLM Cache is my open-source library that brings this capability to Java and Spring Boot applications. It handles the complexity of embedding generation, vector storage, and similarity search, exposing a simple interface that feels native to Spring developers.

Let me walk you through how it works and how to integrate it into your application.

Getting Started

First, add the dependencies to your project. You’ll need three components: the Spring Boot starter, a storage backend, and an embedding provider.

GitHub - Jamalianpour/semantic-llm-cache: Semantic caching for LLM API responses in Spring Boot applications

Each component is modular by design. You can swap storage backends or embedding providers without changing your application code. This matters because your needs will evolve, you might start with in-memory storage for development and move to Redis or Elasticsearch for production.

Configuration

Next, configure the cache in your application.yml:

semantic-cache:
  embedding:
    provider: openai
    api-key: ${OPENAI_API_KEY}        # Your OpenAI API key
    model: text-embedding-3-small     # Cost-effective embedding model
  storage:
    type: memory                       # In-memory for development
  defaults:
    similarity-threshold: 0.92         # How similar queries must be (0.0 to 1.0)
    ttl: 24h                           # How long cached responses live

The similarity-threshold parameter is crucial. Setting it to 0.92 means a query must be at least 92% similar to a cached query to be considered a match. Too low, and you'll return incorrect responses for genuinely different questions. Too high, and you'll miss opportunities to serve from cache. I've found 0.90 to 0.95 works well for most conversational AI applications, but you should experiment with your specific use case.

Using the Annotation

Now comes the elegant part. To enable semantic caching on any method, simply add the @SemanticCache annotation:

@Service
public class CustomerSupportService {

    private final OpenAiClient openAiClient;

    public CustomerSupportService(OpenAiClient openAiClient) {
        this.openAiClient = openAiClient;
    }

    @SemanticCache(
        namespace = "support",    // Isolates this cache from others
        similarity = 0.92         // Override default threshold if needed
    )
    public String answerQuestion(String question) {
        // This only executes on cache misses
        return openAiClient.complete(question);
    }
}

That’s genuinely all the code you need. When answerQuestion is called, the library intercepts the call, generates an embedding for the question, searches for similar cached entries, and either returns a cached response or proceeds to call your method and cache the result.

The namespace parameter creates logical separation between different caches. Your FAQ responses shouldn't interfere with your product recommendation cache, even if someone asks a similar-sounding question in both contexts.

Understanding What Happens Under the Hood

To use semantic caching effectively, it helps to understand the flow of operations.

When a query arrives, the library first generates a vector embedding. If you’re using OpenAI’s text-embedding-3-small model, this produces a 1536-dimensional vector — essentially a list of 1536 numbers that mathematically represent the meaning of your text. This embedding generation takes around 50-100ms and costs a fraction of a cent.

Next, the library searches the vector storage for similar embeddings. It uses cosine similarity, which measures the angle between two vectors. Identical vectors have a similarity of 1.0. Completely unrelated vectors approach 0.0. The search returns the most similar cached entry along with its similarity score.

If the similarity exceeds your threshold, you have a cache hit. The library returns the stored response, and your LLM API is never called. Total latency: typically under 10ms for in-memory storage, under 50ms for Redis or Elasticsearch.

If the similarity falls below your threshold (or no similar entries exist), you have a cache miss. Your method executes normally, calling the LLM API. Before returning, the library caches both the query embedding and the response for future use.

Choosing Your Storage Backend

The library supports three storage backends, each suited to different scenarios.

In-Memory Storage keeps everything in the JVM heap using a ConcurrentHashMap. It’s fast and requires no external infrastructure, making it perfect for development, testing, and small applications. The obvious limitation is that data disappears when your application restarts, and it doesn’t work across multiple application instances.

semantic-cache:
  storage:
    type: memory

Redis Storage uses Redis Stack’s vector search capabilities. It provides persistence, sub-millisecond latency, and works across distributed deployments. If you’re already running Redis, this is often the natural choice for production.

semantic-cache:
  storage:
    type: redis
    redis:
      host: localhost
      port: 6379

You’ll need Redis Stack (not plain Redis) because it includes the RediSearch module with vector similarity search. The easiest way to get started is with Docker:

docker run -d --name redis-stack -p 6379:6379 redis/redis-stack:latest

Elasticsearch Storage is designed for large-scale deployments. It handles millions of vectors efficiently and integrates well if you’re already using Elasticsearch for search or logging. The HNSW algorithm provides approximate nearest neighbor search that scales remarkably well.

semantic-cache:
  storage:
    type: elasticsearch
    elasticsearch:
      uris: http://localhost:9200

Choosing Your Embedding Provider

Vector quality matters. Better embeddings lead to more accurate similarity matching, which means higher cache hit rates and fewer false positives.

OpenAI provides excellent embeddings with minimal setup. The text-embedding-3-small model offers a good balance of quality and cost at $0.02 per million tokens. For applications where embedding quality is critical, text-embedding-3-large provides measurably better results at a higher price point.

Azure OpenAI offers the same models through Azure’s infrastructure, which matters for enterprises with compliance requirements or existing Azure investments.

Ollama lets you run embedding models locally. This eliminates embedding costs entirely and keeps all data on your infrastructure. The nomic-embed-text model produces good quality embeddings and runs efficiently on modest hardware.

semantic-cache:
  embedding:
    provider: ollama
    model: nomic-embed-text
    ollama-base-url: http://localhost:11434

ONNX goes a step further, running models directly in your JVM without any external service. This is ideal for offline deployments or when you want to minimize dependencies. The library includes several pre-trained models:

semantic-cache:
  embedding:
    provider: onnx
    onnx:
      pretrained-model: ALL_MINILM_L6_V2   # Fast and lightweight

The trade-off with local models is generally quality. OpenAI’s embeddings tend to outperform open-source alternatives, though the gap has been narrowing. For many applications, the cost savings of local embeddings outweigh the modest quality difference.

Multi-Tenant Caching

Real applications often serve multiple users or organizations, and you typically don’t want User A’s cached responses served to User B. The library handles this through context keys.

@SemanticCache(
    namespace = "support",
    similarity = 0.92,
    contextKeys = {"#userId"}    // Isolate cache by user
)
public String answerQuestion(String question, String userId) {
    return openAiClient.complete(question);
}

The contextKeys parameter accepts SpEL expressions that evaluate to isolation keys. The cache effectively becomes partitioned — a query from User A only matches cached entries from User A's previous queries.

You can combine multiple context keys for more complex isolation:

@SemanticCache(
    namespace = "support",
    contextKeys = {"#tenantId", "#department"}
)
public String answerQuestion(String question, String tenantId, String department) {
    return openAiClient.complete(question);
}

Cache Eviction

When underlying data changes, you need to invalidate cached responses. The @SemanticCacheEvict annotation handles this:

@SemanticCacheEvict(
    namespace = "faq",
    key = "#topic",
    similarity = 0.85    // Evict entries similar to this topic
)
public void updateFaqContent(String topic, String newContent) {
    faqRepository.update(topic, newContent);
}

This is particularly powerful because eviction is also semantic. Updating the “password reset” FAQ entry will evict cached responses for “reset password,” “forgot password,” and other similar queries — exactly the behavior you want.

For bulk updates, you can clear an entire namespace:

@SemanticCacheEvict(namespace = "faq", allEntries = true)
public void rebuildAllFaqs() {
    // Clears all cached FAQ responses
}

Using Without Spring Boot

While the library is optimized for Spring Boot, the core components work in any Java application:

// Create embedding provider
EmbeddingProvider embeddings = OpenAiEmbeddingFactory.create(apiKey);

// Create storage backend
VectorStorage storage = RedisVectorStorageFactory.create(
    "redis://localhost:6379", 
    1536    // Dimensions must match embedding model
);

// Build the cache
SemanticCache cache = SemanticCache.builder()
    .embeddingProvider(embeddings)
    .storage(storage)
    .config(CacheConfig.builder()
        .similarityThreshold(0.92)
        .ttl(Duration.ofHours(24))
        .build())
    .build();

// Use it directly
cache.put("How do I reset my password?", "To reset your password...");

Optional<CacheHit> hit = cache.get("I forgot my password");
if (hit.isPresent()) {
    System.out.println("Cache hit! Similarity: " + hit.get().similarity());
    System.out.println("Response: " + hit.get().response());
}

This programmatic API gives you full control and works with any framework or no framework at all.

Practical Tips for Production

Start with a higher similarity threshold and lower it gradually. A threshold of 0.95 is conservative it only matches very similar queries. Watch your hit rate, and if it’s too low, gradually reduce the threshold. It’s easier to recover from being too strict than from serving wrong answers.

Monitor false positives actively. Log cache hits along with the original cached query that matched. Review these periodically to ensure the matches make sense. One bad match that returns the wrong answer can erode user trust.

Use namespaces liberally. Different types of queries benefit from different thresholds. Technical support queries might need strict matching (0.95), while casual FAQ queries can be more lenient (0.85). Separate namespaces let you tune each category independently.

Consider embedding costs in your calculations. Every query generates an embedding, whether it hits the cache or not. With OpenAI’s small model, this is typically negligible ($0.02 per million tokens). But if you’re processing very high volumes, local ONNX embeddings might make more economic sense despite slightly lower quality.

Warm your cache during deployment. If you have a known set of common queries, pre-populate the cache during application startup. This ensures good cache hit rates from the first request.

Conclusion

Semantic caching represents a fundamental shift in how we think about caching for AI applications. By operating on meaning rather than text, it unlocks cache hit rates that traditional approaches simply cannot achieve.

Semantic LLM Cache brings this capability to the Java ecosystem with a clean, modular design that respects how Spring developers build applications. Whether you’re building chatbots, FAQ systems, RAG applications, or any other LLM-powered feature, semantic caching can meaningfully reduce your costs and improve response times.

The library is open source and available on GitHub. Contributions, feedback, and feature requests are always welcome.

GitHub: https://github.com/Jamalianpour/semantic-llm-cache

If you found this useful, consider giving the repository a star. It helps others discover the project and motivates continued development.

Recently I faced a problem with LLMs API costs in our company project. We were using GPT-5 for analyzing customer data, and the costs were becoming too high. After investigating, I found that the main issue was not our prompts — it was the JSON format we used for sending data.

I want to share my solution and the Spring Boot library I developed to solve this problem.

The Problem with JSON

When you send structured data to LLM APIs like OpenAI, every character counts as tokens. JSON format has many repeated elements. Look at this example:

{
  "interactions": [
    {"customerId": 1001, "type": "support", "duration": 342, "resolved": true, "satisfaction": 4.5},
    {"customerId": 1002, "type": "sales", "duration": 567, "resolved": false, "satisfaction": 3.2},
    {"customerId": 1003, "type": "support", "duration": 234, "resolved": true, "satisfaction": 4.8}
  ]
}

Each object repeats the same field names. When you have hundreds of records, this repetition wastes many tokens. In our case, we were sending this kind of data many times per day.

Discovering TOON Format

While researching optimization methods, I found TOON (Token-Oriented Object Notation). This format is designed specifically for reducing tokens when working with LLMs. Here is the same data in TOON:

interactions[3]{customerId,type,duration,resolved,satisfaction}:
  1001,support,342,true,4.5
  1002,sales,567,false,3.2
  1003,support,234,true,4.8

The difference is clear. Field names appear only once at the beginning. No quotes for simple values. No braces for each object. The structure is more like a table.

For 100 records, our tests showed:

• JSON format: approximately 4,500 tokens
• TOON format: approximately 2,400 tokens
• Reduction: 47%

This is significant cost saving when you process many requests.

TOON Spring Boot Library

GitHub - Jamalianpour/toon-spring-boot: A Spring Boot library for converting Java objects to TOON (Token-Oriented Object Notation) format

Our backend systems use Spring Boot framework. I needed to create a solution that integrates well with existing code. Manual conversion was not practical for production use.

I decided to build a library with these goals:

• Easy integration with Spring Boot
• Annotation-based configuration
• Automatic format detection
• Good performance for large datasets

<dependency>
    <groupId>io.github.jamalianpour</groupId>
    <artifactId>toon-spring-boot</artifactId>
    <version>0.1.0</version>
</dependency>

Here is the basic structure I implemented:

@ToonSerializable
public class InteractionRecord {
    @ToonField(order = 1)
    private Long customerId;
    
    @ToonField(order = 2)
    private String type;
    
    @ToonField(order = 3)
    private Integer duration;
    
    @ToonField(order = 4)
    private Boolean resolved;
    
    @ToonField(order = 5)
    private Double satisfaction;
    
    @ToonIgnore
    private String internalNotes;  // This field will not be included
}

The annotations provide control over the conversion process. The order attribute is important - it ensures consistent field ordering in the tabular output, which is necessary for the format to work correctly.

Technical Implementation Details

The converter has different strategies for different data types. When it encounters a collection of uniform objects (like database records), it automatically uses the tabular format. For mixed-type arrays, it uses a list format. For nested objects, it maintains the hierarchy with proper indentation.

The core conversion logic examines the data structure and chooses the optimal format:

@RestController
public class DataController {
    private final ToonConverterService toonService;
    
    @PostMapping("/convert")
    public String convertData(@RequestBody List<Record> records) {
        // The service automatically detects uniform structure
        String toonData = toonService.convert(records);
        
        // Now you can send this to LLM with fewer tokens
        return sendToLLM(toonData);
    }
}

To use the library in your Spring Boot application, you need to add the annotation:

@SpringBootApplication
@EnableToonConverter
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Integration with Existing Systems

The library is designed to work alongside existing JSON processing. You can gradually migrate endpoints:

@Service
public class DataService {
    public String processForLLM(List<Data> data) {
        // Convert only for LLM calls
        return toonService.convert(data);
    }
    
    public String processForAPI(List<Data> data) {
        // Keep JSON for other APIs
        return jsonMapper.writeValueAsString(data);
    }
}

This approach allows testing and gradual adoption without breaking existing functionality.

When to Use TOON

TOON is most effective for:

• Uniform data structures (records from database)
• Time-series data
• Log entries
• Any tabular data sent to LLMs

TOON might not be optimal for:

• Deeply nested irregular structures
• Data with high variation between objects
• Systems that don’t use token-based pricing
• Legacy systems that require JSON

Conclusion

After using this library in production for a while, the results are clear. Token usage decreased significantly, which directly reduced our API costs. The implementation was straightforward and didn’t require major changes to our codebase.

For developers working with LLMs and structured data, TOON format offers a practical optimization. The Spring Boot library makes adoption simple. You can start with one endpoint and expand usage based on results.

The key lesson from this project: when new technologies like LLMs introduce new cost models (paying per token), maybe we need to reconsider our data formats. TOON is one solution to this specific problem.

The library is open source and available on GitHub. Feel free to contribute or report issues.

#SpringBoot #Java #LLM #OpenAI #TOON #TokenOptimization #AIIntegration

As someone who has been working in software development and artificial intelligence for years, I can confidently say that AI has changed everything. I use AI for almost everything now: writing code, debugging, drafting documentation, researching new frameworks, even brainstorming architecture decisions. It’s an incredible assistant. The productivity gains aren’t just incremental; they’re revolutionary. AI is, without a doubt, one of the most powerful tools I’ve ever wielded.

And yet, I’m exhausted.

Not by the work, but by the everything else. A strange, low-grade fatigue has set in, and it’s tied directly to the tool I’ve come to rely on.

Yet something has been bothering me lately, a feeling that crystallizes every time I open Instagram, LinkedIn, or X. The endless stream of AI-generated content washes over me — perfectly polished posts with that distinctive ChatGPT cadence, AI-generated images with their telltale smoothness, articles that read like they were assembled rather than written. It’s not that any individual piece is necessarily bad. It’s the cumulative weight of it all, It’s like living in an endless stream of artificial creativity and it’s impressive at first, but after a while, it just wears me out. The platforms that were supposed to connect us with human creativity and insight have become showcases for what machines can produce at scale.

But this is just an annoyance. My real concern runs much deeper.

Computers and artificial intelligence have undeniably accelerated our lives. But in doing so, I think we’ve lost something essential: the ability to wait. Now, when everything is instant, waiting feels like failure.

For Example:

Let’s say you want to start a new project. You have an idea for a web app.

• The AI “Sprint” (1% to 50%): You feed the idea to an LLM. In an hour, it gives you the database schema, the API endpoints, the frontend component structure, and all the boilerplate code. You go from a blank folder to a 50% complete project in an afternoon. It’s a exhilarating rush.
• The Human “Grind” (50% to 60%): Now, you have to move from 50% to 60%. This part isn’t boilerplate. This is the hard stuff. It’s integrating that one tricky third-party API. It’s refactoring the AI’s naive logic to handle real-world edge cases. It’s the subtle, nuanced work that defines the actual product. This 10% jump might take you one to three days.
• The Reality (60% to 70%): This next 10% jump getting the authentication perfectly secure, optimizing the database queries, and refining the user experience might take another week.

The “1-to-50” sprint felt amazing. The “50-to-60” part feels not bad but The “60-to-70” grind feels awful. It feels slow, broken, and frustrating. Because AI has warped our perception of effort, the moment the work gets hard, we are conditioned to believe something is wrong. And here’s the trap, we’ve become so accustomed to that initial velocity, that intoxicating leap from one to fifty, that the normal pace of difficult work now feels unbearably slow.

So we abandon the project. We stop, convince ourselves it wasn’t the right idea anyway, and start something new. And the cycle repeats.

The Vicious Loop of Impatience

This is where the real danger lies. When you don’t know how to wait when you haven’t built the mental resilience for the grind you cannot learn new, hard things.

When we hits the 50% wall they get frustrated. The project suddenly feels “boring” or “too hard.”

So what do we do?

We abandon the project.

We leave it at 50% and jump to a new idea. We get that “1-to-50” rush all over again, feel like a genius for an hour, hit the 50% wall, and abandon it. Again.

This is a vicious loop. It’s a cycle of hollow victories followed by real failures. You end up with a hard drive full of 50%-finished projects and zero 100%-finished ones. You learn how to start, but you never learn how to finish.

In The End

I want to be clear: I’m not suggesting we abandon AI tools. That would be neither practical nor desirable. AI has genuinely improved our work and life in countless ways. But I am suggesting that we need to become more conscious and more intentional about what we’re trading away in exchange for speed. We need to teach ourselves and the next generation not just how to use these powerful tools, but when to step away from them. We need to cultivate the capacity to sit with difficulty, to find meaning in slow progress, to build the psychological resilience that comes from patient effort over time.

The irony is that AI was meant to free us from repetitive work so we could focus on meaningful challenges. But if we’re not careful, it will also free us from the patience that makes challenges meaningful in the first place.

Perhaps the most important skill in the age of AI isn’t learning to prompt effectively or to integrate the latest models into our workflow. Perhaps it’s learning when to deliberately slow down, when to struggle without assistance, when to choose the hard way because the difficulty itself is the point. Because at the end of the day, the goal isn’t to finish projects as quickly as possible. The goal is to become the kind of person who can finish difficult projects at all — and that transformation happens not in the sprint from one to fifty, but in the long, patient journey from fifty to one hundred.

#ArtificialIntelligence #HumanVsMachine #DigitalExhaustion #CreativityInCrisis #SlowProductivity #TechReflection #MindfulInnovation #AIAndHumanity #AuthenticCreativity #ModernLife

I’ve found myself working on several projects at once sometimes 4 or 5 different apps in a single week. Flutter has been a revelation for cross platform development. It has, however, one persistent irritation: the ever growing build folders that take up a lot of disk space.

If you’re anything like me, you’ve had that moment when your disk space warning goes off, and you find that your Flutter projects are the ones to blame, with not just one or two but several gigabytes of cached builds silently piling up over time. In this article, I’ll walk you through the steps of how I solved this problem for myself by creating what I think of as a simple but powerful Dart command-line tool that can automatically clean up Flutter projects in my various development directories.

The Problem: Flutter’s Hungry Build Folders

The build process of Flutter generates a significant number of intermediate files, compiled code, and assets in the build directory of each project. These files are essential during the development and build stages, but they can be safely cleaned up when not in active use.

The build directory for a single Flutter project can easily swell to hundreds of megabytes or even several gigabytes, especially when you’re building for multiple platforms. Working on several projects, of course, adds to this number even more. All told, we could be looking at significant disk space usage.

Flutter gives a simple opportunity to clean a project by offering the flutter clean command, which removes the build directory and frees up the occupied space.

Yet the need to clean projects becomes apparent when one has many projects scattered throughout their developer folders and attempts to navigate to each folder just to run the clean command.

The Solution: A Dart CLI Tool for Automated Cleaning

Jamalianpour/f_cleaner

To solve this problem efficiently, I created a Dart CLI application that:

1. Scans specified directories (recursively by default)
2. Identifies Flutter projects by detecting the presence of a pubspec.yaml file with Flutter dependencies
3. Calculates the size of each project’s build directory
4. Runs flutter clean on each identified project
5. Reports on the total space saved

This approach allows me to clean all my Flutter projects with a single command, saving both time and disk space.

Building the CLI Tool

Let’s walk through the key components of this solution. Our Dart CLI application consists of two main files: the main Dart code and a pubspec.yaml file for dependencies.

Setting Up the Project

First, I created a new Dart project with the necessary dependencies:

name: f_cleaner
description: A CLI tool to scan directories for Flutter projects and run 'flutter clean' to free up disk space.
version: 1.0.0

environment:
  sdk: '>=3.0.0 <4.0.0'

dependencies:
  args: ^2.6.0
  path: ^1.9.1

dev_dependencies:
  lints: ^2.1.0
  test: ^1.24.0

executables:
  f_cleaner: f_cleaner

The args package provides command-line argument parsing capabilities, while path helps with cross-platform path manipulation.

The Core Functionality

The main code is organized into several key functions:

1. Argument Parsing: Handling command-line options for directory selection, recursive scanning, and verbosity
2. Flutter Project Detection: Identifying valid Flutter projects
3. Directory Scanning: Recursively exploring directories
4. Size Calculation: Determining how much space will be freed
5. Running Flutter Clean: Executing the command and handling results

Here’s a simplified breakdown of the key logic:

Future<bool> _isFlutterProject(String dirPath) async {
  // Check for pubspec.yaml file
  final pubspecFile = File(path.join(dirPath, 'pubspec.yaml'));
  if (!await pubspecFile.exists()) {
    return false;
  }
  
  // Read pubspec.yaml and check for Flutter dependency
  try {
    final content = await pubspecFile.readAsString();
    return content.contains('flutter:') || content.contains('sdk: flutter');
  } catch (_) {
    return false;
  }
}

Future<int> _calculateDirectorySize(Directory dir) async {
  if (!await dir.exists()) {
    return 0;
  }
  
  int size = 0;
  try {
    await for (final entity in dir.list(recursive: true, followLinks: false)) {
      if (entity is File) {
        size += await entity.length();
      }
    }
  } catch (_) {
    // Ignore errors
  }
  
  return size;
}
Future<ProcessResult> _runFlutterClean(String projectDir, {required bool verbose}) async {
  if (verbose) {
    print('Running flutter clean in $projectDir');
  }
  
  return await Process.run(
    'flutter',
    ['clean'],
    workingDirectory: projectDir,
    runInShell: true,
  );
}

The main scanning function coordinates these operations and collects the results:

Future<CleanResults> scanAndCleanFlutterProjects(
  String rootDirPath, {
  required bool recursive,
  required bool verbose,
}) async {
  final rootDir = Directory(rootDirPath);
  if (!await rootDir.exists()) {
    throw Exception('Directory does not exist: $rootDirPath');
  }

  int projectsFound = 0;
  int projectsCleaned = 0;
  int spaceFreed = 0;
  final futures = <Future>[];
  
  await for (final entity in _listDirectories(rootDir, recursive: recursive)) {
    if (await _isFlutterProject(entity.path)) {
      projectsFound++;
      
      if (verbose) {
        print('Found Flutter project at: ${entity.path}');
      }
      
      final buildDir = Directory(path.join(entity.path, 'build'));
      final future = _calculateDirectorySize(buildDir).then((size) async {
        if (size > 0) {
          try {
            final result = await _runFlutterClean(entity.path, verbose: verbose);
            if (result.exitCode == 0) {
              projectsCleaned++;
              spaceFreed += size;
              print('✓ Cleaned: ${entity.path} (freed ${_formatSize(size)})');
            } else {
              print('✗ Failed to clean: ${entity.path}');
              if (verbose) {
                print('  Error: ${result.stderr}');
              }
            }
          } catch (e) {
            print('✗ Error cleaning: ${entity.path}');
            if (verbose) {
              print('  Error: $e');
            }
          }
        } else if (verbose) {
          print('• Skipped: ${entity.path} (no build directory or empty)');
        }
      });
      
      futures.add(future);
    }
  }
  
  await Future.wait(futures);
  
  return CleanResults(
    projectsFound: projectsFound,
    projectsCleaned: projectsCleaned,
    spaceFreed: spaceFreed,
  );
}

One key optimization in this design is the use of parallel processing with futures. Instead of cleaning each project sequentially, the tool launches multiple cleaning operations concurrently, making the process much faster, especially when dealing with many projects.

Using the Tool

With the CLI tool complete, usage is straightforward. After installation, it can be run with various options:

# Clean all Flutter projects in current directory and subdirectories
f_cleaner

# Clean Flutter projects in a specific directory
f_cleaner --dir=/path/to/your/flutter/projects

# Non-recursive scan (only check the specified directory)
f_cleaner --dir=/path/to/your/flutter/projects --no-recursive

# Dry run (scan and report but don't clean)
f_cleaner --dry-run

# Skip confirmation prompt
f_cleaner --no-confirm

# Show detailed output
f_cleaner --verbose

The tool provides a clear summary after execution:

Flutter Projects Cleaner 🧹
==========================
Scanning directory: /Users/username/development
Recursive scan: Yes

Found 3 Flutter project(s) with build directories:
- /Users/username/development/project1 (2.3 GB)
- /Users/username/development/project2 (1.8 GB)
- /Users/username/development/clients/project3 (3.2 GB)

Total space that can be freed: 7.3 GB
Do you want to proceed with cleaning these projects? [y/N]: y

✅ Cleaned: /Users/username/development/project1 (freed 2.3 GB)
✅ Cleaned: /Users/username/development/project2 (freed 1.8 GB)
✅ Cleaned: /Users/username/development/clients/project3 (freed 3.2 GB)
❌ Failed to clean: /Users/username/development/broken_project

Summary
-------
Flutter projects found: 4
Projects cleaned: 3
Approximate space freed: 7.3 GB
Time taken: 5 seconds

Benefits and Results

After implementing this tool in my workflow, I’ve experienced several benefits:

1. Significant space savings: Regularly recovering 10–20GB of disk space
2. Time efficiency: What used to take manual effort now happens automatically
3. Better organization: I no longer avoid cleaning projects due to the hassle
4. Development speed: Less time fighting with disk space warnings means more time coding

I’ve been running this tool as part of my weekly maintenance routine, and it has become an essential part of my Flutter development workflow.

Conclusion

As Flutter developers, we often focus on building great apps and overlook infrastructure improvements that can enhance our development experience. This simple CLI tool demonstrates how a small investment in automation can solve persistent annoyances and improve productivity.

The complete source code for this tool is available in the GitHub repository: f_cleane (feel free to contribute or customize it for your needs).

If you’re a Flutter developer managing multiple projects, I encourage you to try this approach or build your own version. The few minutes spent setting up automation will save hours of manual work and gigabytes of disk space in the long run.

Flutter Build Directories Are Eating Your SSD: Here’s How to Fight Back was originally published in Easy Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a developer, having the right set of tools can make a significant difference in productivity. DevUtils, DevToys, and Open Dev are three utility tools that aim to streamline your workflow by offering a wide range of functionalities in one place. But with several options available, which one should you choose?

In this post, we’ll objectively compare these three tools across various features to help you decide which one suits your development needs best.

Overview of the Tools

DevUtils

DevUtils is a macOS-exclusive utility designed for developers. It offers a variety of tools that integrate seamlessly with the macOS environment. With its clean and intuitive interface, DevUtils has become a favorite among macOS developers looking for a powerful and easy-to-use toolkit.

DevToys

DevToys is a free, open-source utility for Windows users. It’s often referred to as the “Swiss Army knife” for developers, providing a broad range of tools in a single, accessible application. DevToys is particularly appealing due to its simplicity and the wide array of functionalities it offers.

OpenDev

OpenDev is a newer entry, built with Flutter, making it available across multiple platforms — macOS, Windows, Linux, and Web. It combines many of the features found in DevUtils and DevToys while also introducing unique tools and a cross-platform approach. Open Dev is open-source, inviting contributions from the developer community.
Try It on web OpenDev

Feature Comparison

To help you evaluate these tools, here’s a side-by-side comparison of their features:

Key Insights

1. Platform Compatibility

• DevUtils is exclusively available on macOS, making it the ideal choice for developers deeply integrated into the Apple ecosystem.
• DevToys is designed specifically for Windows, offering a tailored experience for users within the Microsoft environment.
• Open Dev is the most versatile, with support for macOS, Windows, and Linux, catering to developers who work across multiple operating systems.

2. Unique Features

• SQL Formatter/Parser: DevToys offers a SQL formatter/parser, which can be a handy tool for developers working with databases.
• Cron Parser: Only Open Dev offers a cron parser, which can be particularly useful for developers dealing with cron jobs.
• README Helper: Open Dev also includes a README helper with a real-time viewer, which is a handy feature for developers working on documentation.
• Markdown to HTML Converter: Both DevUtils and DevToys provide a converter from Markdown to HTML, which is not currently available in Open Dev.

3. Core Utilities

• All three tools offer essential developer utilities such as JSON parsing, Unix time conversion, JWT debugging, and color conversion.
• DevToys stands out with additional tools like the SQL Formatter and String Utilities, while Open Dev brings unique features like the Cron Parser and Developer News.

Strengths and Weaknesses

DevUtils

Strengths:

• Seamless integration with macOS.
• Clean, intuitive interface.
• Powerful core utilities for everyday developer tasks.
• Includes tools like Markdown to HTML and HTML Formatter.

Weaknesses:

• Limited to macOS, which excludes users on other platforms.
• Lacks some additional tools like a cron parser or UUID generator.
• Need license (Start from 40$ to 80$)

DevToys

Strengths:

• Free and open-source.
• Wide range of tools in a single application.
• Simple and user-friendly interface for Windows users.
• Includes unique tools like SQL Formatter and String Utilities.

Weaknesses:

• Not stable on MacOS and Linux
• Lacks some unique features like a cron parser or README helper.

Open Dev

Strengths:

• Cross-platform support (macOS, Windows, Linux, web).
• Open-source with potential for community-driven development.
• Includes unique tools like the Cron Parser and README Helper.

Weaknesses:

• Newer to the market, so it may not have the same level of polish as DevUtils.
• Does not include some features available in other tools, like SQL formatting or Markdown to HTML conversion.

Conclusion

Each of these tools has its strengths, depending on your specific needs and the platform you use:

• DevUtils is perfect for macOS developers who want a highly polished, native experience.
• DevToys is ideal for Windows users looking for a free, comprehensive utility tool, especially with its SQL Formatter and other string utilities.
• Open Dev is a great option for developers who need a cross-platform toolset with some unique features not found in the other two.

Ultimately, the best choice depends on your operating system, the features you need, and your preference for open-source versus proprietary tools. Explore each tool to see which one fits your workflow the best.

Try Open Dev on GitHub, or check out DevUtils and DevToys to see how they can enhance your development environment.

A few months ago in one of my projects with flutter I need to show some reservations and tasks to user, I decided to show them on a calendar because it’s easy for user to review all of them quickly.

I start to googling but I can’t found any good package for this. Honestly I found one package but it didn’t allow you to customize that and change the date.

So I create my own time table for my project and use that on it, and now I decided to publish it as open-source and pub package, now you can use it for free.

time_planner | Flutter Package

This is a widget for show tasks to user on a time table.
Each row show an hour and each column show a day but you can change the title of column and show any things else you want.
This package will support flutter mobile 📱, desktop 🖥 and web 🌐

You can see and test web demo here: https://jamalianpour.github.io/time_planner_demo

Usage:

step 1: Add this dependence to pubspec.yaml file :

dependencies:
  time_planner: ^0.1.2+1

and then run flutter pub get to download needed dependencies.

step 2: Import time planner lib to your file:

import 'package:time_planner/time_planner.dart';

now you can use TimePlanner as a widget in your code.

step 3: Add TimePlanner under the a widget like scaffold or any other widget.

TimePlanner(
  // time will be start at this hour on table
  startHour: 6,
  // time will be end at this hour on table
  endHour: 24,
  // each header is a column and a day
  headers: [
    TimePlannerTitle(
      date: "3/10/2021",
      title: "sunday",
    ),
    TimePlannerTitle(
      date: "3/11/2021",
      title: "monday",
    ),
    TimePlannerTitle(
      date: "3/12/2021",
      title: "tuesday",
    ),
  ],
  // List of task will be show on the time planner
  tasks: tasks,
),

Time planner widget get 3 required arguments:

• startHour : Time will be start at this hour on table minimum value is 1.
• endHour : Time will be end at this hour on table maximum value is 24.
• headers : At first you should know each header is a column and each column is a day. headers is a list of TimePlannerTitle and this will get date and title as string.

Time planner widget get 3 optional arguments:

• tasks : List of TimePlannerTask that’s will be show on the time planner as tasks. for more detail about TimePlannerTask read below.
• currentTimeAnimation : when time planner widget loaded it will be scroll to current local hour and this feature is true by default.
• style : you can change style of time planner with TimePlannerStyle . for more detail about TimePlannerStyle read below.

Style:

You can customize the style of time planner with TimePlannerStyle:

style: TimePlannerStyle(
  backgroundColor: Colors.blueGrey[700],
  // default value for height is 80
  cellHeight: 60,
  // default value for width is 90
  cellWidth: 60,
  dividerColor: Colors.white,
  showScrollBar: true,
),

Tasks:

Now if you want to add task on time planner you need to use TimePlannerTask :

List<TimePlannerTask> tasks = [
  TimePlannerTask(
    // background color for task
    color: Colors.purple,
    // day: Index of header, hour: Task will be begin at this hour
    // minutes: Task will be begin at this minutes
    dateTime: TimePlannerDateTime(day: 0, hour: 14, minutes: 30),
    // Minutes duration of task
    minutesDuration: 90,
    // Days duration of task (use for multi days task)
    daysDuration: 1,
    onTap: () {},
    child: Text(
      'this is a task',
      style: TextStyle(color: Colors.grey[350], fontSize: 12),
    ),
  ),
];

Every task on time planner is clickable and you can set your own function on the task with onTap .

Full example:

Thanks for your attention and fill free to fork this repository and send pull request 🏁👍

• Jamalianpour/time_planner
• time_planner | Flutter Package