DEV Community: Medard Mandane

It's been while since my last article, hope this helps

Medard Mandane — Thu, 11 Jun 2026 11:46:43 +0000

Medard Mandane

Jun 11

How to save tokens/usage on your Coding Sessions (Claude, etc)

#claude #ai #agents #tokens

2 min read

How to save tokens/usage on your Coding Sessions (Claude, etc)

Medard Mandane — Thu, 11 Jun 2026 11:46:07 +0000

Saving Tokens/Usage especially on your coding sessions

Someone probably covered Most or all of this, I just learn OTG. So no hate pls. I will update this when I learn more strategies and when I have time

The Problem

Many of us are working on multiple projects, using shared accounts or maybe can't afford the MAX plans, so reaching the limits is really a pain in the ass that affects our momentum and productivity.

Possible Solutions that I tried myself

1. Install the following Skills

https://github.com/JuliusBrussee/caveman
- ask claude to install, and after installation /caveman
https://github.com/rtk-ai/rtk
just read the docs please on what their purpose are, these will basically reduce your token usage by a lot

2. Provide initial Context

Point agent to a file or list of files related to the task as starting context. If you just ask them to build a feature, they will extract information from your query and do bunch of terminal commands to find the right files to work on.

3. Create New Chat

Once you are done working on a specific tasks, switch to a new chat for the others. Since you will be passing unecessary context if you stay in the current chat

4. Compact/Compress context

if in a single chat, you talked about many rules or specific instructions on how the agent should work or behave, or you are working on features that are tightly related to each other and that switching to new chat might not be the best solution. It's better to compact the chat before you start working on the next task every time. This saves tons of tokens
for claude we use /compact to summarize and reduce the context of the current chat

5. Plan -> Compact -> Implement

If you plan first, aside from saving tokens, the implementation is smoother. Since if you just ask the agent to implement a feature, it will do a mix of planning and implementation, a lot of thinking and realizing this is wrong and that is right. So it wastes a lot of tokens
When the plan is created, compact the context, then proceed with implementation.

6. Plan -> Implement in new Chat

This might be the most token saving approach, since after you create a plan and implement in a new chat, the only context the new chat has is the plan, and it doesn't need to figure out which files to update or do heavy searching of context since we already have a guide.

I personally do a mix and match of these methods, like I usually just compact if the tasks are continuous but not complex or big. And do Plan -> Implement Approach for big changes. It all depends.

Anyway Good luck and thank you for taking your time to read this

Splitting Wasp TS Config?

Medard Mandane — Fri, 17 Jan 2025 19:55:04 +0000

Splitting Wasp TS Config, Can we do it? (Updated)

Overview

The early support for TS config of Wasp was introduced in v0.15. It's been out for a while. Some of the goals were to support multiple Wasp files, take advantage of built-in TypeScript support for most editors, and lessen the burden of maintaining the codebase. Unfortunately, at the moment, splitting or using multiple Wasp files is a feature we can anticipate in future updates.

However, there is a way we can reduce the lines of code in the wasp file

Part 1: Extracting the pages from `main.wasp.ts` in 2 steps

One of the ways we can reduce the code in main.wasp.ts is by moving the pages to a different file and exporting it from there. (Can I call this Factory Pattern?)

Step 1: Move the page constants in a file, I'll call it `pages.config.ts`. Then return.

// pages.config.ts
import { App } from 'wasp-config'

export const pagesConfig = (app: App) => {
  const landingPage = app.page('LandingPage', {
    component: { importDefault: 'LandingPage', from: '@src/landing-page/LandingPage' }
  });
  // other pages

  return {
    landingPage,
    // other pages
  }
}

** I suggest you also nest the file inside a dedicated directory, maybe name it wasp-config

Step 2: Import the pages in `main.wasp.ts`, pass the app instance to `pagesConfig`

// main.wasp.ts

import { pagesConfig } from './pages.config.ts'
// other code

const { 
  landingPage,
  // other pages
} from pagesConfig(app)

app.route('LandingPageRoute', { path: '/', to: landingPage });

Part 2: Extracting jobs, query, actions and other configs

Step 1: Move the config to a variable in a new file, let's call it `jobs.config.ts`. I will give an example for jobs, but the same applies for queries or actions.

// jobs.config.ts

// import the appropriate type to avoid ts errors
import { App, JobConfig } from "wasp-config";

export const jobConfigs = (app: App) => {
  const dailyStatsJobConfig: JobConfig = {
    executor: 'PgBoss',
      perform: {
      fn: { import: 'calculateDailyStats', from: '@src/analytics/stats' }
    },
    entities: ['User', 'DailyStats', 'Logs', 'PageViewSource']
  }

  return {
    dailyStatsJobConfig
  }
}

Step 2: Import and use the config in `main.wasp.ts`, same with what we did for pages

// main.wasp.ts

import { jobConfigs } from './jobs.config.ts'
// other code

const { 
  dailyStatsJobConfig,
} from jobConfigs(app)

app.job('dailyStatsJob', dailyStatsJobConfig);

Wrap Up

By doing all these extractions, we can significantly reduce the code and somehow organize main.wasp.ts while we wait for the official support for multiple wasp files.

** Please let me know if you have questions or if you found a better solution.

Oh Wait, THERE IS ANOTHER WAY (Update)

Okay, so while working more on the organizing my wasp file I found another way to reduce and organize the code.

Extracting pages, actions -- everything

a more organized `main.wasp.ts`

Lets first take a look at my main.wasp.ts

import { initApp } from './wasp-config/core.wasp.js'
import { initRoutes } from './wasp-config/routes.wasp.js'
import { initActions } from './wasp-config/actions.wasp.js'
import { initJobs } from './wasp-config/jobs.wasp.js'

