DEV Community: Francis Oyakhire

Postiz Self Host Bluesky Python Client

Francis Oyakhire — Fri, 25 Sep 2026 15:00:23 +0000

This week’s discussions around AI sovereignty and open source reminded us of a core principle: control over your data and tools is not just a philosophical stance - it’s a technical necessity. As we continue to push for open, self-hosted systems, we found ourselves building a Python client that interacts with a self-hosted instance of Postiz, a Bluesky-compatible social network. Here’s how we made it work.

The Problem: Self-Hosting and API Inconsistencies

We wanted to run a fully self-hosted social network, with full control over data, infrastructure, and the user experience. Postiz, being a self-hosted alternative to Bluesky, fit the bill. However, the API it exposes is not always consistent - specifically, when fetching posts via /api/public/v1/posts, the response can be either a single object or a list, depending on the query parameters. This inconsistency required careful handling on our end.

Our goal was to build a Python client that could reliably interact with a Postiz instance running in Docker Compose, with minimal boilerplate and clear error handling. We also needed to manage authentication headers and parse the response structure dynamically.

Our Approach: Docker Compose + Python Client

We deployed Postiz using Docker Compose, which made it easy to spin up a local instance for development and testing. Here’s a simplified version of our docker-compose.yml:

version: '3'
services:
  postiz:
    image: postiz/postiz:latest
    ports:
      - "8080:8080"
    environment:
      - POSTIZ_DB_URL=postgres://user:pass@db:5432/postiz
    depends_on:
      - db
  db:
    image: postgres:15
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=postiz
    volumes:
      - postgres_data:/var/lib/postgresql/data
volumes:
  postgres_data:

With Postiz running locally, we built a Python client that sends requests to /api/public/v1/posts. The client handles authentication via an Authorization header, which Postiz expects in the format Bearer <token>. The token is obtained via the /api/auth/token endpoint, which we also implemented in our code.

Code: Handling API Responses Dynamically

Here’s a snippet from our Python client, which demonstrates how we handle the API’s inconsistent response structure:

import requests

def fetch_posts(postiz_url, auth_token):
    headers = {
        "Authorization": f"Bearer {auth_token}"
    }
    response = requests.get(f"{postiz_url}/api/public/v1/posts", headers=headers)
    response.raise_for_status()

    data = response.json()

    # Handle both single object and list responses
    if isinstance(data, dict) and "items" in data:
        return data["items"]
    elif isinstance(data, list):
        return data
    else:
        raise ValueError("Unexpected response structure from Postiz API")

This code ensures that regardless of whether the API returns a single item or a list, we can consistently work with a list of posts in our application. We also made sure to raise clear errors when the response structure is unexpected, which helps in debugging and maintaining the client over time.

Tradeoffs and Considerations

While this approach is simple and effective, it does come with tradeoffs. The dynamic handling of API responses adds a layer of complexity that could be avoided with a more consistent API. Additionally, managing authentication tokens and ensuring secure storage is a non-trivial task, especially in production environments.

We also found that the Postiz API lacks some features that we would expect from a modern social network, such as pagination and rate limiting support. These are things we plan to address in our own middleware layer.

What’s Next

We’re currently working on extending our client to support more endpoints, including user relationships and media uploads. We’re also exploring ways to integrate this with our on-device AI infrastructure, enabling local processing of social media data without relying on cloud services. How would you approach extending this client for a production environment? We’re eager to hear your thoughts.

Cron Scheduled Ollama Autonomous Agent

Francis Oyakhire — Tue, 22 Sep 2026 15:00:22 +0000

This week’s focus on benchmarking large language model (LLM) inference at scale has sparked renewed interest in how we can build autonomous agents that operate efficiently and responsibly on the edge. As we explore the intersection of on-device AI and autonomous systems, we’re seeing new patterns emerge in how we manage inference pipelines, especially when dealing with real-world constraints like latency, accuracy, and user safety.

At Apex Grid, we’ve been building a cron-scheduled autonomous agent using Ollama as the core inference engine. This agent is designed to operate on a periodic basis, generating and publishing content across multiple social channels. The system is structured with a clear separation of concerns, ensuring that each component - voice profiling, controversy checking, credit verification, and content quarantine - can be independently tested, scaled, and maintained.

The agent operates on a strict pipeline: first, it generates a voice profile from a user’s input, stored as a separate JSON file. This profile is used to personalize the output. Then, the generated content passes through a “controversy gate” - a second model that acts as a filter, scanning for potentially harmful or controversial content. Only after passing this gate does the content proceed to the “credit gate,” which performs a real-time probe against a Postgres database managed by Postiz. This step ensures that the agent only publishes content from verified users. If the content fails any of these checks, it is moved to a quarantine folder for later review or deletion.

