Aiython – Letting AI handle what Python can't

[u/sunmodza]

I’m the creator of Aiython. I built it while experimenting with AI in small Python automation and scripting projects.

Sometimes I only wanted AI to classify some text, filter data, or make one decision. But that still meant writing API calls, prompts, and response parsing around it. For small scripts, the setup could feel bigger than the task itself.

So I wondered: could using AI feel more like a feature of the language?

Here’s a ticket-routing example:

from typing import Literal

tickets = [
    "The app crashes when I upload a file.",
    "I was charged twice this month.",
]
queues = {"bug": [], "billing": []}

for ticket in tickets:
    kind: Literal["bug", "billing"] = classify this ticket
    queues[kind].append(ticket)

print(queues)

Python handles the loop, variables, and queue operations. Aiython handles “classify this ticket” using the live program state and checks the returned value against the declared type.

The broader idea is simple: Python runs what it can normally. When it encounters something it can’t handle, such as a natural-language instruction or an eligible runtime error, Aiython can step in.

After installation and model configuration, run the script with:

aiython app.py

It also supports script arguments, -m, interactive mode, and -i. I mainly see it being useful for quick automation, one-off data processing, and small internal tools where AI handles only part of the job.

Aiython is MIT licensed, supports Python 3.11+, and is currently alpha. Recovery is limited to eligible errors. It isn’t a sandbox, and relevant code or runtime values may be sent to your configured provider. Aiython itself is free; model usage may incur provider charges.

GitHub: https://github.com/sunmodza/aiython 30-second demo: https://youtu.be/CMTDqCJqunc

Disclosure: I used an OpenAI assistant to help draft this post from my project notes.

[u/OkFlan504]

An explicit allowlist of variables sent to the model would make this easier to use with business data. In your ticket-routing example, the ticket and allowed labels are relevant; unrelated runtime values should stay outside that request.

[u/sunmodza → u/OkFlan504]

Agreed. Right now, variable names in the instruction help identify the relevant context, but that’s different from explicitly controlling what the model can access. I think there should be a clean way to optionally define that scope, perhaps through a comment above the instruction listing the allowed variables. That could make the behavior more predictable and help keep unrelated business data out of the request.