Unfortunately there's no way to do that except overriding the query builder methods yourself. Objection query builder is a superset of the knex query builder and simply calls the corresponding knex method for most of the query builder methods like where. That way, objection doesn't need to duplicate the knex API which would need to be tested and maintained. Knex doesn't have a hook system or a reflection API for doing things like this.

But you can override the objection query builder. Something like this:

class MyCustomQueryBuilder extends Model.QueryBuilder {
  where(...args) {
    if (args.length === 2 && args[0] === 'status') {
      args[1] = mapStatus(args[1])
    }
    return super.where(...args)
  }
}

class User extends Model {
  static get QueryBuilder() {
    return MyCustomQueryBuilder
  }
}

If you want to make this work in all situations, you need to override a bunch more *where methods, so this solution is not optimal.

This will change strings to integer so we will have more readable code and smaller (and faster) DB queries.

I would just define them as strings in the db too. I challenge you to show any proof that there is a significant performance difference. If comparing two numbers takes 0.1 nanoseconds, comparing small strings can take 0.5 nanosecond or something like that. You can still do billions of those in a second. Those comparisons will never ever be a bottleneck. If you have this kind of queries, you would use an index anyway, which will take down the amount of comparisons by orders of magnitude.

Also the space you save is couple of bytes per row. Even if you have billions of rows, it's some gigabytes. At that point your database will be terabytes anyway, so it wouldn't really matter.