Here’s what the publish_to_all_channels function looks like in our implementation:

from ollama import Client
import json
import os
import psycopg2
from datetime import datetime

def publish_to_all_channels(content, voice_profile_path):
    # Step 1: Load voice profile
    with open(voice_profile_path, 'r') as f:
        voice_profile = json.load(f)

    # Step 2: Controversy gate check
    controversy_model = Client(host='controversy-gate-model-endpoint')
    controversy_check = controversy_model.generate("Is this content controversial?", content)
    if controversy_check['response'].lower() in ['yes', 'maybe']:
        move_to_quarantine(content, voice_profile)
        return False

    # Step 3: Credit gate check
    try:
        conn = psycopg2.connect(
            dbname="postiz_db",
            user="user",
            password="password",
            host="postiz-db-endpoint"
        )
        cur = conn.cursor()
        cur.execute("SELECT verified FROM users WHERE content_hash = %s", (hash(content),))
        result = cur.fetchone()
        if not result or not result[0]:
            move_to_quarantine(content, voice_profile)
            return False
    except Exception as e:
        print(f"Credit gate error: {e}")
        move_to_quarantine(content, voice_profile)
        return False
    finally:
        if conn:
            conn.close()

    # Step 4: Publish content
    for channel in ["twitter", "telegram", "mastodon"]:
        publish_to_channel(channel, content, voice_profile)
    return True

This approach allows us to decouple the inference logic from the publishing logic, making the system more robust and easier to maintain. However, it’s not without tradeoffs. The use of a second model for controversy checking increases inference latency and cost. Additionally, the reliance on a Postgres probe for credit verification introduces a single point of failure if the database is unreachable or slow.

We’re actively exploring ways to reduce this latency by integrating lightweight on-device filtering models and implementing fallback strategies for database connectivity. We’re also evaluating whether we can replace the second model with a rule-based system for certain types of content, which could reduce both cost and complexity.

What we’re building next is a more distributed version of this agent, where each gate can be independently scaled and deployed across multiple nodes. We’re also looking into using a hybrid approach - combining rule-based checks for low-risk content with model-based checks for high-risk scenarios. We’d love to hear from the community: have you seen similar patterns in your autonomous agent pipelines, or have you found better ways to handle multi-model inference in production?

Publishing Pipeline Scheduled vs Immediate

Francis Oyakhire — Sat, 19 Sep 2026 15:00:24 +0000

This week’s focus on log analysis tools reminded us of the importance of infrastructure that works reliably in the background - and that’s exactly what we’re building at Apex Grid. Just as log analysis tools help us understand the health of our systems, our publishing pipeline needs to be robust enough to handle both scheduled and immediate content delivery without breaking the user experience.

At Apex Grid, we run a hybrid publishing pipeline that balances the need for immediate content delivery with the strategic value of scheduling posts for optimal user engagement. For example, we use Postiz to schedule social media posts for specific timezones, ensuring that our audience sees content when it matters most. Meanwhile, long-form articles like this one are published on a cron-fire schedule, hitting our platform at regular intervals. This approach allows us to maintain a consistent content rhythm while still tailoring engagement tactics to different platforms.

The challenge arises when these two workflows intersect - specifically, when the same content is published both immediately and scheduled for later. A key point of friction is the canonical URL. For example, a post published immediately may have one URL structure, while the same content scheduled for later might be routed through a different endpoint, leading to duplicate content and broken links. To solve this, we’ve implemented a centralized content routing system that assigns a single, stable canonical URL to every piece of content, regardless of when or where it’s published.

Here’s a simplified version of how we manage this in our backend:

from flask import Flask, request, redirect, url_for
import uuid

app = Flask(__name__)

# In-memory store for content metadata
content_store = {}

@app.route('/publish', methods=['POST'])
def publish_content():
    data = request.json
    content_id = str(uuid.uuid4())
    content_store[content_id] = {
        'title': data['title'],
        'body': data['body'],
        'scheduled_time': data.get('scheduled_time'),
        'canonical_url': f"https://apexgrid.dev/content/{content_id}"
    }
    return {'canonical_url': content_store[content_id]['canonical_url']}, 201

@app.route('/content/<content_id>')
def get_content(content_id):
    if content_id in content_store:
        return content_store[content_id]['body'], 200
    return "Content not found", 404

if __name__ == '__main__':
    app.run()

This code snippet shows how we assign a unique canonical URL to each piece of content as it’s published. Whether the content is scheduled or published immediately, the canonical URL remains consistent. This approach ensures that search engines and users always see the same URL for the same content, no matter the delivery method.