// Configure the app here
const app = initApp(
  'OpenSaaS App',
  {
    title: 'OpenSaaS App',
    wasp: { version: '^0.15.0' },
    head: [
      "<meta charset='utf-8' />",
      "<meta name='description' content='Your apps main description and features.' />",
      "<meta name='author' content='OpenSaaS App' />"
      // other meta tags
    ],
  }
);
initRoutes(app);
initActions(app);
initJobs(app);

export default app;

That's just a few lines of and you can immediately tell what's happening here. By organizing it this way, we can work on each section separately. It is also beneficial for devs new to Wasp-lang. This is easier to digest (my personal opinion)

Diving into each section

Below is how I coded each section of the main.wasp.ts. I decided to separate the configs from the declarations because I want to see the list of pages, actions etc clearly

A look at my`core.wasp.ts`

import { App, AppConfig, AuthConfig, ClientConfig, DbConfig, EmailSenderConfig } from 'wasp-config'

export const initApp = (appName: string, appConfig: AppConfig): App => {
  const app = new App(appName, appConfig);
  const { authConfig, dbConfig, clientConfig, emailSenderConfig } = config();
  app.auth(authConfig);
  app.db(dbConfig);
  app.client(clientConfig);
  app.emailSender(emailSenderConfig); 
  return app
}
const config = () => {
  const authConfig: AuthConfig = {
    userEntity: 'User',
    // other auth config
  }
  const dbConfig: DbConfig = {
    // db config
  }
  const clientConfig: ClientConfig = {
    // client config
  }
  const emailSenderConfig: EmailSenderConfig = {
    provider: 'SMTP',
    // email sender config
  }
  return { authConfig, dbConfig, clientConfig, emailSenderConfig }
}

** I will just show how I coded the core config. Anyway, I used the same pattern for other sections.

If you want to see a full example using OpenSaaS template please check this gist https://gist.github.com/medardm/263b2c933186eb1a496fa743c756edc7

🐝 ✉️ MailHog & Wasp: Testing Emails Locally

Medard Mandane — Fri, 26 Jul 2024 21:53:17 +0000

What is Wasp

I'll assume you already know Wasp, it's basically a Full-Stack framework similar to Laravel but for Javascript. If you don't know anything about it yet, then I guess this is a sign that you should start exploring now.

For more information, please check their website -> Wasp-lang. Please read about OpenSaaS as well.

What is MailHog

Mailhog is an open source email testing tool that works locally. That only means you don't need internet to test emails.
To install MailHog, please check their GitHub repository for more info

How to use MailHog in Wasp

Step 1: In `main.wasp` file

set the email sender provider to SMTP

// main.wasp file
emailSender: {
...
  provider: SMTP
...
}

Step 2: Update `.env.server`

To use MailHog, simply set the SMTP configuration with the following values:

SMTP_HOST=localhost
SMTP_PORT=1025
SMTP_USERNAME=mailhog
SMTP_PASSWORD=mailhog

Usually you don't need to set the SMTP_USERNAME and SMTP_PASSWORD, however this won't work as Wasp uses nodemailer and the secured option is set to true by default if not specified.
- Currently, there's no way to override that option. This works because I also don't know, maybe it's related to encryption or some restriction of nodemailer. Maybe you can help me explain it more 😁

Step 3: Testing

Open the web interface of MailHog, this is where you will receive all the emails sent through Wasp, you can access it @ localhost:8025 or 0.0.0.0:8025
Try sending an email, if you are using the OpenSaaS template, you can simply try reset password.

You should receive the email

If these instructions doesn't work and you found a working solution, please let me know :) I only tested this on a mac machine

DEV Community: Medard Mandane

It's been while since my last article, hope this helps

How to save tokens/usage on your Coding Sessions (Claude, etc)

How to save tokens/usage on your Coding Sessions (Claude, etc)

Saving Tokens/Usage especially on your coding sessions

The Problem

Possible Solutions that I tried myself

1. Install the following Skills

2. Provide initial Context

3. Create New Chat

4. Compact/Compress context

5. Plan -> Compact -> Implement

6. Plan -> Implement in new Chat

Splitting Wasp TS Config?

Splitting Wasp TS Config, Can we do it? (Updated)

Overview

Part 1: Extracting the pages from main.wasp.ts in 2 steps

Step 1: Move the page constants in a file, I'll call it pages.config.ts. Then return.

Step 2: Import the pages in main.wasp.ts, pass the app instance to pagesConfig

Part 2: Extracting jobs, query, actions and other configs

Step 1: Move the config to a variable in a new file, let's call it jobs.config.ts. I will give an example for jobs, but the same applies for queries or actions.

Step 2: Import and use the config in main.wasp.ts, same with what we did for pages

Wrap Up

Oh Wait, THERE IS ANOTHER WAY (Update)

Extracting pages, actions -- everything

a more organized main.wasp.ts

Diving into each section

A look at mycore.wasp.ts

🐝 ✉️ MailHog & Wasp: Testing Emails Locally

What is Wasp

What is MailHog

How to use MailHog in Wasp

Step 1: In main.wasp file

Step 2: Update .env.server

Step 3: Testing

Part 1: Extracting the pages from `main.wasp.ts` in 2 steps

Step 1: Move the page constants in a file, I'll call it `pages.config.ts`. Then return.

Step 2: Import the pages in `main.wasp.ts`, pass the app instance to `pagesConfig`

Step 1: Move the config to a variable in a new file, let's call it `jobs.config.ts`. I will give an example for jobs, but the same applies for queries or actions.

Step 2: Import and use the config in `main.wasp.ts`, same with what we did for pages

a more organized `main.wasp.ts`

A look at my`core.wasp.ts`

Step 1: In `main.wasp` file

Step 2: Update `.env.server`