Adding a Token Usage Feature to a Partner’s Project

Hey everyone! 👋

Today, I want to share an interesting experience I had while working on Lab 2. My mission? To contribute a brand-new feature to Scrappy project. I decided to dive into one of the Lab 1 submissions and add something I found super useful: a Token Usage feature. If you’re working with Large Language Models (LLMs) like OpenAI’s GPT, you know how important it is to keep an eye on token usage. Let me walk you through why I thought this was a great addition, how I implemented it, and the unexpected twist that came with it.

Implementing the Feature

Step 1: Adding the Command-Line Flag

First things first, I introduced a new command-line flag: --token-usage (or simply -t for short). When users include this flag, the program will show:

Prompt tokens: How many tokens are in the input prompt.
Completion tokens: How many tokens the model used in its response.
Total tokens: The sum of prompt and completion tokens.

Step 2: Capturing Token Data

Next, I tweaked the program to grab the token usage data from the API’s response. This involved parsing the response to extract the token counts and then storing that information for later display.

Step 3: Displaying Token Usage

With the data in hand, I made sure that when the --token-usage flag is active, the program prints out the token details in a user-friendly format. Here’s what it looks like:

Token Usage:
Prompt tokens: 57
Completion tokens: 17
Total tokens: 74

Pretty straightforward, right?

This gives users immediate feedback on their token usage, helping them keep track of costs and stay within the model’s limits.

A Twist: Someone Beat Me to It!

Just when I thought I was all set to submit my pull request, I hit a bit of a snag. Turns out, someone else had already implemented the exact same feature and got their pull request merged into the repository before I could push mine. 😅

My Initial Reaction

At first, I was a bit bummed. It’s never fun to put time into something only to find out it’s already been done. But then I reminded myself that this is all part of the open-source game—sometimes, multiple people are working on similar ideas simultaneously.

Turning Frustration into Learning

Instead of getting discouraged, I decided to take this as a valuable learning experience. Here’s what I realized:

1. Communication is Key

Before diving deep into coding, I should’ve reached out to the project owner or checked the existing pull requests to see if anyone else was working on the same feature. A quick message could have saved me a lot of time and effort.

2. Open Source Etiquette

Filing an issue before starting work is a great way to signal your intentions to the community. This helps prevent duplication and keeps everyone on the same page. From now on, I’ll make it a habit to claim issues early on.

3. Collaboration Opportunities

If I ever find myself in a similar situation again, I might reach out to the other contributor. Who knows? We could team up and build something even better together!

Lessons Learned

This whole experience was a great reminder that contributing to open-source projects is about more than just coding. Here are some key takeaways:

Proactive Communication: Engage with project maintainers and check for ongoing work to avoid redundant efforts.
Community Engagement: Open-source is all about collaboration. Being an active part of the community can enhance your contributions.

Moving Forward

Even though my specific contribution didn’t get merged, I still gained a lot from the process. I learned how to integrate new features into an existing codebase, maintain the original coding style, and ensure that my changes didn’t introduce any bugs.

ccp lab2