However, this abstraction isn’t without tradeoffs. Managing a centralized content store adds complexity to our system. It requires careful coordination between our scheduling systems, our content delivery networks, and our analytics pipelines. Additionally, we’ve had to invest in robust versioning and caching strategies to ensure that updates to scheduled content don’t inadvertently overwrite or break already-published posts.

Looking ahead, we’re exploring ways to further decouple our scheduling and immediate publishing systems while maintaining the same level of consistency. One idea is to introduce a lightweight content graph that can dynamically route requests to the correct version of a post based on time, platform, and user context. We’re also evaluating how to better integrate with third-party platforms like Postiz to ensure that scheduled posts are automatically mirrored with the same canonical URL structure as our immediate content.

What do you think about the tradeoffs between centralized and decentralized content routing in hybrid publishing pipelines? Have you encountered similar challenges in your own projects?

Controversy Gate Second Model Check

Francis Oyakhire — Wed, 16 Sep 2026 15:00:25 +0000

This week’s excitement around large language models has sparked a broader conversation about their reliability - and more specifically, their safety. As the field advances, the tension between performance and responsibility grows sharper. The recent release of DeepSeek-V4.1-Flash has reignited interest in model capabilities, but it also raises the question: how do we ensure these models are not just powerful, but trustworthy?

At Apex Grid, we’ve been exploring a pattern for autonomous social posting that addresses this tension head-on. The idea is simple: draft content with your primary model, then score it for controversy or risk using a second, specialized model before publishing. This approach reduces the likelihood of auto-published embarrassment without requiring constant human oversight. It’s a two-model architecture, designed for reliability in the absence of real-time feedback loops.

Our stack runs on a multi-model inference engine that supports this pattern. The first model, a general-purpose LLM, is responsible for generating content. The second model, trained on a dataset of flagged content and risk signals, evaluates the output. We’ve found that this separation of concerns improves both accuracy and safety, as each model can be optimized for its specific task.

Here’s a simplified version of how the architecture works in practice:

from apexgrid import LLMInference, RiskScorer

# Primary model for content generation
primary_model = LLMInference(model_name="primary-llm", temperature=0.7)

# Secondary model for risk scoring
risk_model = RiskScorer(model_name="risk-llm", threshold=0.6)

def generate_and_score(prompt):
    draft = primary_model.generate(prompt)
    risk_score = risk_model.score(draft)
    if risk_score < 0.6:
        return f"Draft: {draft}\nRisk Score: {risk_score} (Safe to publish)"
    else:
        return f"Draft: {draft}\nRisk Score: {risk_score} (High risk, do not publish)"

# Example usage
output = generate_and_score("Write a post about the new AI regulations in Nigeria.")
print(output)

This pattern has shown promise, but it’s not without its tradeoffs. First, the latency introduced by running two models in sequence can be significant, especially in high-throughput environments. Second, the two models must be kept in sync, which can be challenging when the primary model evolves more rapidly than the risk model. Finally, the risk model is only as good as the data it was trained on - and in fast-moving domains like social media, that data can become outdated quickly.

Despite these challenges, the two-model approach has proven more effective than relying on a single model to both generate and evaluate content. We’ve seen a 35% reduction in high-risk content being auto-published compared to a single-model system. The separation also allows us to update the risk model independently, without affecting the primary model’s performance.

What’s next? We’re experimenting with lightweight, on-device versions of the risk model to reduce latency and improve scalability. We’re also exploring ways to train the risk model on synthetic data, generated by the primary model itself, to keep it up to date with the latest trends and risks. We’re curious: have you seen similar patterns used in your own systems? What tradeoffs did you face?

Data Substrate Versus Vector Db Rag

Francis Oyakhire — Sun, 13 Sep 2026 15:01:23 +0000

This week’s headlines highlight the rapid evolution of AI in China, with models like Qwen and DeepSeek pushing the frontier of capability. But as these models grow more sophisticated, the conversation around how data is stored, queried, and used as a foundation for AI systems becomes more critical than ever. At Apex Grid, we’re building a regtech tool for Nigerian microfinance banks, and in doing so, we’ve had to grapple with the difference between a data substrate and vector databases in the context of RAG.

In the world of AI-powered applications, the distinction between a data substrate and a vector database is often blurred. A data substrate is a versioned, citable, and queryable layer of structured and unstructured data that serves as a reference for AI systems. It’s about precision, traceability, and governance. On the other hand, a vector database excels at similarity search and is the go-to tool for embedding-based retrieval in RAG systems. Each has its place, but the choice depends on the problem at hand.

For our regtech tool, we needed to ensure that AI-generated insights could be traced back to specific data sources - a non-negotiable requirement in a financial compliance context. When a bank’s AI system flags a suspicious transaction, it’s not enough to say “the model thinks this is risky.” We need to know which regulation it’s referencing, which historical pattern it’s matching, and how the data was processed. That’s where a data substrate shines.

