DEV Community: Omar Baró

Field Break: an open-weight AI that tells you to close the screen

Omar Baró — Mon, 05 Oct 2026 22:55:45 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

I built Field Break, a deliberately small AI tool whose success condition is that you stop using it.

You tell it four things:

how many minutes you have;
your energy level;
what kind of outdoor space is nearby;
one constraint, such as “stay close to home” or “no car”.

It returns one micro-adventure that can start almost immediately, plus a final instruction telling you when to lock the screen.

That last part is the product idea. Most AI apps optimize for more conversation. Field Break optimizes for the shortest useful interaction possible.

Demo

The 36-second demo is here:

https://raw.githubusercontent.com/ondmindmanagement-hub/field-break/main/demo/field-break-demo.mp4

A live Apertus 1.5 70B test was also captured during the challenge. Given 20 minutes, medium energy, neighbourhood streets and a small park, the model produced a “Neighbourhood Pocket Adventure” and ended with:

Turn off phone and let adventure unfold offline

The exact prompt and result are preserved in the repository so the model evidence is inspectable rather than described from memory.

Code

ondmindmanagement-hub / field-break

Open-weight AI micro-adventures that get you off the screen — Hacktoberfest Week 1

Field Break

Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass

Field Break turns a small amount of free time into one simple outdoor micro-adventure, then explicitly tells the user to put the screen away.

Open-source AI core

The app is designed for the open-weight Apertus 1.5 model through an OpenAI-compatible endpoint. The provider/model are environment-configurable, so the project can switch to another open-weight deployment without changing the UI.

Run with real model inference by setting:

OPEN_MODEL_API_KEY OPEN_MODEL_API_URL=https://api.publicai.co/v1/chat/completions OPEN_MODEL_NAME=swiss-ai/apertus-v1.5-8b

Without a key, the prototype runs a clearly labelled deterministic demo-policy; it never pretends that fallback output is model inference.

Why open innovation matters

The planning layer is not locked to one proprietary model or API. An open-weight model can be self-hosted, swapped, audited, or moved closer to the user's data. For a tiny tool whose purpose is to get you away from the screen, that simplicity matters.

Safety

Field…

View on GitHub

Repository: https://github.com/ondmindmanagement-hub/field-break

The project is intentionally dependency-light: a Python standard-library server, a small browser UI, three unit tests, and an OpenAI-compatible adapter for an open-weight model endpoint.

How I Built It

The open model at the center is Apertus 1.5, with the default configuration pointing to swiss-ai/apertus-v1.5-8b.

The model receives only the context the user provides. The system prompt explicitly tells it not to invent live weather, trail closures, local conditions, or medical claims. It must prefer something local, simple, low-cost and reversible.

The output is structured JSON:

title;
number of minutes;
a short plan;
what to bring;
a screen_exit instruction.

That structure matters because I did not want another chat interface that can drift into an endless conversation. Field Break asks for one decision and then gets out of the way.

The provider and model are environment-configurable:

OPEN_MODEL_API_KEY=...
OPEN_MODEL_API_URL=https://api.publicai.co/v1/chat/completions
OPEN_MODEL_NAME=swiss-ai/apertus-v1.5-8b

If no model key is configured, the app switches to an explicitly labelled demo-policy. It never claims that deterministic fallback output came from the model.

I also added tests for JSON extraction, output normalization and the demo planner. All three are passing.

Why Does Open Innovation Matter?

For this project, open innovation is not a decorative technology choice.

A closed planning API would make the smallest part of the product — deciding what to do outside — dependent on one vendor. With an open-weight model, the inference layer can be moved, swapped or self-hosted without changing the experience.

That becomes especially interesting for a tool whose philosophy is less cloud, less screen, less dependency.

The project can use a hosted Apertus endpoint today, but the interface is deliberately compatible with a future local or privately hosted deployment. The user interface does not need to know which provider is behind it.

Open weights also make the model choice inspectable. The project is not pretending that “AI” is a magic black box; the model family, prompt, evidence and fallback behavior are all visible in the repo.

What I Learned

The challenge theme pushed me to reverse the normal metric.

Instead of “How many messages can the user send?”, I asked:

How quickly can the software become unnecessary?

That changed the design:

no feed;
no history requirement;
no engagement loop;
one plan;
one exit instruction.

The best output is not the most impressive paragraph. It is the one that makes someone say “okay” and leave the desk.

