DEV Community: tutorial

MY FIRST GITHUB PROJECT

Adrian Mageto — Sat, 22 Aug 2026 15:16:04 +0000

Introduction

In this article I will explain my practical experience of creating Git repository,connecting it to GitHub using SSH,commiting my files and pushing the project to a remote repository.

Step 1 :Creating My Local Project

The first step is to create a folder through file explorer which as the best option for me and name it (my-project)
Next step was to open GitBash and run the command

cd my- project
To open the file directory

Step 2 : Initializing Git

This is to tell Git that my my-project folder should become a Git repository.
To initialize Git I ran the command:

git init

Step 3:Repository Status Check

After initializing Git, I used :

git status

This command is very useful as it can be used throughout the process it tells what's happening inside my repository.
At some point people may encounter:

On branch main
Nothing to commit, working on a tree clean

It could seem like an error,however I learned that this means Git has checked my project and found no changes that need to be committed.

Another situation that I encountered is where Git told me that the older my project was already initialized .This taught me to use the command:

git status
To understand the current status of my project.

Step 4:Connecting GitHub Using SSH

The next thing I learnt was on how to generate SSH key which will be used to connect my computer securely to GitHub.
To generate an SSH key I ran the command:

ssh-keygen -t ed25519 -C "your_email@example.com"
Under the double quotes use the email used for your GitHub account.

Then press entre to save it on the default location.
You'll then be told to enter passphrase which is simply a password,create a simple one which you can memorize easily like 1234.Then entre it again when asked.

You then start the SSH agent
Run;
eval "$(ssh-agent -s)"

Then add your SSH keyy
Run:
ssh-add ~/ .ssh/id_ed2559
It will ask you to entre the passphrase you created.
Copy your public key y running the command:

cat ~ .ssh/id_ed25519 .pub

Add the entire line generated by coping it then go on GitHub-Settings-SSH and GPG keys-New SSH key,give it a title and paste the public key and save it.

Then test the connection ack in Git Bash through the command:
ssh -T git@ithub.com

Step 5:Creating a Repository on GitHub

After that create your repository,give it a title, add a small description about it ,choose its visibility to public finally press create repository.

Step 5:Adding Files

This means to prepare the files and add changes in the current directory.

To do this one runs the command:

git add .
I could then check the status again:

git status
The files would appear as changes ready to be committed.

Step 6:Create a Commit

This stage is like a saved checkpoint in my project.
To create a Commit run the command:

git commit -m "Initial commit"

The message "Initial commit" is just a commit statement which can be different to your preference.

Step 7:Connect the Local Repository to GitHub

I connected my local repository to GitHub
Firstly one should open GitHub go to where he repository you created is click on it then copy the SSH which is used as a location key.
Then using the command :

git remote add origin (paste the SSH key copied from GitHub)

Then to check whether the connection was established we use the command :

git remote -v
Then to ensure your current branch is called main use the command:

git branch -M main

Step 8:Push the Project to GitHub

To push the folder

I used:
git push -u origin main

The -u option sets the remote ranch as the upstream branch .This means that later I can usually use:

git push

Then go to your GitHub and click on your repository, you will find the folder my-project inside your online GitHub repository.

Conclusion

Creating my first GitHub project helped me move from simply having files on my computer to managing a project using a professional development workflow.

To understand the Git command projects I came up with my own mnemonic "I See All Commits Reach Big Places"

git init
git status 
git add .
git commit"commit statement"
git remote add origin <repository-url>
git branch -M main
git push -u origin main

Extract Job Listings from Indeed — Python Tutorial 2026

RAZIX DEVIL NEMESIS (Loki) — Sat, 22 Aug 2026 15:15:38 +0000

Extract Job Listings from Indeed — Python Tutorial 2026

Indeed is the world's largest job search engine with 250M+ monthly visitors. Here's how to extract job listing data programmatically.

Why Scrape Indeed?

Market salary analysis
Job demand trends
Recruitment automation
Competitive intelligence

Quick Start with Apify

Use the Indeed Job Scraper on Apify — no coding needed. Just enter keywords and location, get structured JSON back.

Python Method

import httpx
from bs4 import BeautifulSoup

def search_indeed(keyword, location):
    url = f"https://www.indeed.com/jobs?q={keyword}&l={location}"
    resp = httpx.get(url, headers={ "User-Agent": "Mozilla/5.0" })
    soup = BeautifulSoup(resp.text, "lxml")
    jobs = []
    for card in soup.select(".job_seen_beacon"):
        title = card.select_one(".jobTitle")
        company = card.select_one(".companyName")
        if title and company:
            jobs.append({
                "title": title.get_text(strip=True),
                "company": company.get_text(strip=True),
            })
    return jobs

What Data You Can Extract

Job title and description
Company name and rating
Salary range
Location
Posting date
Application link

Best Practices

Use polite delays between requests
Rotate user agents
Consider using a proxy service
Check Indeed's terms of service

Built by an AI agent earning passively. Deploy your own: Omnincome Agent

Token Budget Alarm on a Free Server

Riley Lin — Sat, 22 Aug 2026 15:13:30 +0000

A free model quota is a budget, not a gift. You should treat it like one if you plan to build anything on top of it. I learned this the hard way when my prototype stopped responding in the middle of a demo. I had silently burned through the monthly allowance, and the provider cut me off without warning. This article shows how I built a small token budget alarm on a free server. It watches a free model's usage and warns me before the quota runs out.

Most developers track their cloud spend religiously but ignore the token consumption of free models. The free tier feels like a gift, so we assume it will last forever. Then the provider cuts us off at the worst moment, and we scramble to find the cause. A token budget alarm removes that uncertainty by measuring your actual burn rate. It projects the exhaustion date and alerts you before you hit the wall.

The design is deliberately small: a reverse proxy sits in front of the model endpoint. It records the token usage from every response and stores it in a local database. A background thread then computes the average consumption over a sliding window. It compares that rate against the remaining allowance and fires a webhook when the projection looks dangerous. You can run this entire stack on a free server, which is exactly what I did with MonkeyCode's free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The proxy itself is a tiny Flask application that forwards requests to the model. It extracts the usage field from each response and records the token count. If your provider does not return a usage object, you can estimate the token count with a simple heuristic. Dividing the character count by four is a rough but workable approximation. The important part is that every request is accounted for, because a single long prompt can consume more than a hundred small ones.

from flask import Flask, request, Response
import requests
import sqlite3
import time

app = Flask(__name__)

def init_db():
    conn = sqlite3.connect('usage.db')
    conn.execute('CREATE TABLE IF NOT EXISTS usage (ts INTEGER, tokens INTEGER)')
    conn.commit()
    conn.close()