To illustrate, consider a scenario where our system processes loan applications. A vector database might quickly find similar applications based on embeddings of text and numerical features. But if we later need to audit why a particular application was flagged, the vector database lacks the structure and lineage to answer that. A data substrate, however, can link the AI’s decision to specific, versioned data entries - making the system both compliant and explainable.

Here’s a simplified example of how we structure our data substrate using a SQL-like query to retrieve the source of a decision:

SELECT 
    decision_id, 
    regulation_version, 
    source_data_id, 
    embedding_hash
FROM 
    ai_decisions
WHERE 
    decision_id = '2024-07-12-001'

This query returns the regulation version used, the source data that influenced the decision, and a hash of the embedding that was used in the RAG pipeline. This level of traceability is critical in regulated environments and is a feature that vector databases alone cannot provide.

That said, vector databases are not obsolete. In our system, we use a vector database for the initial retrieval phase of the RAG pipeline. It’s fast, efficient, and well-suited for finding similar documents or embeddings. But once the relevant data is retrieved, it’s moved into the data substrate for versioning and governance. This hybrid approach ensures we get the best of both worlds - speed and relevance from the vector database, and traceability and auditability from the data substrate.

Tradeoffs are inevitable. Maintaining a data substrate adds complexity and overhead compared to a pure vector DB approach. It requires more storage, more careful schema design, and more rigorous versioning. But for applications in regulated sectors, the tradeoff is worth it. In Nigeria’s microfinance space, where compliance is a top priority, the cost of a misclassified transaction or an untraceable AI decision is far greater than the cost of maintaining a data substrate.

Looking ahead, we’re exploring ways to integrate the data substrate with more dynamic AI models, enabling real-time auditing and feedback loops. We’re also looking into how to make the data substrate more accessible to non-technical users - after all, the value of traceable data is only realized when it can be understood and acted upon by the people who need it most. What do you think is the next big challenge in making data substrates both powerful and user-friendly?

GPU Preflight For Cron Agents

Francis Oyakhire — Thu, 10 Sep 2026 15:00:40 +0000

This week’s news about self-hosted AI coding agents has sparked renewed interest in the reliability of infrastructure that runs these agents. While the focus has been on the agent’s capabilities, we’ve found that the underlying infrastructure needs just as much attention - particularly when it comes to GPU-dependent cron jobs. At Apex Grid Technologies, we’ve been working on a robust preflight system for GPU-dependent cron agents that ensures they only run when the hardware is truly available.

Our cron agents are responsible for a variety of tasks, from model training to inference pipelines. All of them rely on GPU resources, and we’ve seen firsthand how brittle a simple try/except block can be in this context. A GPU might appear available at the start of a job, only for another task to consume it mid-execution, leading to silent failures or timeouts that are hard to debug. That’s why we’ve built a two-stage preflight system that checks both the health of the GPU and its availability.

The first stage of our preflight is a lightweight health check: we send a request to /api/tags and ensure it responds within 3 seconds. This check confirms that the GPU is not only present but also accessible by the system. The second stage is a warmup check, where we send a trivial request to /api/generate and measure the response time. This helps us detect if the GPU is currently being monopolized by another job. If either of these checks fails, the cron job skips cleanly, avoiding the pitfalls of firing and swallowing an error.

Here’s how we implement this in our code:

import requests
import time

def gpu_ready(timeout=10):
    start = time.time()
    try:
        # First stage: health check
        health_response = requests.get("http://localhost:8000/api/tags", timeout=3)
        if health_response.status_code != 200:
            return False

        # Second stage: warmup check
        warmup_response = requests.get("http://localhost:8000/api/generate", timeout=timeout)
        if warmup_response.status_code != 200:
            return False

        return True
    except requests.RequestException:
        return False

This helper function, gpu_ready(), is used before every GPU-dependent cron job. It ensures that the job only runs when the GPU is both healthy and available, preventing resource contention and reducing the risk of silent failures.

Of course, this approach has its tradeoffs. The warmup check adds some latency to the overall process, which might be problematic for jobs that need to run as quickly as possible. Additionally, the /api/generate endpoint used in the warmup must be designed to be lightweight - anything too heavy could skew the results or add unnecessary load. We’ve also had to handle edge cases, like when the GPU is in a state of transition (e.g., during a reboot or driver update), where the health check might pass but the warmup fails.

Looking ahead, we’re exploring ways to make this preflight even more intelligent. One idea is to use metrics from the GPU itself - such as utilization or temperature - rather than relying solely on HTTP endpoints. We’re also considering introducing a caching layer that remembers past failures and adjusts the preflight strategy accordingly. What do you think? Would you prefer a more hardware-centric approach, or do you see value in keeping the preflight logic at the application layer?