Prize Categories

I am entering the overall Hacktoberfest Open-Source AI Challenge Week 1 category.

I did not add a partner category just to increase eligibility; the project only claims technologies it actually uses.

Build Evidence

New project created during the Week 1 challenge window.
Public GitHub repository.
3/3 tests passing.
Live Apertus 1.5 70B evidence captured from Public AI / CSCS infrastructure.
Short demo video and screenshots included in the repo.

Field Break is small on purpose. The screen should be the shortest part of the experience.

BOLT PayFlow Guard: Open AI That Cannot Spend Without You

Omar Baró — Mon, 05 Oct 2026 05:18:11 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

I built BOLT PayFlow Guard, a governed AI payment workflow designed around one rule: AI can propose, but a person must authorize the consequential action.

I built it for a close friend, who uses AI tools but does not want an AI agent to have silent authority over money. The problem is not whether AI can understand a payment request; it is whether that recommendation can become an irreversible action without explicit human control.

A user can write a natural-language request such as:

Pay 1 EUR for a test purchase.

The local AI turns that into structured JSON with whether a payment is recommended, the proposed amount, and the reason.

But nothing is paid. A separate approval gate blocks the payment path until explicit human authorization exists.

Demo

The demo shows the complete decision flow: intent, AI recommendation, blocked state, human approval, and the PayPal Sandbox path.

Code

ondmindmanagement-hub / bolt-payflow-guard

Governed AI payment workflow prototype using PayPal Orders API

BOLT Payflow Guard

BOLT Payflow Guard is a governed AI-to-payment workflow prototype for the PayPal AI Hackathon.

Flow

A local AI model running in Ollama analyzes a natural-language payment request and returns a structured recommendation. The AI is advisory only and cannot execute payments.
A separate BOLT approval gate blocks the payment step unless explicit human approval is present.
After approval, the PayPal module authenticates with OAuth 2.0 and creates a PayPal Orders v2 Sandbox order.

AI integration

The demo uses Ollama with qwen2.5:7b by default, so the AI part can run locally without cloud credentials.

Run:

npm run ai -- "Pay 1 EUR for a test purchase"

The model returns JSON with should_pay, amount_eur, and reason.

PayPal integration

Requires PayPal Sandbox credentials. Keep them in environment variables only:

PAYPAL_CLIENT_ID
PAYPAL_CLIENT_SECRET
optional PAYPAL_BASE_URL (defaults to the Sandbox API)

Then explicitly approve the sandbox transaction with BOLT_APPROVED=1 and…

View on GitHub

https://github.com/ondmindmanagement-hub/bolt-payflow-guard

How I Built It

The open-source AI core is Ollama running Qwen 2.5 7B locally.

The Node.js AI module sends the natural-language request to a local Ollama endpoint and asks the model to return structured JSON containing should_pay, amount_eur, and reason.

The model is advisory only. It never receives PayPal credentials and it cannot execute a transaction.

A separate BOLT approval layer evaluates whether explicit authorization exists. Without approval, the workflow stops before contacting PayPal. With approval, the payment module can authenticate with PayPal OAuth 2.0 and create an order using the PayPal Orders v2 Sandbox API.

The architecture is intentionally simple:

natural-language intent → local open model → structured proposal → human approval gate → PayPal Sandbox

That separation keeps AI reasoning independent from financial authority.

Why Does Open Innovation Matter?

Running Qwen locally through Ollama changes the trust model.

The payment request can be interpreted without sending the user's prompt to a closed hosted model. The model can be swapped, inspected, run offline, or replaced with another open-weight model without changing the governance layer.

With local inference:

prompts can remain on the user's machine,
there is no AI API key to manage,
inference can keep working without a cloud model provider,
the model can be changed without redesigning the workflow,
and payment credentials remain completely separate from the AI process.

Open AI makes the reasoning layer portable. Human approval keeps the authority layer explicit.

What I Learned

The useful boundary is not “AI versus no AI.” It is recommendation versus authority.

An AI system can automate interpretation and planning while still requiring a person to approve the final consequential step. That pattern can extend to spending limits, role-based approvals, risk checks, multi-step authorization, and other high-impact workflows.

Built With

Ollama
Qwen 2.5 7B
Node.js
PayPal Orders v2 Sandbox API
PayPal OAuth 2.0
Human-in-the-loop approval gating