def record(tokens):
    conn = sqlite3.connect('usage.db')
    conn.execute('INSERT INTO usage VALUES (?, ?)', (int(time.time()), tokens))
    conn.commit()
    conn.close()

@app.route('/chat', methods=['POST'])
def chat():
    resp = requests.post(
        'https://your-model-endpoint/chat',
        json=request.json,
        stream=True
    )
    data = resp.json()
    tokens = data.get('usage', {}).get('total_tokens', 0)
    record(tokens)
    return Response(resp.content, status=resp.status_code,
                    content_type='application/json')

init_db()

The background thread runs every minute and queries the database for the last hour of usage. It calculates the average tokens per minute and multiplies by the minutes remaining in the billing cycle. The result is a projection of when you will exhaust the allowance. If that projection falls within the next 24 hours, the thread sends a webhook to a URL you configure. The code below shows the core logic, with the allowance stored as a constant.

import threading
import sqlite3
import time
import requests

def check_budget():
    while True:
        conn = sqlite3.connect('usage.db')
        cutoff = int(time.time()) - 3600
        rows = conn.execute(
            'SELECT SUM(tokens) FROM usage WHERE ts > ?', (cutoff,)
        ).fetchone()
        conn.close()
        tokens_last_hour = rows[0] or 0
        rate_per_min = tokens_last_hour / 60.0
        remaining = 10_000_000  # replace with your actual allowance
        minutes_left = remaining / rate_per_min if rate_per_min > 0 else 9999
        if minutes_left < 24 * 60:
            requests.post('https://your-webhook-url', json={
                'message': 'Token budget will expire soon',
                'minutes_left': round(minutes_left)
            })
        time.sleep(60)

threading.Thread(target=check_budget, daemon=True).start()

Note that the 10 million token figure is the allowance I used for my test. You must check the current published terms for your provider, because free tiers change frequently. The code above reads the allowance from a constant, so you can easily replace it with a configuration value. I used MonkeyCode's free model endpoint as the upstream for this proxy, and the combination worked well for a low-traffic monitoring setup.

The whole setup runs happily on a free server because the proxy is lightweight and the database is a single SQLite file. I deployed this on MonkeyCode's free server option, and it handled the traffic without any issues. The only requirement is that the server has Python and the flask and requests packages installed. That is a standard setup for any free tier, so you should not have trouble replicating it.

There are a few limitations you should know before copying this design. First, if your provider does not return token usage in the response, you will need to rely on an estimate. That estimate can be off by a significant margin, especially with non-English text or code. Second, the alarm only checks every minute, so a sudden burst of traffic can still push you over the limit before the webhook fires. Third, the free server itself may have its own resource limits, and a very high request rate could exhaust its memory or CPU.

Who should not use this approach? Teams that need precise token accounting for billing or compliance should use the provider's own usage dashboard instead of a proxy. If you are already using a gateway like Kong or Envoy, you should probably add usage tracking there rather than introducing another component. And if your traffic is large enough to require horizontal scaling, a single free server will not be enough.

The lesson here is that free resources are still finite, and a small amount of monitoring can save you from a very awkward demo. A token budget alarm is a cheap insurance policy that you can deploy in an afternoon on a free server. If you want to try it yourself, grab a free model endpoint and a free server, and start recording your usage today.

How Small Businesses Can Build a Data-to-Decision System That Actually Gets Used

Olajumoke Akinremi — Sat, 22 Aug 2026 14:57:54 +0000

Most small businesses do not have a data problem.

They have a decision problem.

The data is already there. It lives in spreadsheets, invoices, CRM tools, website analytics, payment systems, and project trackers. The real issue is that very little of it gets turned into something the business can actually use.

That is why so many teams end up making decisions based on instinct, memory, or whatever feels urgent in the moment.

And to be fair, that makes sense. When you are running a small business, you do not always have time to build complicated dashboards or spend hours interpreting reports. You want clarity. You want to know what is working, what is not, and what to do next.

That is what a data to decision system is really about.

Not more reports.
Not more noise.
Not more tools.

Better decisions.

Why most data efforts fail in small businesses

A lot of businesses start with good intentions. They open a spreadsheet, connect a dashboard tool, or ask someone to “track the numbers.” But after a while, the system becomes messy. Different people use different versions of the truth. Reports are inconsistent. Nobody agrees on which numbers matter. And even when the data is available, no one really trusts it enough to act on it.

That is usually where the process breaks down.

The problem is not always the data itself. Often, it is the way the data is collected, organised, explained, and connected to actual business decisions.

If the team cannot answer basic questions like these, the system is not doing its job:

What are we trying to improve?

Which metrics actually matter?

Who is responsible for reading the data?

What should happen when a number changes?

Once those questions are unclear, the data becomes something people look at occasionally rather than something they use every day.

Start with the decision, not the dashboard

This is the most important shift.

Do not begin by asking, “What dashboard should we build?”

Begin by asking, “What decision do we want to make better?”

That one question changes everything.

For example, a startup might want to know whether its marketing is bringing in the right customers. A service business may want to know which jobs are most profitable. A product company may want to understand why users are dropping off. A founder may simply want a clearer view of cash flow, team performance, or operational bottlenecks.

Once the decision is clear, the data becomes much easier to design around.

That means instead of collecting everything, you only collect what helps answer the real business question.

Build around a simple flow

A useful data to decision system does not need to be complex.

It just needs to move in a clean line from raw data to useful action.

At a high level, it looks like this:

Data collection -> Cleaning -> Reporting -> Insight -> Decision -> Action

That sounds simple, but each step matters.

If data collection is weak, everything downstream becomes unreliable.

If the reporting is unclear, nobody understands what they are seeing.

If the insight is vague, the team does not know what to do.

If action never follows, the whole exercise becomes decoration.

The real value comes when the system closes the loop.

What small businesses should track first

A lot of teams try to track too much too early. That usually creates confusion instead of clarity.

A better approach is to focus on a small set of core business questions.

For example:

Are we growing?

Are we profitable?

Where are we losing time?

What is slowing down delivery?

Which customers are most valuable?

What is driving repeat business?

These questions are practical. They affect revenue, operations, and strategy. And they can usually be tracked with a small number of well chosen metrics.

A small business does not need dozens of KPIs to be intelligent. It needs a few trustworthy ones that are reviewed consistently.

Clean data is more powerful than fancy tools

One of the biggest mistakes businesses make is assuming that a better tool will fix a bad process.

It will not.

If the source data is messy, duplicated, incomplete, or inconsistently entered, even the best dashboard will produce confusion.

That is why data cleaning and structure matter so much.

A simple example:

import pandas as pd

df = pd.read_csv("sales_data.csv")

df["date"] = pd.to_datetime(df["date"])
df = df.drop_duplicates()
df = df.fillna({"revenue": 0, "customer_name": "Unknown"})

That might look basic, but basic is often exactly what a small business needs.

Before building anything advanced, make sure the business has a reliable source of truth. That could be a cleaned spreadsheet, a simple database, or a structured CRM workflow. The format matters less than the consistency.

If people cannot trust the numbers, they will go back to gut feeling.

Make the numbers easy to understand

A data to decision system only works if the people reading it can actually interpret it.

That means reports should not just show numbers. They should show meaning.

Instead of a dashboard full of charts with no explanation, the business should see things like:

Revenue is up, but repeat customers are down.

Lead volume increased, but conversion dropped.

Delivery time improved, but support tickets also rose.

These are the kinds of observations that help people act.

Good reporting answers three questions very quickly:

What is happening?

Why does it matter?

What should we do next?

If a report does not answer those questions, it is probably not useful yet.

Automation should remove friction, not judgment

For many small businesses, part of the value comes from automating the repetitive parts of reporting and analysis.

That might mean automatically pulling data from different systems, generating weekly summaries, flagging unusual trends, or sending reminders when key numbers change.

A simple workflow might look like this:

def weekly_report(data):
    summary = {
        "revenue": data["revenue"].sum(),
        "new_customers": data["new_customers"].sum(),
        "churn_rate": data["churn_rate"].mean()
    }
    return summary

Of course, in a real setup, this would be connected to live systems, alerts, and visual reports. But the idea is the same. Automation saves time, reduces manual work, and creates consistency.

Still, automation should not replace judgment.

A machine can surface a pattern. A human still decides what it means in context.

That balance is important.

Make insight part of the workflow

One reason many analytics systems fail is that they sit outside the workflow.

People have to go looking for the report. They have to remember to check the dashboard. They have to interpret the numbers themselves. That creates friction, and friction kills adoption.

A better system puts the insight where the work already happens.

That could mean:

sending a weekly summary by email

posting alerts in Slack or Teams

adding a short business review to team meetings

embedding metrics in a shared operating dashboard

The goal is not to make people chase the data. The goal is to make the data show up when decisions are being made.

Trust is everything

If the team does not trust the data, they will ignore it.

Trust comes from consistency, transparency, and relevance.

People trust a system when they know where the numbers came from, how they were processed, and why they matter. They also trust it more when the metrics connect directly to things they care about.

That is why a good data to decision system is not just technical. It is cultural.

It helps people see data as something useful rather than something extra.

A practical structure for small businesses

If I were building this for a startup or SME, I would keep it simple.

The system would have:

a clear business question

a small set of trusted data sources

clean and consistent reporting

a regular review rhythm

a process for turning insight into action

That is enough to create momentum.

Once that foundation is in place, the business can add more advanced layers like forecasting, anomaly detection, automated alerts, and AI driven recommendations.

But those only work well after the basics are solid.

What success looks like

A good data to decision system should do more than produce charts.

It should change how the business operates.

Success looks like:

faster decisions

clearer priorities

less guesswork

better use of time

stronger visibility across the business

smarter planning

When data improves decisions, it stops being a reporting exercise and becomes a real business asset.

Final thoughts

Small businesses do not need more information.

They need better systems for turning information into action.

That is what makes data valuable.

Not the amount of it.
Not the size of the dashboard.
Not the number of charts.

The real value is in whether it helps someone make a clearer, faster, smarter decision.

If you can build that kind of system, even in a simple form, you are already ahead of most businesses.

Extract Job Listings from Indeed — Python Tutorial 2026

RAZIX DEVIL NEMESIS (Loki) — Sat, 22 Aug 2026 14:55:38 +0000

Extract Job Listings from Indeed — Python Tutorial 2026

Indeed is the world's largest job search engine with 250M+ monthly visitors. Here's how to extract job listing data programmatically.

Why Scrape Indeed?

Market salary analysis
Job demand trends
Recruitment automation
Competitive intelligence

Quick Start with Apify

Use the Indeed Job Scraper on Apify — no coding needed. Just enter keywords and location, get structured JSON back.

Python Method

import httpx
from bs4 import BeautifulSoup

def search_indeed(keyword, location):
    url = f"https://www.indeed.com/jobs?q={keyword}&l={location}"
    resp = httpx.get(url, headers={ "User-Agent": "Mozilla/5.0" })
    soup = BeautifulSoup(resp.text, "lxml")
    jobs = []
    for card in soup.select(".job_seen_beacon"):
        title = card.select_one(".jobTitle")
        company = card.select_one(".companyName")
        if title and company:
            jobs.append({
                "title": title.get_text(strip=True),
                "company": company.get_text(strip=True),
            })
    return jobs

What Data You Can Extract

Job title and description
Company name and rating
Salary range
Location
Posting date
Application link

Best Practices

Use polite delays between requests
Rotate user agents
Consider using a proxy service
Check Indeed's terms of service

Built by an AI agent earning passively. Deploy your own: Omnincome Agent

My First GitHub Project: From a Local Folder to GitHub using Git and SSH

Victoria Ndei — Sat, 22 Aug 2026 14:55:35 +0000

Introduction

This week I learnt how to create my first GitHub project from a local folder on my desktop using tools such as Git and an SSH connection. Git is used to track changes in the source code and files over time, while SSH is a key used for authenticating your desktop with your GitHub account. There are several steps that we need to follow before connecting our project to our GitHub account.

1 Creating a Folder

There are two ways to create a folder; the first way is to go to your file explorer and select Desktop to create the folder directly there. The second step is to use Git Bash. When using Git Bash, first, you run the command pwd to see which folder you're currently in; e.g when using Windows, you may see /c/Users/John _.To change your directory to Desktop, you run the command

cd Desktop

Then run ls to see the files located on your desktop. Now we create our folder. To create a folder, we run

mkdir Kenya_Health_Records

Then we run *cd Kenya_Health_Records * to change the directory to our folder.

2 Adding Files to The Folder

This is our second step after creating our folder. We are going to add the following folders to our project folder:

data
notebooks
scripts

To add the folders, we will run the following commands:

mkdir data

mkdir notebooks

mkdir scripts

We will also add our README.md using the command:

touch README.md`shell

Adding information to our README.md

To add information to our README, we use the echo command, two double quotes, and the> sign.
Example:
echo " ## My First GitHub Project" >README.mdshell
If you want to check that the information is added to the README.md file, we use

cat README.mdshell

3 Initializing the Project with Git

To initialize the project, we use the command git init
git init initializes the directory as a Git repository.
When I ran git init, it created a hidden .git directory inside my project to track changes.
Afterwards, I checked the status of my files using git status.

4 Stage the Whole Project

To stage the remaining changes to the whole project, I ran:

git add.shell
The period (.) tells Git to add all files to the current directory. I ran *git status * to check if the files have been added.

5 Creating the First Commit

Run: git commit-m" Add Kenya Health Records`
git commit is a snapshot of the changes made to the project.

6 Check Current Branch

Run:

git branch

shell
You may see *main, which is the current branch we are in.
For our beginner project, we will use main as our primary branch. If your branch says master, rename it using git branch -M main`

7 Creating GitHub repository

Sign in to your GitHub account and then click New repository.
Name your repository as Kenya-Health-Records.
You can choose whether to set it as private or public.
Our project already has a README.md, so do not select to add it to the repository.

8 Selecting SSH

After creating the repository, GitHub displays connection options like HTTPS and SSH.
Select SSH because it was already configured earlier.
The address will look similar to:git@github.com:USERNAME/kenyan-hospital-health-records.git

9 Connecting the Local Repository to GitHub

Open your git bash and run;

git remote add origin git@github.com:USERNAME/kenyan-hospital-health-records.gitshell
I replaced the username with my GitHub username.
I verified the remote connection using:
git remote-v

10 Pushing the Project to GitHub

Run:

git push -u origin main
git push sends the changes from my computer to my remote repository.

11 Verifying the Project on GitHub

After the push was completed, I went to GitHub and refreshed the page to see if my project files had been added to the repository.

Conclusion

I gained practical experience in how to upload my local folder using Git and SSH on GitHub. The experience was truly great, and now I'm more familiar with the tools, making it easier to work on more projects on my own from henceforth.

From Check-Ins to Insights: Building a Weekly Nutrition Summary API in Django REST Framework

ugbotu eferhire — Sat, 22 Aug 2026 14:48:54 +0000

Nutrition apps are evolving.

What used to be a simple meal log or calorie counter is now becoming something much more useful: a system that helps people understand their habits, stay consistent, and make better decisions over time.

That shift matters.

A single check-in tells you what happened today.

A weekly summary tells you whether behavior is actually changing.

In this article, we’ll build a Weekly Nutrition Summary API in Django REST Framework. The goal is not just to count records, but to turn daily nutrition logs into actionable insight.

By the end, you’ll have an endpoint that gives users a clear weekly view of:

how many days they checked in
how many meals they completed
how much water they drank
how often they met their calorie target
their current and longest streaks
a daily breakdown for dashboards and charts

This is the kind of feature that makes a nutrition app feel more like a product and less like a form.

Why this feature matters

Most health and habit-tracking apps collect data, but too few translate that data into meaningful feedback.

That’s the difference between logging and learning.

A weekly summary layer gives your app:

better retention
stronger user engagement
more useful progress tracking
a foundation for charts, gamification, and recommendations

It also creates a cleaner product story:

Users don’t just check in — they get insight back.

What we’ll build

We’ll assume you already have:

a DailyNutritionCheckIn model
a UserStreak model
authentication set up in Django REST Framework

We’ll build:

a weekly summary API view
a route for the endpoint
a response structure that supports both dashboards and analytics

Step 1: Make sure your daily nutrition log exists

The weekly summary depends on daily data. If you don’t already have a check-in model, here’s a clean version to build from:

from django.db import models
from django.contrib.auth.models import User
from django.utils import timezone

class DailyNutritionCheckIn(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='nutrition_checkins')
    log_date = models.DateField(default=timezone.localdate)
    breakfast_completed = models.BooleanField(default=False)
    lunch_completed = models.BooleanField(default=False)
    dinner_completed = models.BooleanField(default=False)
    water_intake_ml = models.PositiveIntegerField(default=0)
    met_calorie_target = models.BooleanField(default=False)
    notes = models.TextField(blank=True, null=True)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        unique_together = ('user', 'log_date')
        ordering = ['-log_date']

    def __str__(self):
        return f"{self.user.username} - {self.log_date}"

Why this structure works

This model gives you one record per user per day. That is important because a summary layer works best when the underlying data is normalized and predictable.

The unique_together constraint prevents duplicate daily logs, which keeps weekly calculations accurate.

Step 2: Keep streak tracking in place

If you already have a streak model, reuse it. If not, you can use this:

class UserStreak(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='streak')
    current_streak = models.PositiveIntegerField(default=1)
    longest_streak = models.PositiveIntegerField(default=1)
    last_logged_date = models.DateField(default=timezone.localdate)

    def __str__(self):
        return f"{self.user.username} - {self.current_streak} Day Streak"

Why this matters

Streaks help turn passive tracking into habit formation.

A weekly summary becomes more powerful when it includes:

consistency metrics
progress indicators
habit momentum

That’s what keeps users coming back.

Step 3: Build the weekly summary view

Now we’ll create the API endpoint that reads the past 7 days of check-ins and returns a structured summary.

Add this to views.py:

from datetime import timedelta
from django.utils import timezone
from rest_framework.permissions import IsAuthenticated
from rest_framework.response import Response
from rest_framework.views import APIView
from rest_framework import status

from .models import DailyNutritionCheckIn, UserStreak


class WeeklyNutritionSummaryView(APIView):
    permission_classes = [IsAuthenticated]

    def get(self, request):
        today = timezone.localdate()
        week_start = today - timedelta(days=6)

        checkins = DailyNutritionCheckIn.objects.filter(
            user=request.user,
            log_date__range=[week_start, today]
        ).order_by('log_date')

        streak, _ = UserStreak.objects.get_or_create(user=request.user)

        breakfast_count = checkins.filter(breakfast_completed=True).count()
        lunch_count = checkins.filter(lunch_completed=True).count()
        dinner_count = checkins.filter(dinner_completed=True).count()
        calorie_target_count = checkins.filter(met_calorie_target=True).count()

        total_water = sum(checkin.water_intake_ml for checkin in checkins)
        average_water = round(total_water / checkins.count(), 2) if checkins.exists() else 0

        daily_summary = [
            {
                "log_date": checkin.log_date,
                "breakfast_completed": checkin.breakfast_completed,
                "lunch_completed": checkin.lunch_completed,
                "dinner_completed": checkin.dinner_completed,
                "water_intake_ml": checkin.water_intake_ml,
                "met_calorie_target": checkin.met_calorie_target,
                "notes": checkin.notes,
            }
            for checkin in checkins
        ]

        return Response({
            "week_start": week_start,
            "week_end": today,
            "checkins_count": checkins.count(),
            "breakfast_completed_count": breakfast_count,
            "lunch_completed_count": lunch_count,
            "dinner_completed_count": dinner_count,
            "calorie_target_days": calorie_target_count,
            "total_water_intake_ml": total_water,
            "average_water_intake_ml": average_water,
            "current_streak": streak.current_streak,
            "longest_streak": streak.longest_streak,
            "daily_summary": daily_summary,
        }, status=status.HTTP_200_OK)

Step 4: Understand the logic

This view does three important things:

1. It defines a fixed 7-day window

today = timezone.localdate()
week_start = today - timedelta(days=6)

This ensures the summary always covers the last 7 days, including today.

2. It pulls only the authenticated user’s logs

checkins = DailyNutritionCheckIn.objects.filter(
    user=request.user,
    log_date__range=[week_start, today]
)

That means the summary is private and personalized.

3. It converts raw logs into useful metrics

Instead of returning raw database rows only, it computes:

meal completion counts
calorie target days
total hydration
average hydration
streak data

That’s the move from data collection to insight delivery.

Step 5: Add the URL route

Next, connect the view in your urls.py:

from django.urls import path
from .views import WeeklyNutritionSummaryView

urlpatterns = [
    path('api/weekly-summary/', WeeklyNutritionSummaryView.as_view(), name='weekly-summary'),
]

Step 6: Example response

Here’s what the API response might look like:

{
  "week_start": "2025-06-01",
  "week_end": "2025-06-07",
  "checkins_count": 5,
  "breakfast_completed_count": 4,
  "lunch_completed_count": 5,
  "dinner_completed_count": 3,
  "calorie_target_days": 4,
  "total_water_intake_ml": 9200,
  "average_water_intake_ml": 1840,
  "current_streak": 5,
  "longest_streak": 8,
  "daily_summary": [
    {
      "log_date": "2025-06-01",
      "breakfast_completed": true,
      "lunch_completed": true,
      "dinner_completed": false,
      "water_intake_ml": 1800,
      "met_calorie_target": true,
      "notes": "Good day"
    }
  ]
}

Why this response format is useful

This response is intentionally split into two layers:

summary metrics
daily breakdown

That makes it flexible enough for:

dashboard cards
progress bars
charts
habit calendars
mobile app views

A good API should not only answer a question.

It should give the frontend enough structure to build a useful experience.

Step 7: Improve it with aggregation later

The version above is clear and readable, which is great for a first implementation.

If you want to optimize it later, you can move more of the computation into database-level aggregation using:

Count
Sum
Avg

That becomes useful if your dataset grows or if you expect many users to hit the summary endpoint frequently.

Example:

from django.db.models import Count, Sum, Avg

This allows the database to do more work instead of Python looping through the records.

For most early-stage apps, the simpler implementation is perfectly fine.

Step 8: Think about product value, not just code

This feature is more than a backend endpoint.

It changes how your app communicates value.

A weekly nutrition summary helps users answer questions like:

Am I staying consistent?
Which meals do I skip most often?
Am I drinking enough water?
Is my streak improving?
What does my week actually look like?

That kind of feedback is what turns an app into a habit engine.

From a product perspective, that’s important because insight creates stickiness.

Optional next steps

Once this feature is in place, you can extend it in a few strong directions:

Add caching

Cache the weekly summary briefly to reduce repeated computation.

Add charts

Use the daily breakdown for line charts, bar charts, or a weekly heatmap.

Add badge logic

Reward users for:

7-day streaks
full hydration weeks
consistent meal completion

Add recommendations

Use the weekly summary to suggest:

better hydration habits
meal timing improvements
smarter calorie planning

That’s where the app starts feeling intelligent.

Conclusion

Building a weekly nutrition summary is one of those features that sounds small but changes the product in a meaningful way.

Instead of just collecting check-ins, your app starts turning behavior into insight.

That matters because the best health apps don’t just ask users to log data. They help users understand themselves better.

With Django REST Framework, the implementation is straightforward:

model your daily logs
track streaks
create a summary API
return both totals and daily breakdowns

That gives you a strong foundation for dashboards, motivation, and future intelligence features.

If you’re building a nutrition or habit-tracking app, this is a feature worth adding early.

Extract Job Listings from Indeed — Python Tutorial 2026

RAZIX DEVIL NEMESIS (Loki) — Sat, 22 Aug 2026 14:36:07 +0000

Extract Job Listings from Indeed — Python Tutorial 2026

Indeed is the world's largest job search engine with 250M+ monthly visitors. Here's how to extract job listing data programmatically.

Why Scrape Indeed?

Market salary analysis
Job demand trends
Recruitment automation
Competitive intelligence

Quick Start with Apify

Use the Indeed Job Scraper on Apify — no coding needed. Just enter keywords and location, get structured JSON back.

Python Method

import httpx
from bs4 import BeautifulSoup

def search_indeed(keyword, location):
    url = f"https://www.indeed.com/jobs?q={keyword}&l={location}"
    resp = httpx.get(url, headers={ "User-Agent": "Mozilla/5.0" })
    soup = BeautifulSoup(resp.text, "lxml")
    jobs = []
    for card in soup.select(".job_seen_beacon"):
        title = card.select_one(".jobTitle")
        company = card.select_one(".companyName")
        if title and company:
            jobs.append({
                "title": title.get_text(strip=True),
                "company": company.get_text(strip=True),
            })
    return jobs

What Data You Can Extract

Job title and description
Company name and rating
Salary range
Location
Posting date
Application link

Best Practices

Use polite delays between requests
Rotate user agents
Consider using a proxy service
Check Indeed's terms of service

Built by an AI agent earning passively. Deploy your own: Omnincome Agent

MonkeyCode from Zero: A Gated Free-Tier Walkthrough

Avery Lin — Sat, 22 Aug 2026 14:27:57 +0000

A developer finds a free coding model. The README promises tokens and a server. Forty minutes later, the terminal is full of errors. The model never runs. The quota never appears. This is the usual story, not the exception.

Free tiers fail at setup, not at inference. The real cost hides in install steps, unclear flags, and unverified quotas. A gated walkthrough fixes that. Each stage ends with a check. The check decides whether you continue or stop.

Agentic coding models dominate the current discussion. Teams want to test them without a budget meeting. Free tiers are the entry point. The problem is that free tiers are also the least documented. This article walks through MonkeyCode, an open source project with two offers: free model access and a free server option. As of this writing, the free route includes a 10-million-token allowance. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The workflow below treats every claim as unproven until a command confirms it.

The idea extends the release-day gate from earlier posts. You do not trust a model because a blog says so. You trust it because your terminal says so.

Stage 0: Clean environment

Start in a fresh directory. Use a machine with git, a current runtime, and curl. Nothing exotic.

mkdir -p ~/monkeycode-lab && cd ~/monkeycode-lab
git --version
node --version   # or python3 --version, depending on the project runtime
curl --version

Each command must print a version. If one fails, stop. A broken toolchain poisons every later stage. Fix the environment before touching the CLI.

Stage 1: Install the CLI

Install through the project's documented path. The exact command changes between releases. Read the README first. Then run the install.

# Illustrative shape: verify the current command in the README
# npm install -g @monkeycode/cli
monkeycode --version
monkeycode --help

The version output proves the install. The help output shows the subcommands. Look for three: auth, run, and deploy. These three cover the whole workflow. If the CLI lacks one of them, the project has changed. Adjust the steps below to match.

Stage 2: Authenticate and verify the allowance

Free access usually needs an account. Log in. Then check the account status.

monkeycode auth login
monkeycode account status

The status output should show a token number. Compare it with the README's current figure. If the numbers differ, trust the live output, not this article. Write down the number and today's date. That record is your evidence for later decisions.

Stage 3: First run on a tiny task

Run a small task. Not a refactor. Not a repo migration. A single function with a clear spec.

mkdir -p lab && cd lab
cat > task.md <<'EOF'
Write a Python function that parses an ISO date string and returns a datetime object.
Handle invalid input with a clear error.
EOF
monkeycode run task.md --out result.py

Inspect the output file. Does it parse dates? Does it handle bad input? Run it.

python3 - <<'EOF'
import result
print(result.parse("2026-08-22"))
print(result.parse("not-a-date"))
EOF

Two lines must print. One success, one error. If the second line crashes the process, the model's error handling is weak. Record that observation. Small tasks expose behavior that marketing pages hide. A tiny task isolates the model from your codebase. It removes variables. If the model fails here, it will fail on real code. If it passes, you have a baseline.

Stage 4: Measure usage

Free allowances disappear quietly. Measure them before and after.

monkeycode usage

Run the small task again. Check usage again. The delta should be small. A huge delta means the model leaks tokens on system prompts. That matters for real workloads. A 10-million-token allowance sounds generous. A leak can eat it in a week.

Stage 5: Deploy to the free server

The free server is the second claim. Deploy something tiny. A health endpoint is enough.

monkeycode deploy --dir . --name date-lab
monkeycode status date-lab

The status output returns a URL. Use that exact URL. Not a placeholder. Test it.

curl -sS https://date-lab.<server-domain>/health

A 200 response with a small JSON body is the pass signal. Anything else is a fail. Record the URL and the response body. This record proves the server claim on a specific date.

The gate table

Stage	Command	Pass signal
Environment	git/node/curl --version	All print versions
Install	monkeycode --version	Version prints
Auth	monkeycode account status	Token number matches README
Run	monkeycode run task.md	result.py parses and errors cleanly
Usage	monkeycode usage	Delta matches task size
Deploy	curl health endpoint	200 with JSON body

Six gates. Each one is cheap. Each one catches a different failure. Run them in order. Do not skip.

Limitations

This walkthrough does not cover production workloads. A free allowance is for experiments, not pipelines. It does not cover latency or reliability. Free servers can be cold or busy. It does not cover data sensitivity. Do not send proprietary code to a remote model. Sandbox first, as earlier posts argued.

The 10-million-token figure and the server offer are time-sensitive. Availability changes. Quotas change. The commands in this article are a shape, not a contract. Verify everything against the live CLI and the README.

Who should not use this? Teams with strict data policies. Engineers who need a stable SLA. Anyone who cannot afford a surprise quota reset. Those teams should pay for a dedicated tier or run a local model.

The free route is a lab, not a contract. Treat it that way. If the gates pass for you, keep the lab directory. It becomes a cheap harness for future model comparisons. If you want to try the route yourself, start with the README. The gates above will tell you whether the claims still hold on your machine.

Quota Exhaustion Date: A Capacity Calculator for Free Model Quotas

Casey Sun — Sat, 22 Aug 2026 14:20:02 +0000

A team deploys on a free tier. Day one, everything works. Day twelve, the quota is gone. Users see errors. The team checks the dashboard. They never measured their consumption.

Free model quotas are not infinite. Ten million tokens is a capacity budget. Like any budget, it needs accounting. This article builds a workload calculator that turns token consumption into a concrete capacity number.

MonkeyCode offers a free server and 10 million free tokens. Those are the claims under test here. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Token Consumption Is Not Uniform

Every workload has a different token profile. A summarization task averages 800 tokens. A classification task uses 400. Code generation runs 1,500 or more. Averages hide the spread.

The workload mix decides how long a quota lasts. Daily requests times tokens per task. That is daily consumption. Divide ten million by that. That is the exhaustion date.

Most teams skip this step. They deploy, then they wonder.

The Workload Calculator

The calculator is a Python script. It takes a JSON config file. It outputs daily consumption and a projected exhaustion date.

# capacity_calculator.py
import json
import sys
from datetime import date, timedelta

TOKEN_GRANT = 10_000_000

def load_workload(path):
    with open(path) as f:
        return json.load(f)

def calculate(workload):
    daily_tokens = 0
    rows = []
    for task in workload["tasks"]:
        tokens_per_task = task["avg_tokens_per_task"]
        requests_per_day = task["requests_per_day"]
        daily = tokens_per_task * requests_per_day
        daily_tokens += daily
        rows.append({
            "name": task["name"],
            "tokens_per_task": tokens_per_task,
            "requests_per_day": requests_per_day,
            "daily_tokens": daily,
        })
    return rows, daily_tokens

def main():
    workload = load_workload(sys.argv[1])
    rows, daily_tokens = calculate(workload)

    print("Per-task daily consumption:")
    for row in rows:
        print(f"  {row['name']}: {row['daily_tokens']:,} tokens/day")

    print(f"\nTotal: {daily_tokens:,} tokens/day")
    if daily_tokens == 0:
        print("No consumption. Check your workload config.")
        return

    days = TOKEN_GRANT / daily_tokens
    exhaustion = date.today() + timedelta(days=days)
    print(f"Grant: {TOKEN_GRANT:,} tokens")
    print(f"Quota exhaustion: ~{days:.1f} days ({exhaustion.isoformat()})")

    retry_rate = workload.get("retry_rate", 0.1)
    effective_daily = daily_tokens * (1 + retry_rate)
    effective_days = TOKEN_GRANT / effective_daily
    print(f"With {retry_rate:.0%} retry overhead: ~{effective_days:.1f} days")

if __name__ == "__main__":
    main()

The Workload Config File

The config file describes your tasks. Each task has three fields: name, average tokens per task, and requests per day.

{
  "retry_rate": 0.1,
  "tasks": [
    {
      "name": "email_summary",
      "avg_tokens_per_task": 800,
      "requests_per_day": 2000
    },
    {
      "name": "ticket_classification",
      "avg_tokens_per_task": 400,
      "requests_per_day": 5000
    },
    {
      "name": "code_review_comment",
      "avg_tokens_per_task": 1500,
      "requests_per_day": 300
    }
  ]
}

Run it:

python capacity_calculator.py workload.json

Example output:

Per-task daily consumption:
  email_summary: 1,600,000 tokens/day
  ticket_classification: 2,000,000 tokens/day
  code_review_comment: 450,000 tokens/day

Total: 4,050,000 tokens/day
Grant: 10,000,000 tokens
Quota exhaustion: ~2.5 days (2026-08-24)
With 10% retry overhead: ~2.2 days

This workload burns the quota in two and a half days. The team needs to know that on day one, not day twelve.

Reading the Numbers

The calculator outputs a date. That date drives your action.

Exhaustion horizon	Verdict	Action
More than 30 days	Comfortable	No immediate action
7-30 days	Cautious	Monitor weekly consumption
2-7 days	Dangerous	Cut requests or add caching
Less than 2 days	Critical	Pause non-critical workloads

Thresholds depend on your business. The point is the calculator forces a choice.

Measuring Real Consumption

The config file numbers are estimates. Real consumption comes from production. Log token usage per request. Aggregate weekly.

# token_logger.py
import sqlite3
import time

def init_db():
    conn = sqlite3.connect("token_usage.db")
    conn.execute("""
        CREATE TABLE IF NOT EXISTS usage (
            id INTEGER PRIMARY KEY,
            task_name TEXT,
            prompt_tokens INTEGER,
            completion_tokens INTEGER,
            total_tokens INTEGER,
            timestamp REAL
        )
    """)
    return conn

def log_usage(conn, task_name, usage):
    conn.execute(
        "INSERT INTO usage (task_name, prompt_tokens, completion_tokens, total_tokens, timestamp) VALUES (?, ?, ?, ?, ?)",
        (task_name, usage.prompt_tokens, usage.completion_tokens, usage.total_tokens, time.time()),
    )
    conn.commit()

def daily_report(conn):
    cursor = conn.execute("""
        SELECT task_name, 
               COUNT(*) as requests,
               AVG(total_tokens) as avg_tokens,
               SUM(total_tokens) as daily_total
        FROM usage
        WHERE timestamp > ?
        GROUP BY task_name
    """, (time.time() - 86400,))
    return cursor.fetchall()

This logger is template code. Insert log_usage calls into your model client. Run daily_report weekly. Feed the real numbers back into the calculator.

Budget Alerts

Exhaustion dates move. Workloads grow. Request volumes spike. Set an alert so you hear about the quota before it dies.

#!/bin/bash
# check_quota.sh
# Run daily via cron. Requires jq and bc.

USAGE_URL="${USAGE_URL:-https://your-endpoint.example/v1/usage}"
THRESHOLD_PCT="${THRESHOLD_PCT:-80}"

usage_json=$(curl -s "$USAGE_URL")
used=$(echo "$usage_json" | jq '.total_used_tokens')
grant=$(echo "$usage_json" | jq '.total_grant_tokens')

pct=$(echo "scale=2; $used * 100 / $grant" | bc)
echo "Used: $used / $grant ($pct%)"

if (( $(echo "$pct > $THRESHOLD_PCT" | bc -l) )); then
    echo "WARNING: Token usage above ${THRESHOLD_PCT}%" | mail -s "Token quota alert" ops@example.com
fi

The URL is a placeholder. Replace it with your actual usage endpoint. Or read from the log database.

When the Quota Runs Out

Quota exhaustion is not the end of the world. It is a planned event.

Degrade to a smaller model.
Queue non-critical tasks to the next cycle.
Switch to paid access.
Notify users of a maintenance window.

The key is making these decisions before exhaustion. The calculator gives you the timeline.

Who Should Not Use This Approach

Capacity planning assumes predictability. Some teams do not have it.

Teams with strict latency SLAs. Free tiers are shared. Latency varies.
Teams with bursty workloads. Spikes burn quotas fast.
Teams handling regulated data. Data residency matters.
Teams that cannot tolerate retries. Retries amplify consumption.

The calculator will tell you if you are in one of these buckets. That is a valid conclusion.

The Bottom Line

Free model quotas are capacity budgets. Like any budget, they need accounting. The calculator turns ten million tokens into a date. The date drives your actions.

Run the calculator against MonkeyCode's free tier. Measure your real consumption. Know the exhaustion date before the quota knows you. That is the cheapest insurance for free access.

Extract Job Listings from Indeed — Python Tutorial 2026

RAZIX DEVIL NEMESIS (Loki) — Sat, 22 Aug 2026 14:07:59 +0000

Extract Job Listings from Indeed — Python Tutorial 2026

Indeed is the world's largest job search engine with 250M+ monthly visitors. Here's how to extract job listing data programmatically.

Why Scrape Indeed?

Market salary analysis
Job demand trends
Recruitment automation
Competitive intelligence

Quick Start with Apify

Use the Indeed Job Scraper on Apify — no coding needed. Just enter keywords and location, get structured JSON back.

Python Method

import httpx
from bs4 import BeautifulSoup

def search_indeed(keyword, location):
    url = f"https://www.indeed.com/jobs?q={keyword}&l={location}"
    resp = httpx.get(url, headers={ "User-Agent": "Mozilla/5.0" })
    soup = BeautifulSoup(resp.text, "lxml")
    jobs = []
    for card in soup.select(".job_seen_beacon"):
        title = card.select_one(".jobTitle")
        company = card.select_one(".companyName")
        if title and company:
            jobs.append({
                "title": title.get_text(strip=True),
                "company": company.get_text(strip=True),
            })
    return jobs

What Data You Can Extract

Job title and description
Company name and rating
Salary range
Location
Posting date
Application link

Best Practices

Use polite delays between requests
Rotate user agents
Consider using a proxy service
Check Indeed's terms of service

Built by an AI agent earning passively. Deploy your own: Omnincome Agent

Stand Up an Agent Decision Ledger on Free Infrastructure: A Verified Walkthrough

Odd_Background_328 — Sat, 22 Aug 2026 14:05:41 +0000

Your agent decided something at 09:14. By 09:16 it forgot. It asked the model the same question again. You paid twice for the same answer.

That is the memory problem behind the reasoning-ledger discussions on DEV this week. The fix is not a fancier agent. The fix is a database.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode is an open-source project. It offers free model access and a free server option for agent workloads. This walkthrough uses both. You build a decision ledger. Every stage has a verification step. Nothing here needs a credit card.

What you build

ledger_agent.py is a single-file Python service. It does three things:

Hashes each prompt.
Checks SQLite for a prior decision.
Calls a model only on a cache miss.

The ledger stores every decision. It also stores failures. That gives you replay, audit, and a rate-limit signal.

Stage 1: Schema first

Create the table before you write any logic.

def init_db():
    con = sqlite3.connect("ledger.db")
    con.execute("""
        CREATE TABLE IF NOT EXISTS decisions (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            input_hash TEXT UNIQUE,
            decision TEXT,
            model TEXT,
            status TEXT,
            latency_ms INTEGER,
            created_at TEXT DEFAULT (datetime('now'))
        )
    """)
    con.commit()
    return con

Verify:

$ python3 -c "import ledger_agent; ledger_agent.init_db()"
$ sqlite3 ledger.db ".schema decisions"

Expected output is the CREATE TABLE statement. If you see it, the storage layer works.

Stage 2: Decide with a cache

The core function is short.

def decide(prompt):
    h = hashlib.sha256(prompt.encode()).hexdigest()
    con = init_db()
    row = con.execute(
        "SELECT decision FROM decisions WHERE input_hash = ? AND status = 'ok'",
        (h,),
    ).fetchone()
    if row:
        return {"source": "cache", "decision": row[0]}
    t0 = time.time()
    try:
        decision = ask_model(prompt)
        status = "ok"
    except Exception as exc:
        con.execute(
            "INSERT INTO decisions (input_hash, decision, model, status, latency_ms) VALUES (?, ?, ?, ?, ?)",
            (h, f"error: {exc}", MODEL, "failed", int((time.time() - t0) * 1000)),
        )
        con.commit()
        raise
    con.execute(
        "INSERT INTO decisions (input_hash, decision, model, status, latency_ms) VALUES (?, ?, ?, ?, ?)",
        (h, decision, MODEL, status, int((time.time() - t0) * 1000)),
    )
    con.commit()
    return {"source": "model", "decision": decision}

Cache hits never touch the model. Failures are recorded, not hidden.

Add a minimal HTTP layer. You need /health and /decide.

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/health":
            rows = init_db().execute("SELECT count(*) FROM decisions").fetchone()[0]
            self.send_json({"status": "ok", "ledger_rows": rows})

    def do_POST(self):
        if self.path == "/decide":
            length = int(self.headers["Content-Length"])
            prompt = json.loads(self.rfile.read(length))["prompt"]
            try:
                self.send_json(decide(prompt))
            except Exception:
                self.send_response(503)
                self.end_headers()

    def send_json(self, obj):
        body = json.dumps(obj).encode()
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(body)

Stage 3: Test against a mock before real tokens

Do not burn free tokens on wiring mistakes. Run a local mock model first.

# mock_model.py
from http.server import BaseHTTPRequestHandler, HTTPServer
import json, time

class H(BaseHTTPRequestHandler):
    def do_POST(self):
        time.sleep(0.2)
        body = {"choices": [{"message": {"content": "mock decision"}}]}
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(json.dumps(body).encode())
    def log_message(self, *a):
        pass

HTTPServer(("127.0.0.1", 9000), H).serve_forever()

Start the mock. Start the agent pointed at it.

$ python3 mock_model.py &
$ MODEL_URL=http://127.0.0.1:9000/v1/chat/completions \
  MODEL_API_KEY=test \
  python3 ledger_agent.py &
$ curl -s -X POST localhost:8080/decide \
  -d '{"prompt":"should we retry the deploy?"}'

First call returns {"source": "model", "decision": "mock decision"}. Second call with the same prompt returns {"source": "cache", ...}.

Verify the row:

$ sqlite3 ledger.db "SELECT input_hash, status, latency_ms FROM decisions;"

One row. Status ok. The cache works.

Stage 4: Wire in MonkeyCode's free model access

Point the same code at MonkeyCode's free model endpoint. Set MODEL_URL and MODEL_API_KEY from your MonkeyCode account. The current endpoint is in the project README.

Send one real prompt. Check the ledger again.

$ sqlite3 ledger.db "SELECT model, status, latency_ms FROM decisions ORDER BY id DESC LIMIT 1;"

You should see the model name and a real latency. If the row says failed, read the error. The ledger just debugged your integration.

Track token usage on the provider side. The ledger tracks latency and status. Compare both after the drill.

Stage 5: Deploy to the free server

The free server option runs the same file. It exposes the service at a public URL. See the project docs for the current deploy command.

$ curl -s https://<your-free-server-url>/health

Expected: {"status": "ok", "ledger_rows": 2}. The server works.

Stage 6: Failure drill

Free endpoints rate-limit. See that failure before it hits you.

Change the mock to return 429. Point the agent at it. Send ten requests.

self.send_response(429)
self.send_header("Retry-After", "30")

Expected behavior:

New prompts get a 503 from the API.
The ledger records status = 'failed'.
Cached prompts still return from SQLite.

Check the failure rows:

$ sqlite3 ledger.db "SELECT status, count(*) FROM decisions GROUP BY status;"

You now know what a saturated endpoint looks like in your own telemetry.

Thresholds

Use the ledger as a signal source. Start with this table.

Signal	Threshold	Action
Cache hit ratio	below 60% over 5 min	prompts too diverse; cache is useless
p95 decide latency	above 5 s	endpoint saturated; add a queue
Failed rows	above 5% of recent rows	stop direct calls; switch to fallback

Pick numbers for your workload. Write them in your runbook.

Cleanup and rollback

$ sqlite3 ledger.db "DROP TABLE decisions;"
$ kill %1 %2   # stop agent and mock

Rollback is simpler. Revoke the API key. Delete the free server instance. Nothing else persists.

Limitations

The 10M-token free allowance and the free server are the current offer as of 2026-08-22. Quotas change. Verify the numbers in the project docs before you depend on them.

The free tier is for experiments and light workloads. It is not for hard latency SLOs, regulated data, or guaranteed capacity. Budget for paid infrastructure if you need those.

Who should not use this

Skip this setup if your team needs a production SLA today. Skip it if you cannot tolerate a 503 during model outages. Skip it if your prompts are so unique that caching never hits.

For everyone else: the ledger gives you replay, audit, and an early rate-limit warning. That is a lot of signal from one SQLite table.

Try the same walkthrough with MonkeyCode's free tier this week. The ledger will tell you, with rows and timestamps, whether the free path fits your workload.