Ollama v1 OpenAI Compat Drops Think Toggle

Francis Oyakhire — Mon, 07 Sep 2026 15:00:59 +0000

This week's headlines buzzed with the promise of running large language models at unprecedented speeds, but the technical details beneath the surface often get lost in the hype. As engineers, we care more about the nuts and bolts - like when a seemingly minor API change can break a pipeline in unexpected ways. That’s exactly what happened to us when working with Ollama’s OpenAI-compatible endpoint and the Qwen3-family models.

We were running a service that relied on Ollama’s /v1 endpoint to interface with Qwen3 models, expecting the think: false toggle to short-circuit the model’s internal reasoning and return a prompt-based response. Instead, we noticed that the models were consistently exhausting their num_predict budget and returning empty content. This was a silent failure - no errors, no logs, just empty strings where we expected output.

After some digging, we realized the issue was not with the model itself, but with the endpoint. The /v1 OpenAI-compatible endpoint silently ignored the think: false parameter for Qwen3-family models. This meant the model would process the entire prompt, perform internal reasoning, and then - with no tokens left to predict - return nothing. It was a classic case of a misaligned expectation between the API and the model's behavior.

To fix this, we pivoted to Ollama’s native /api/chat endpoint, which respects the think: false toggle as intended. Here’s a comparison of the two payloads:

// OpenAI-compat endpoint (fails for Qwen3)
{
  "model": "qwen3",
  "prompt": "What is the capital of France?",
  "think": false,
  "num_predict": 10
}

// Native /api/chat endpoint (works as expected)
{
  "model": "qwen3",
  "messages": [
    {"role": "user", "content": "What is the capital of France?"}
  ],
  "options": {
    "think": false,
    "num_predict": 10
  }
}

The key difference lies in how the think parameter is interpreted and where it's placed in the payload. The /v1 endpoint appears to ignore think: false for certain models, while the native endpoint correctly honors it. We noticed the issue by monitoring the num_predict usage and correlating it with the output length. When the num_predict budget was consumed but no output was returned, it became clear that something was wrong in the reasoning phase.

This experience highlights the importance of testing across endpoints and understanding the nuances of model-specific behavior. While the /v1 endpoint is convenient for compatibility with OpenAI tools, it’s not a one-size-fits-all solution - especially for models like Qwen3 that have unique interaction patterns.

Looking ahead, we’re exploring ways to unify our internal tooling to handle these endpoint differences more gracefully. We’re also considering contributing to the Ollama project to clarify the behavior of the /v1 endpoint for specific models. What would you do if you encountered a similar silent failure in your AI pipeline?

Postiz Self Host Bluesky Python Client

Francis Oyakhire — Fri, 04 Sep 2026 15:00:18 +0000

This week, the AI space saw a surge in open-source enthusiasm, with new tools and libraries capturing developer attention. While the headlines focus on stars and strategic partnerships, we’re diving into the nitty-gritty of how we’ve built a self-hosted Postiz instance using Docker Compose and connected it with a Python client that communicates via the /api/public/v1/posts endpoint.

At Apex Grid Technologies, we’ve been evaluating lightweight, self-hosted social platforms as part of our broader exploration into on-device AI integration. Postiz stood out for its minimalism and open API, which made it a natural fit for our experimentation. We chose to self-host it using Docker Compose to ensure we had full control over the environment and could easily scale or modify it as needed.

Setting up Postiz with Docker Compose was straightforward. We used the official Docker image and configured it with our desired settings, such as database connections and authentication options. Here’s a simplified version of our docker-compose.yml:

version: '3.8'
services:
  postiz:
    image: postiz/postiz:latest
    ports:
      - "8080:8080"
    environment:
      POSTIZ_DB_URL: "postgres://user:password@db:5432/postiz"
      POSTIZ_JWT_SECRET: "supersecretkey"
    depends_on:
      - db
  db:
    image: postgres:15
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: postiz
    volumes:
      - postgres_data:/var/lib/postgresql/data
volumes:
  postgres_data:

Once the Postiz instance was up and running, we built a Python client to interact with its API. We focused on the /api/public/v1/posts endpoint, which allows for creating and retrieving posts. The client is built using requests, and we handle both the JSON payload and the response structure carefully.

Here’s how we construct the request:

import requests
import json

headers = {
    "Authorization": "Bearer <your-jwt-token>",
    "Content-Type": "application/json"
}

payload = {
    "text": "This is a test post from the Python client.",
    "visibility": "public"
}

response = requests.post("http://localhost:8080/api/public/v1/posts", headers=headers, json=payload)

