[GH-ISSUE #405] Add support for OpenAI Batch API

kerem commented

2026-03-03 13:52:49 +03:00

Owner

Originally created by @0xdevalias on GitHub (Apr 17, 2025).
Original GitHub issue: https://github.com/jehna/humanify/issues/405

The Batch API provides a 50% discount on token costs, and higher rate limits; with the downside being that the results aren't available straight away (could be up to 24hr delay).

I think for a lot of JS reversing use cases, these tradeoffs of cost/benefit would likely make enough sense to explore implementing.

https://platform.openai.com/docs/guides/batch
- While some uses of the OpenAI Platform require you to send synchronous requests, there are many cases where requests do not need an immediate response or rate limits prevent you from executing a large number of queries quickly. Batch processing jobs are often helpful in use cases like:
  - Running evaluations
  - Classifying large datasets
  - Embedding content repositories
  The Batch API offers a straightforward set of endpoints that allow you to collect a set of requests into a single file, kick off a batch processing job to execute these requests, query for the status of that batch while the underlying requests execute, and eventually retrieve the collected results when the batch is complete.
  
  Compared to using standard endpoints directly, Batch API has:
  - Better cost efficiency: 50% cost discount compared to synchronous APIs
  - Higher rate limits: Substantially more headroom compared to the synchronous APIs
  - Fast completion times: Each batch completes within 24 hours (and often more quickly)
https://platform.openai.com/docs/pricing

Originally created by @0xdevalias on GitHub (Apr 17, 2025). Original GitHub issue: https://github.com/jehna/humanify/issues/405 The Batch API provides a 50% discount on token costs, and higher rate limits; with the downside being that the results aren't available straight away (could be up to 24hr delay). I think for a lot of JS reversing use cases, these tradeoffs of cost/benefit would likely make enough sense to explore implementing. - https://platform.openai.com/docs/guides/batch - > While some uses of the OpenAI Platform require you to send synchronous requests, there are many cases where requests do not need an immediate response or [rate limits](https://platform.openai.com/docs/guides/rate-limits) prevent you from executing a large number of queries quickly. Batch processing jobs are often helpful in use cases like: > > - Running evaluations > - Classifying large datasets > - Embedding content repositories > > The Batch API offers a straightforward set of endpoints that allow you to collect a set of requests into a single file, kick off a batch processing job to execute these requests, query for the status of that batch while the underlying requests execute, and eventually retrieve the collected results when the batch is complete. > > Compared to using standard endpoints directly, Batch API has: > > - Better cost efficiency: 50% cost discount compared to synchronous APIs > - Higher rate limits: [Substantially more headroom](https://platform.openai.com/settings/organization/limits) compared to the synchronous APIs > - Fast completion times: Each batch completes within 24 hours (and often more quickly) - https://platform.openai.com/docs/pricing ## See Also - https://github.com/jehna/humanify/issues/406 - https://github.com/jehna/humanify/issues/2 - https://github.com/jehna/humanify/issues/84 - https://github.com/jehna/humanify/issues/167 - https://github.com/jehna/humanify/issues/174 This would potentially also have relevance to the stable renaming / resumability / etc issues; as I suspect there may be a need to export some kind of ‘status’ file that might contain a hash of the source file + extract of the scopes + identifier names or similar: - https://github.com/jehna/humanify/issues/97 - https://github.com/jehna/humanify/issues/129 - etc?

kerem commented

2026-03-03 13:52:49 +03:00

Author

Owner

@neoOpus commented on GitHub (Apr 17, 2025):

HumanifyJS has tremendous potential as a tool, and the foundation laid so far is commendable. However, there are opportunities to enhance its functionality and usability. Right now, it requires a lot of manual effort and maintenance, which can be challenging even for small projects.

To unlock its full potential, it would be exciting to explore a reworked version that focuses on reliability, automation, and seamless integration with development environments. Imagine a tool that could handle its own limitations, leverage AI for intelligent task management, and work effortlessly within the context of a project.

Some ideas for improvement could include:

Building AI-driven features to automate deobfuscation and monitoring, similar to what Manus does but specific to the reverse-engineering task.
Enhancing its ability to integrate smoothly with IDEs for a more streamlined experience.
Developing a project-aware system that adapts to the needs of each workflow, allowing refactoring of the code and making it possible to create something different out of it and keep updating it with minimal to no effort, while leveraging the state-of the art coding knowledge and development expertise, allowing to create better versions of what is already there (obfuscated or not).

With these enhancements, HumanifyJS could become an indispensable tool for developers. It’s a great opportunity for collaboration to bring this vision to life and create something truly impactful.

Let’s build on the existing foundation and take it to the next level!

@neoOpus commented on GitHub (Apr 17, 2025): HumanifyJS has tremendous potential as a tool, and the foundation laid so far is commendable. However, there are opportunities to enhance its functionality and usability. Right now, it requires a lot of manual effort and maintenance, which can be challenging even for small projects. To unlock its full potential, it would be exciting to explore a reworked version that focuses on reliability, automation, and seamless integration with development environments. Imagine a tool that could handle its own limitations, leverage AI for intelligent task management, and work effortlessly within the context of a project. Some ideas for improvement could include: - Building AI-driven features to automate deobfuscation and monitoring, similar to what Manus does but specific to the reverse-engineering task. - Enhancing its ability to integrate smoothly with IDEs for a more streamlined experience. - Developing a project-aware system that adapts to the needs of each workflow, allowing refactoring of the code and making it possible to create something different out of it and keep updating it with minimal to no effort, while leveraging the state-of the art coding knowledge and development expertise, allowing to create better versions of what is already there (obfuscated or not). With these enhancements, HumanifyJS could become an indispensable tool for developers. It’s a great opportunity for collaboration to bring this vision to life and create something truly impactful. Let’s build on the existing foundation and take it to the next level!

kerem commented

2026-03-03 13:52:49 +03:00

Author

Owner

@0xdevalias commented on GitHub (Apr 18, 2025):

@neoOpus From a quick skim through your comment, it seems like it might be better positioned in a new issue, since it sounds more 'standalone'; rather than on this one that is focussed on the OpenAI Batch API specifically.

My quick /2c is that while I agree there's a lot of potential within Humanify (or another tool like it), I think there is also a lot of benefit in knowing where to draw the boundaries around what a tool will/won't handle (eg. unix philosophy); while making it easier for other tools/projects to make use of it in the process (eg. the same way humanify builds upon webcrack).

Some of what you mention above sounds interesting to me, but some of it sounds like things I would personally probably never need/use; and at least at face value, feel like they may stray a bit from what I believe the core functionality of humanify probably is/should be.

But yeah.. probably better if you create a new issue with that comment and can discuss thoughts there more as appropriate.

@0xdevalias commented on GitHub (Apr 18, 2025): @neoOpus From a quick skim through your comment, it seems like it might be better positioned in a new issue, since it sounds more 'standalone'; rather than on this one that is focussed on the OpenAI Batch API specifically. My quick /2c is that while I agree there's a lot of potential within Humanify (or another tool like it), I think there is also a lot of benefit in knowing where to draw the boundaries around what a tool will/won't handle (eg. [unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy#Origin)); while making it easier for other tools/projects to make use of it in the process (eg. the same way `humanify` builds upon `webcrack`). Some of what you mention above sounds interesting to me, but some of it sounds like things I would personally probably never need/use; and at least at face value, feel like they may stray a bit from what I believe the core functionality of `humanify` probably is/should be. But yeah.. probably better if you create a new issue with that comment and can discuss thoughts there more as appropriate.

kerem commented

2026-03-03 13:52:49 +03:00

Author

Owner

@0xdevalias commented on GitHub (Apr 23, 2025):

probably better if you create a new issue with that comment and can discuss thoughts there more as appropriate

@neoOpus I made the following issue for it and copied your comments into it:

https://github.com/jehna/humanify/issues/414

@0xdevalias commented on GitHub (Apr 23, 2025): > probably better if you create a new issue with that comment and can discuss thoughts there more as appropriate @neoOpus I made the following issue for it and copied your comments into it: - https://github.com/jehna/humanify/issues/414

kerem commented

2026-03-03 13:52:50 +03:00

Author

Owner

@neoOpus commented on GitHub (Apr 23, 2025):

Thank you for your kindness @0xdevalias. I considered taking action yesterday, as you suggested, but I was too tired and unsure if it was within scope as you remarked. I'm now reorganizing to see if I can make it work, but if anyone else is confident, please don't hesitate to take the initiative.

I'm also open to collaboration and exploring product launch opportunities, given the significant potential. Friendship as well.

@neoOpus commented on GitHub (Apr 23, 2025): Thank you for your kindness @0xdevalias. I considered taking action yesterday, as you suggested, but I was too tired and unsure if it was within scope as you remarked. I'm now reorganizing to see if I can make it work, but if anyone else is confident, please don't hesitate to take the initiative. I'm also open to collaboration and exploring product launch opportunities, given the significant potential. Friendship as well.

kerem referenced this issue

2026-03-03 13:53:15 +03:00

[PR #76] [CLOSED] Bump @types/node from 22.5.1 to 22.5.2 #141

Rows
Columns

[GH-ISSUE #405] Add support for OpenAI Batch API #76

See Also