if response.status_code == 200:
    result = response.json()
    if isinstance(result, list):
        print("Received a list of posts:", result)
    else:
        print("Received a single post:", result)
else:
    print("Error:", response.status_code, response.text)

We’ve noticed that the /api/public/v1/posts endpoint can return either a single object or a list depending on the context - for example, when creating a new post, it returns the created object, but when fetching all posts, it returns a list. This is a subtle but important detail for any client consuming the API. We handle this by checking the type of the response using isinstance() and processing accordingly.

One tradeoff we’ve made is the lack of advanced features like rate limiting or more granular permissions, which are not exposed through the public API. However, for our use case, this is acceptable, and we can always extend the client or the Postiz setup if needed.

Looking ahead, we’re exploring ways to integrate this setup with our on-device AI models. The idea is to have a local, self-hosted social layer that can interact with AI-generated content in real time, without relying on external cloud services. We’re also looking into ways to make the Python client more robust, including support for async requests and better error handling.

What are your thoughts on self-hosted social platforms and their potential for AI integration?

Cron Scheduled Ollama Autonomous Agent

Francis Oyakhire — Tue, 01 Sep 2026 15:00:22 +0000

This week’s news about new constraints on AI agents within networked systems reminded us of a critical design decision we made early in our work on autonomous social agents. While the headlines focus on policy and governance, the real challenge lies in the infrastructure that enables these agents to operate safely and autonomously. Here's how we built one such agent using Ollama, cron scheduling, and a layered gate system to ensure responsible behavior.

We're building a social agent that autonomously generates content for multiple channels. The agent runs on a Linux server, with a cron job triggering it every hour. The core of the agent is an Ollama model that generates text, but before any content is published, it must pass through a series of gates to ensure it's safe, relevant, and aligned with our values.

Our stack runs on a combination of Ollama for the LLM, Postgres for data storage, and Postiz for message queuing. We chose Postiz over other systems because of its lightweight design and compatibility with our existing infrastructure. The agent’s workflow is as follows:

Voice Profile Check: Each user has their own voice profile stored as a JSON file. The agent loads this profile to determine the tone, style, and personality of the generated content.
Controversy Gate: A second Ollama model acts as a classifier, scanning the generated text for any potentially controversial or harmful content.
Credit Gate: A Postgres query checks the Postiz DB to ensure the agent has sufficient credits or permissions to publish the content.
Quarantine Folder: Any content that fails the gates is moved to a quarantine folder for review before being discarded or reprocessed.

Here’s the function signature for publish_to_all_channels, which encapsulates the entire process:

def publish_to_all_channels(generated_text: str, voice_profile: Dict[str, Any]) -> bool:
    if not check_voice_profile(voice_profile):
        log.warning("Voice profile check failed")
        return False

    if not controversy_gate(generated_text):
        log.warning("Controversy gate failed")
        return False

    if not credit_gate():
        log.warning("Credit gate failed")
        return False

    try:
        for channel in CHANNELS:
            send_to_channel(channel, generated_text)
        return True
    except Exception as e:
        log.error(f"Failed to publish content: {e}")
        move_to_quarantine(generated_text)
        return False

Each of these gates has its own tradeoffs. The voice profile check ensures consistency, but it adds overhead in terms of file I/O and memory usage. The controversy gate is computationally expensive, as it involves running a second model. The credit gate introduces a dependency on Postgres and Postiz, which can be a bottleneck under high load.

We're actively working on optimizing the controversy gate by experimenting with smaller, more efficient models that can run locally without sacrificing accuracy. We're also exploring ways to batch process content to reduce the number of model inferences required.

What we're building next is a more distributed version of this agent that can run on multiple nodes, with each node handling a subset of the channels. This will help scale the system and reduce the load on any single component. We're also considering integrating real-time feedback from users to dynamically adjust the voice profile and gate thresholds.

Ninety-one days: why we built a food price tracker, and why we need you to fill it

Francis Oyakhire — Mon, 31 Aug 2026 15:00:02 +0000

The most recent official figure for what food costs in Nigeria describes May 2026. Today is 30 August. That is ninety-one days.

This is not an accusation. The National Bureau of Statistics publishes the Selected Food Price Watch monthly, it is careful work with a real sample frame, and it is current through May — we checked the catalogue this week and pulled the file. Every statistical office in the world publishes with a lag, because doing it properly takes time.

But a lag is still a lag. A woman deciding what to put in the pot this week cannot use a number about May. Neither can a trader pricing stock, a lender sizing a loan, or an economist trying to see inflation while it is happening rather than after it has finished.

So we built the fast half: foodtracker.apexgridapps.com. Crowd-reported retail food prices, by state, in the units people actually buy in. It updates the moment someone reports a price.

It does not replace the official series and it is not trying to. NBS remains the statutory record, and where the two disagree, NBS is the one that counts. What we can add is speed — and, over time, something more interesting: the gap between the two is itself a measurement.

Who this came from

The idea did not start with us. It came out of a set of questions from Queen Esther Oye , one of the advisors who reviews our work.

She asked three things that all turned out to need the same missing ingredient: a model of how food inflation would move in the fourth quarter; whether diaspora remittances act as informal adaptation grants when food prices spike and state safety nets fail; and a measure of purchasing power adjusted for localised food shocks rather than a national average.

Every one of those needs food prices by state , close to now. We went to look at what we held.

We held 229 rows. One month. Nine of thirty-seven states.

That is the honest inventory. We had built engines that needed state-level food prices and we did not have state-level food prices. You cannot model a localised food shock from nine states.

Ninety-one days is not a rounding error in food

With most numbers, a quarter’s lag is an inconvenience. With food it can invert the answer.

Nigerian food prices are seasonal, and the season that matters most is the one we are in. Grain stocks run down between planting and harvest, and prices climb through the lean months before falling back when the new crop arrives. A figure describing May, read in late August, is not simply an old number — it is a number from the other side of that curve, and nothing in it tells you which way things have moved since.

So the honest position is not that a May figure is a bit out of date. It is that a May figure cannot answer an August question at all , and quoting it as though it can is how a stale number does real damage. It is not a price any more; it is a claim about the past wearing today’s clothes.

That is the gap this fills. Not better than the official series — sooner than it, and openly rougher.

What we are asking

The tracker is live and nearly empty. That is the awkward stage of every crowd project, and there is only one way through it.

Report one price. Open the site, tap the item you bought, confirm the price if it looks right or type what you actually paid. It takes about fifteen seconds. No account, no email, no phone number — we do not collect your name or your IP address, and there is nothing to sign up for.

Then send it to somebody in another state. This is the part that matters more than the reporting. A food price tracker with ten states is a Lagos newsletter. Nigeria has thirty-seven, and the prices that move first are rarely the ones in the cities that already get written about.

We are tracking the basket people actually buy: rice, beans, gari, yam, tomatoes, pepper, onions, palm oil, bread, eggs, with millet, sorghum, maize and the rest one tap away. Prices are reported in market units — per mudu, per paint, per tuber — because asking a shopper for a price per kilogram gets you a guess.

The rules we set ourselves

A crowd tracker is only worth having if it is honest about being one.

Every figure carries how many people reported it, the spread between the highest and lowest, and how old the newest report is. A median of one report is labelled “ single report — not a price”, because that is what it is. There is no way to get the bare number out of our API without that context attached — we built it that way deliberately, since the bare number is what ends up quoted.

And we do not convert a mudu into a kilogram. A mudu of gari and a mudu of beans do not weigh the same, and the vessel varies by region and by trader. Publishing a kilogram price we had not measured would be inventing precision. So the conversion factor sits in our data as null, marked UNCALIBRATED, until somebody weighs it properly.

Why it matters who counts

There is a version of this country’s economic story that is told entirely from outside it — assembled from satellite passes, wire copy, and quarterly reports written three months after the fact. It is not usually wrong. It is just late, and thin, and shaped by whoever had the budget to collect it.

The alternative is not complaining about that. It is counting.

A woman in Gombe reporting what she paid for a mudu of rice this morning is doing statistics. Ten thousand of those, across thirty-seven states, is a national series that belongs to the people who generated it — published under a licence that keeps it free for researchers, journalists and NGOs, with the code open so anyone can check our arithmetic or run their own copy.

We are ninety-one days behind on what food costs. We do not have to be.

foodtracker.apexgridapps.com — report one price, then share it with someone in a state we are missing.

Publishing Pipeline Scheduled vs Immediate

Francis Oyakhire — Fri, 28 Aug 2026 15:00:14 +0000

This week, AWS announced a new version of AWS Glue that promises to make data integration faster and more cost-effective. While that’s impressive, we’re more interested in the underlying challenge: how to reliably move data across systems, especially when timing and consistency matter. At Apex Grid, we’ve wrestled with a similar problem in our publishing pipeline - specifically, how to balance the need for scheduled content with the immediacy of real-time updates.

We run a hybrid publishing system. Some content is scheduled - think social media posts that go out at optimal times for different timezones - while other content, like long-form articles, is published immediately, often triggered by a cron job or an event. This duality introduces a subtle but critical problem: managing canonical URLs across different publishing channels and timelines.

In a perfect world, every piece of content would have a single, unchanging URL. But when you publish the same article both immediately and later as part of a scheduled post, you end up with multiple URLs pointing to the same content. This breaks the web’s expectations around link consistency and SEO, and it complicates analytics when you’re tracking user engagement across platforms.

Our approach to solving this has been to introduce a canonical URL system that dynamically resolves to the correct version of the content based on context. Here’s how it works in practice:

def get_canonical_url(article_id, context):
    # context can be 'social', 'web', or 'email'
    if context == 'social':
        # return scheduled version
        return f"https://apexgrid.com/social/{article_id}"
    elif context == 'web':
        # return the original, long-form version
        return f"https://apexgrid.com/articles/{article_id}"
    else:
        # fallback or other contexts
        return f"https://apexgrid.com/articles/{article_id}"

This function isn’t magic. It relies on a backend mapping system that tracks all versions of an article and their associated contexts. Every time a new version is published - whether scheduled or immediate - we update this mapping. When a user clicks on a link, the system resolves the canonical URL in real time, ensuring they land on the correct version of the content.

But this isn’t without tradeoffs. Managing multiple URLs increases complexity in our CMS and affects caching strategies. We’ve had to invest in a robust URL resolver that can handle edge cases, like when a scheduled post is published early or when an immediate post is later rescheduled. It also requires careful coordination with our analytics team to ensure that user behavior is tracked consistently across all versions.

Despite these challenges, the hybrid model has proven valuable. It allows us to maintain the immediacy of our long-form content while still leveraging the power of scheduling for social media. It’s a balance that’s not easy to achieve, but it’s one we’re confident in.

Looking ahead, we’re working on a more intelligent version of this system that can automatically detect when a scheduled post is no longer needed - for example, if an article is updated and the scheduled version is now obsolete. We’re also exploring ways to unify our content models further, so that the distinction between scheduled and immediate publishing becomes less of a technical burden and more of a strategic choice.

Controversy Gate Second Model Check

Francis Oyakhire — Tue, 25 Aug 2026 15:00:15 +0000

This week’s release of a Go-based agent framework brought renewed attention to the balance between automation and oversight in AI systems. While the framework promises improved user experience, it also raises questions about the reliability of AI in high-stakes scenarios - questions that are especially relevant when it comes to autonomous systems making decisions on our behalf.

We’ve been working on a system that allows for autonomous social posting, but with a key twist: the content is drafted by one model, then scored for potential controversy or risk by a second model before being published. This two-model architecture helps reduce the chance of auto-published embarrassment without requiring constant human intervention. The idea is simple but powerful: trust the model to generate ideas, but let a different model act as a gatekeeper, filtering out content that might be harmful, controversial, or just plain unwise.

Here's a high-level look at how the system works in practice:

from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch

# Primary model: generates content
primary_model = AutoModelForSequenceClassification.from_pretrained("primary-model")
primary_tokenizer = AutoTokenizer.from_pretrained("primary-model")

# Secondary model: evaluates risk
secondary_model = AutoModelForSequenceClassification.from_pretrained("secondary-model")
secondary_tokenizer = AutoTokenizer.from_pretrained("secondary-model")

def generate_post(prompt):
    inputs = primary_tokenizer(prompt, return_tensors="pt")
    outputs = primary_model.generate(**inputs)
    return primary_tokenizer.decode(outputs[0], skip_special_tokens=True)

def score_risk(text):
    inputs = secondary_tokenizer(text, return_tensors="pt")
    outputs = secondary_model(**inputs)
    scores = torch.softmax(outputs.logits, dim=1)
    risk_score = scores[0][1].item()  # assuming class 1 is "controversial"
    return risk_score

def post_if_safe(prompt):
    draft = generate_post(prompt)
    risk = score_risk(draft)
    if risk < 0.7:
        print("Publishing:", draft)
        # publish_to_platform(draft)
    else:
        print("Risk score too high:", risk)

This pattern has its merits: the primary model can be optimized for creativity, while the secondary model can be fine-tuned for sensitivity and risk detection. It also allows for a degree of separation between the model that creates and the model that evaluates, which can help mitigate the risk of bias or overconfidence in a single model’s judgment.

However, the two-model approach isn’t foolproof. There are scenarios where the primary model may generate content that is clearly controversial, but the secondary model fails to flag it. This can happen if the secondary model is not trained on a sufficiently diverse dataset or if the two models have overlapping biases. In some cases, the secondary model may even flag non-controversial content as risky if its training data is skewed toward certain types of language or topics.

We're actively exploring ways to improve the robustness of this architecture. One idea is to use a third model for cross-validation, or to introduce a lightweight human-in-the-loop system for high-risk content. Another is to fine-tune the secondary model using a synthetic dataset that includes a wide range of edge cases and ambiguous content scenarios.

What do you think? Are there other patterns or techniques you’ve seen that help reduce the risk of auto-published embarrassment without sacrificing autonomy?