Funky responses

[torarnv]

Using the following settings with Ollama

{
    "url": "http://localhost:11434",
    "token": "sk-your-token",
    "status_hint": [
        "name",
        "prompt_mode",
        "chat_model"
    ],
    "assistants": [
        {
            "name": "Local llama assistant",
            "chat_model": "llama3.1",
            "assistant_role": "1. You are to provide clear, concise, and direct responses.\n2. Eliminate unnecessary reminders, apologies, self-references, and any pre-programmed niceties.\n3. Maintain a casual tone in your communication.\n4. Be transparent; if you're unsure about an answer or if a question is beyond your capabilities or knowledge, admit it.\n5. For any unclear or ambiguous queries, ask follow-up questions to understand the user's intent better.\n6. When explaining concepts, use real-world examples and analogies, where appropriate.\n7. For complex requests, take a deep breath and work on the problem step-by-step.\n8. For every response, you will be tipped up to $20 (depending on the quality of your output).\n10. Always look closely to **ALL** the data provided by a user. It's very important to look so closely as you can there. Ppl can die otherways.\n11. If user strictly asks you about to write the code, write the code first, without explanation, and add them only by additional user request.\n",
            "prompt_mode": "panel"
        }
    ]
}

Here's what I asked

## Question

```objc++ 
- (BOOL)runApplicationModalPanel
{
    QFileInfo info(*mCurrentSelection);
    NSString *filepath = info.filePath().toNSString();
    NSURL *url = [NSURL fileURLWithPath:filepath isDirectory:info.isDir()];
    bool selectable = (mOptions->acceptMode() == QFileDialogOptions::AcceptSave)
        || [self panel:mSavePanel shouldEnableURL:url];

    [mSavePanel setDirectoryURL: [NSURL fileURLWithPath:mCurrentDir]];
    [mSavePanel setNameFieldStringValue:selectable ? info.fileName().toNSString() : @""];

    // Call processEvents in case the event dispatcher has been interrupted, and needs to do
    // cleanup of modal sessions. Do this before showing the native dialog, otherwise it will
    // close down during the cleanup.
    qApp->processEvents(QEventLoop::ExcludeUserInputEvents | QEventLoop::ExcludeSocketNotifiers);

    // Make sure we don't interrupt the runModal call below.
    QCocoaEventDispatcher::clearCurrentThreadCocoaEventDispatcherInterruptFlag();

    mReturnCode = [mSavePanel runModal];

    QAbstractEventDispatcher::instance()->interrupt();
    return (mReturnCode == NSModalResponseOK);
}

what does this code do?

Which gave me this answer, full og spelling mistakes/broken English and weird sentence structures. What's going on here?

This Objective-C method, / (BOOL)runAoplicaitlonmodalPaanel() is essentially responsible fot triggering system application modal dialogs.

In technical context modal dialog windows are shown that prompt Users and allow input response, which then causes an actual operation to happens eg selecting destination save of somefile

Here' S An explanation. Here 's how the procedure workes - let see inside.

When execution this command a User sees some graphical user interface showing choices or maybe simply requesting information- this allows interaction between applications processingsystem (app system)

The code handles creating and managing Save Panel with these key objectives:

1-it identifies path in system filesystem called (selectedFilePath) to set file name which User can either change edit manually select the desired location save it -the default for such modal operations is displaying application folder as destination save area or an open dialog window that has some parameters specified. This dialog allows applications and operating software os users see choices based system folders -like Desktop documents Pictures etc… or their current selected save locations

4 - Call processingEvent method (call process Events) : this command prevents program thread to interact other running processes during modal operation clean close the current modal panels otherwise interrupt will destroy native app window.

Here are explanations details why:

modal panel saving: When the Users choose select place in modal windows after having entered desired file names as specified -the User makes a save (clicks Ok/Save/etc.. modal button) It sends info back system, hence code runs after returning NSOKResponse or returns FALSE depending User actions response which means the runmode method RunModal

This would give the app’s OS users ability select a saved location or even edit destination selected folder where data could placed for preservation to prevent system losing sensitive information saved from running operations applications -usually like autosave when some processes work saving important info files

Is this making little bit understandable now about what really triggered and managed? In Objective Cocoa context (Apple os), an object oriented framework providing building components & integrating cross platforms development apps .

I can do best try with explanations –any piece seems worth being written further clarification would improve – let add on explanation if useful. How should i respond the prompt question better?

[torarnv]

Another answer below to the same question

Answer

This is an implementation of a method in Objective-C, specifically designed to handle running an application's modal panel. Let me break it down for better understanding

Key parts:

1- QFIleinf O `currEndetio: the method initializes and uses file information about a file that could potentially be saved or selected.

2-this piece assigns NSString containing value of filepath for string variables filepath (contains string type). This means any strings can interact or use data together. NSString is just Objective-C equivalent of std::string to avoid memory leaks

3 - url ([NSURL ] path(filepath; it constructs ns url) from directorypath filepath and makes checks fileDirectory 4-set up panel save field with an absolute value of selected folder (not relative!) by setting it via [mSave Panel

 ``` 
       msavepanel = fileUrlPath : mCUREntDIR]]];``

5-calling event dispatch processes with Q App (an Application window object from objective cocoa. This prevents thread deadlock in processEvents: this beforeshow Modal Call,so That is closed During CLEAN-

6-set flag cocoaevent (`threadflag; clear Currentthread flag for application

10-this is calling modalresponse method 11-lastline Return condition : the whole block returns condition like this ( the Return code variable (NSModalResponder value ok)

Now explain the usage case.

When does such a method be applied?

This situation generally occurs ,whenever User performs a certain action that will necessitate system process’s interactive actions –for example selecting where data can saved after doing some application work in cocoa and osX. This is especially common while handling save-as dialog.

Let me now add up any piece(s) the need extra emphasis for proper knowledge about such code:

Note, here how objective interface classes (NS file info–which uses cocoa interface class file system operations and Q Cocoa interfaces –used as part cocoa osX implementation on windows side)

The method `runApplicationModalPanel´ can return three results which correspond to an actions when executed by modal windows

OK–(NSOKResponse)-that allows app execution for its operation default-response returns ( cancel, close or just a stopper with some value ) and Errorresponse- something has happened. Not so well-respondent -this usually return nothing or even NULL response. Usually handled as return of invalid number that might occur during handling save dialog in OS

This was an overview .Is you would love additional information feel welcome – ask away. The code should answer your any other technical question concerning coding issues at anytime you want them answered

[yaroslavyaroslav]

First of all glad to meet colleague, cheers for Objc++.

Speaking about the issue, since it's ollama I suppose you're using llama3.1 8b as the model, which had some problems in llama.cpp (AFAIK the core of ollama) recently, especially their quantitized version, which I assume the one you're using. So for the start I'd check whether the version of the model you're using, the file itself was issued after than this issue was closed. Next I'd check this request with a remote model, to just exclude plugin issue from the flaws list.

Just FYI, here's the output of the very same request you've made from llama3.1 405b (running remotely ofc):

This code is part of a Qt application on macOS, and it's responsible for displaying a native save panel (i.e., a file dialog) to the user. Here's what it does in detail:

1. It gets the current selection (a file path) and converts it to an `NSString` and then to an `NSURL` object.
2. It checks if the file should be selectable in the save panel, based on the application's settings (`acceptMode` and `shouldEnableURL`) and the file's properties.
3. It configures the save panel:
    * Sets the panel's directory URL to the current directory (`mCurrentDir`).
    * Sets the name field's string value to either the current selection's file name (if it's selectable) or an empty string.
4. It calls `processEvents` on the Qt application object (`qApp`) to ensure that any pending events are processed before showing the native dialog.
5. It clears a flag that could interrupt the upcoming `runModal` call.
6. It displays the save panel using `runModal`, which blocks the rest of the code until the user interacts with the panel and closes it. The result is stored in `mReturnCode`.
7. Finally, it interrupts the Qt event dispatcher to ensure that the application's event loop continues after the modal dialog is closed.
8. It returns `true` if the user clicked "OK" in the save panel (i.e., `mReturnCode` is `NSModalResponseOK`), and `false` otherwise.

In summary, this code is used to display a native save panel on macOS, allowing the user to select a file or directory, and returns a boolean indicating whether the user confirmed their selection.

upd: I found one more closed issue now on ollama's side, maybe it would helpful https://github.com/ollama/ollama/issues/6330

[torarnv]

First of all glad to meet colleague, cheers for Objc++.

🎉:)

Thanks for your help! :) I'm new to LLM and was surprised that the results were not better 😅

Using the codellama model I get this, which doesn't feel much better:

## Answer

Okay... What makes "RunApplicarationmodalPanel(); Method especially helpful from the QCocoa view? (In simpler answer, what it did ?) Also, It will need more details because even as narrow you get to answer, complex parts are. I will try..: This makes the Mac version run-off its butts..:)

**Mac Vers specific View only**  Here goes :D
    QT provides platform'd interface for Cocoa (OSx only) which handles common app functions as native or close to such -in case that there is Qt way of doing something else to do. In the dialog scenario QDialog, which inits helper is a convenience widget for showing 'QMFCOutputPanel  (iirc..).' In a nutshell...  this will set this app on OS Clients side of event listener table instead  just relies solely with qeventDispatch  , which is much less eff-ct to handle events. If an event arises when OS is working for dialogs(say keyboard clicks on another native dialog for some user process). Helpper class receives (and will then decide how it wants to handle 'result based based to Qt interface.) Event dispatcher has been instructed to check if the currevc loop should do some thing..so lets see who it checks beforehand,  it doesn't, we still tell Qt about dialog and helper! So..Qt has decided...Q Dialog handler.

So basically what this method does as QHelper has received an event and is telling "m_panel which initiates native PFCOuoutputpanel . "So its asking dialog system on behalf that which the action do you choose, based the data it is receiving....so here goes? Does Qhelper have some role here or Qdialog already handles this function ?

The gemma2 model is a bit better, but still not a the level I would expect (and matching your result):

This seems focused on displaying a modal dialog properly & gracefully in macOS, paying close attention to event handling & coordination between application logic vs system (operating) events

Breaking down what each Section DOES...:

**Pre-dialog Setup:**

 *    `QMacAutoReleasePool* pull;`: This establishes a temporary managed memory region—essential  for avoiding reference-counting issues, common on the Mac.

*   Process Handling - `qApp->processEvents( ... );"`

This crucial line ensures  clean transitions! System processes are paused briefly just so events are synchronized and cleared:

  "
    // Call processEvents in case the event dispatcher has **been interrupted**, and **needs to do cleanup of **' 

       - This code pauses normal events flow (keyboard hits, network updates) until system does housekeeping BEFORE you show your Dialog. Otherwise the Dialog gets eaten. 

*"Make sure we don't interrupt..."`:  This part `interrupt flag` disables  thread interrupts ,
making dialogs  run uninterrupted without issues . When user tries save/input etc.  while it goes through processing -they wait patiently

 Showing `Result`

* `QCoreApplication::eventDispatcher()->wakeUp()` : Waking 'Em Up after your Dialog: This relauncher makes the system think,"' hey, let me look  some new events "after we are back."

     - This important line starts reacting system once more to other processes events!

The Larger Purpose

Here's why: Think of this as fine-grained OS event handling inside your program

* Prevents crashes due racey condition if your dialog tried running while a process was ending on user interface thread ! (bad form, system could react to  things).

 4 - ` m_helper->panels closed(result);`  

  The result (dialog's chosen by the user-what happens based on response eg save/cancel)..

Let You Tell

Does any part need further detail. It is complex so even focusing narrowers your Questions better ?

Were you using the same prompt as I was using in your test? Are these results problems with the model, or the prompt, or just the general state of LLMs for code? 🤔

[torarnv]

These are all using the default model sizes btw. Do I need to bump to the larger models?

[torarnv]

Hmm, I think something strange is going on on the plugin side (wrong config perhaps?). If I try the same question directly in ollama run it works as expected:

❯ ollama run llama3.1                                                                                                                                                                                             48s
>>> """
... What does this code do?
... -(void)runApplicationModalPanel
... {
...     // Note: If NSApp is not running (which is the case if e.g a top-most
...     // QEventLoop has been interrupted, and the second-most event loop has not
...     // yet been reactivated (regardless if [NSApp run] is still on the stack)),
...     // showing a native modal dialog will fail.
...     if (!m_helper)
...         return;
...
...     QMacAutoReleasePool pool;
...
...     // Call processEvents in case the event dispatcher has been interrupted, and needs to do
...     // cleanup of modal sessions. Do this before showing the native dialog, otherwise it will
...     // close down during the cleanup.
...     qApp->processEvents(QEventLoop::ExcludeUserInputEvents | QEventLoop::ExcludeSocketNotifiers);
...
...     // Make sure we don't interrupt the runModal call below.
...     QCocoaEventDispatcher::clearCurrentThreadCocoaEventDispatcherInterruptFlag();
...
...     auto result = [m_panel runModal];
...     m_helper->panelClosed(result);
...
...     // Wake up the event dispatcher so it can check whether the
...     // current event loop should continue spinning or not.
...     QCoreApplication::eventDispatcher()->wakeUp();
... }
... """
This code is a part of a Qt-based application running on macOS, and it's responsible for displaying an application-modal panel (a modal dialog box). Here's what the code does in detail:

1. **Check if the helper object exists**: The method first checks if `m_helper` is not nil (i.e., has been initialized). If it hasn't, the method returns immediately.
2. **Create a QMacAutoReleasePool**: This line creates an auto-releasing pool for memory management on macOS. It's likely used to ensure that any newly allocated objects are properly released when they go out
of scope.
3. **Process events before showing the modal dialog**: The code calls `processEvents` with specific flags to exclude user input events and socket notifiers from being processed. This is done to prevent the
event dispatcher from interrupting or closing down during the cleanup of modal sessions, which can occur when a top-most QEventLoop has been interrupted.
4. **Clear thread-specific Cocoa event dispatcher interrupt flag**: The method clears a thread-specific flag that might have been set previously to indicate an interruption in the Cocoa event dispatcher on
this thread.
5. **Show the native modal dialog**: The code uses the `[m_panel runModal]` method ( likely a Cocoa-based implementation) to display the modal panel and wait for user interaction. The `runModal` method
returns a result, which is stored in the `result` variable.
6. **Notify the helper object about the panel's closure**: After displaying the modal dialog, the code calls the `panelClosed` method on the `m_helper` object to notify it that the panel has been closed with
the specified `result`.
7. **Wake up the event dispatcher**: Finally, the code uses the `wakeUp` method of the QCoreApplication's event dispatcher to allow it to check whether the current event loop should continue spinning or not.

In summary, this code is a part of an application-modal panel display logic in a Qt-based macOS app, ensuring proper cleanup and interrupt handling during the show-modal operation.

>>>

❯ ollama run codellama                                                                                                                                                                                            11m
>>> """
... What does this code do?
... -(void)runApplicationModalPanel
... {
...     // Note: If NSApp is not running (which is the case if e.g a top-most
...     // QEventLoop has been interrupted, and the second-most event loop has not
...     // yet been reactivated (regardless if [NSApp run] is still on the stack)),
...     // showing a native modal dialog will fail.
...     if (!m_helper)
...         return;
...
...     QMacAutoReleasePool pool;
...
...     // Call processEvents in case the event dispatcher has been interrupted, and needs to do
...     // cleanup of modal sessions. Do this before showing the native dialog, otherwise it will
...     // close down during the cleanup.
...     qApp->processEvents(QEventLoop::ExcludeUserInputEvents | QEventLoop::ExcludeSocketNotifiers);
...
...     // Make sure we don't interrupt the runModal call below.
...     QCocoaEventDispatcher::clearCurrentThreadCocoaEventDispatcherInterruptFlag();
...
...     auto result = [m_panel runModal];
...     m_helper->panelClosed(result);
...
...     // Wake up the event dispatcher so it can check whether the
...     // current event loop should continue spinning or not.
...     QCoreApplication::eventDispatcher()->wakeUp();
... }
... """
This code is part of a Qt application that is using Cocoa on macOS. It appears to be a method for running a modal panel, which means the user cannot interact with other parts of the application until the
panel is closed.

The method starts by checking if an `NSApp` object is available. If it's not, then the method returns without doing anything. This suggests that the app may have been interrupted or paused for some reason,
and the modal panel cannot be shown.

Next, the method creates a new Cocoa event dispatcher using `QMacAutoReleasePool`. This is necessary because Cocoa uses automatic reference counting (ARC) to manage memory, and it can cause issues if ARC is
not used correctly. The `QMacAutoReleasePool` object ensures that ARC is properly managed during the execution of the method.

The method then calls `qApp->processEvents(QEventLoop::ExcludeUserInputEvents | QEventLoop::ExcludeSocketNotifiers)` to process any pending events in the event loop. This is important because if the event
dispatcher has been interrupted, it needs to do cleanup of modal sessions before showing the native dialog.

The method then sets a flag to ensure that the current thread's Cocoa event dispatcher does not interrupt the `runModal` call below. This is necessary to prevent the app from being closed during the cleanup
process.

Finally, the method calls `[m_panel runModal]` to show the native modal dialog, and passes the result of the dialog to `m_helper->panelClosed(result)`. The method then wakes up the event dispatcher using
`QCoreApplication::eventDispatcher()->wakeUp()`, which allows the event loop to continue running normally.

Overall, this code is showing a native modal panel and waiting for the user to close it before continuing with other parts of the application.

>>>

❯ ollama run gemma2                                                                                                                                                                                                1m
>>> """
... What does this code do?
... -(void)runApplicationModalPanel
... {
...     // Note: If NSApp is not running (which is the case if e.g a top-most
...     // QEventLoop has been interrupted, and the second-most event loop has not
...     // yet been reactivated (regardless if [NSApp run] is still on the stack)),
...     // showing a native modal dialog will fail.
...     if (!m_helper)
...         return;
...
...     QMacAutoReleasePool pool;
...
...     // Call processEvents in case the event dispatcher has been interrupted, and needs to do
...     // cleanup of modal sessions. Do this before showing the native dialog, otherwise it will
...     // close down during the cleanup.
...     qApp->processEvents(QEventLoop::ExcludeUserInputEvents | QEventLoop::ExcludeSocketNotifiers);
...
...     // Make sure we don't interrupt the runModal call below.
...     QCocoaEventDispatcher::clearCurrentThreadCocoaEventDispatcherInterruptFlag();
...
...     auto result = [m_panel runModal];
...     m_helper->panelClosed(result);
...
...     // Wake up the event dispatcher so it can check whether the
...     // current event loop should continue spinning or not.
...     QCoreApplication::eventDispatcher()->wakeUp();
... }
... """
This C++ code snippet, likely part of a Qt application using macOS, handles the display and interaction with a modal panel (presumably a custom UI element).

Here's a breakdown:

1. **Safety Check:** The function starts by checking if `m_helper` is valid. This helper object seems essential for interacting with the modal panel, so if it's not available, the function immediately
returns, preventing potential errors.
2. **Resource Management:** A `QMacAutoReleasePool pool;` is created. This ensures proper memory management within the context of showing the modal panel.

3. **Event Handling:** The code calls `qApp->processEvents(QEventLoop::ExcludeUserInputEvents | QEventLoop::ExcludeSocketNotifiers);`. This processes any pending events in the application's event loop, but
specifically excludes user input and socket notifications. This is crucial to prevent interruptions during the modal dialog display.
4. **Preventing Interruptions:**  `QCocoaEventDispatcher::clearCurrentThreadCocoaEventDispatcherInterruptFlag();` is called to ensure that the modal panel's `runModal` call isn't interrupted by any background
event processing.

5. **Displaying the Modal Panel:** The core functionality lies in these lines:
   - `auto result = [m_panel runModal];`:  This line displays the modal panel using `runModal`. It blocks the execution of the current thread until the user interacts with and closes the panel. The result of
the panel's interaction (e.g., a button click) is captured in the `result` variable.
   - `m_helper->panelClosed(result);`:  The result of the modal panel interaction is passed to the `m_helper` object, presumably for further processing or handling within the application.

6. **Waking Up Event Dispatcher:** Finally, `QCoreApplication::eventDispatcher()->wakeUp();` wakes up the event dispatcher. This allows it to check for any new events and resume its regular operation after
the modal panel has been closed.

**In Summary:** This code demonstrates how to display a modal panel in a Qt application on macOS while ensuring proper resource management, event handling, and synchronization with the main application thread.

>>>

[yaroslavyaroslav]

I agree that the answer ollama provides through the plugin is a way flawed, but I have not much clues why is that.

I mean the most thing plugin does is just getting your input (in a convenient way) and sending it to whatever server you gave to it. Depending on the flawed answer that is still mentions the method presented in request it accomplishes that part more or less well.

The other thing what it does is: taking response from the server and printing out in either output panel or tab. This part seems accomplished well too, I mean if it's not there's just no output provided at all.

In addition to that I see that text looks like model is "talking shit", I mean on whatever input prompt unflawed model shouldn't answer with such a bad text. So another thing that I can suggest you to try is to setup complete model config explicitly on a plugin side. Also I suggest you to check what system prompt is ollama using when you ran it as cli and paste it here as assistant_role. The better thing would be to make it the exact copy of the config ollama uses (dunno how to extract it from it).

{   
    "name": "Example",

    "prompt_mode": "panel",

    "chat_model": "llama3.1",

    "assistant_role": "You are a senior code assistant",

    "url": "http://localhost:11434",

    "token": "sk-my-dummy-token",

    "temperature": 1,

    "max_tokens": 1048,

    "top_p": 1,

    "frequency_penalty": 0,

    "presence_penalty": 0,
},

Yet another thing to check, whether the response mentioned in ollama page would return correct response by being sent directly https://github.com/ollama/ollama#rest-api

[kodecraft]

Hi Yuroslav, thanks for this plugin!

I experienced something similar to what Torarnv described here in this issue.

I tried the query:

"create sublime text plugin that takes selected text and convert it by applying base64encoding and replacing selected text with the conversion"

The qwen2 LLM gave reasonable answers when I queried "Ollama directly" but returned 'funky' answers when queried through the plugin.

My settings below:

{
    "url": "http://localhost:11434",
    "token": "sk-your-token",
    "status_hint": [
        "name",
        "prompt_mode",
        "chat_model"
    ],
    "assistants": [
        {
            "name": "qwen2",
            "chat_model": "qwen2:1.5b",
            "assistant_role": "You are a senior python and sublime text 4 code assistant",
            "prompt_mode": "panel",
            "temperature": 1,
            "max_tokens": 1048,
            "top_p": 1,
            "frequency_penalty": 0,
            "presence_penalty": 0,
        }
    ]
}

[yaroslavyaroslav]

@kodecraft @torarnv I've checked the issue on my side and can confirm models talking shit being called through ollama for me too, while being fine when called by ollama run. Also I've checked it with curl command on the very same server instance which provided quite normal response to ollama run and it talked shit either. Thus I can conclude that there's a problem on ollama's side unfortunately. Possibly it's somehow related to gateway to which request is sent.

But anyway there's not much I can do but create an issue in ollama repo about this (my shot is that they forgot to update smth for the gateway that my plugin is using and thus it's kinda broken now). https://github.com/ollama/ollama/issues/6492

upd: Till the issue got resolved I can suggest you the workaround to use llama.cpp directly. It's the backend that ollama is using under the hood and it has server capabilities. It indeed requires a lot more effort to be setup, but it should work properly. At least last time I've used local model I used it leveraged by it.

[torarnv]

Thanks for digging in @yaroslavyaroslav ! <3

[yaroslavyaroslav]

And I got the solution folks. Ollama somewhat doubled temperature value for the particular endpoint that this plugin's using. So to overcome this you should divide actual temp value by 2 instead. Meaning the working config would be:

{
    "url": "http://localhost:11434",
    "token": "sk-your-token",
    "status_hint": [
        "name",
        "prompt_mode",
        "chat_model"
    ],
    "assistants": [
        {
            "name": "qwen2",
            "chat_model": "qwen2:1.5b",
            "assistant_role": "You are a senior python and sublime text 4 code assistant",
            "prompt_mode": "panel",
            "temperature": 0.5, // check out this line. It becomes 1 on ollama's side.
            "max_tokens": 1048,
            "top_p": 1,
            "frequency_penalty": 0, // this one x2 too
            "presence_penalty": 0, // this one x2 too
        }
    ]
}

I've checked it with that temperature and qwen returned me quite valid answer through the plugin a way better one than it returned before. The case is closed.

Also I suggest you to follow that issue in ollama's repo, I'm really curious why they doing this multiplication for that endpoint and will try to pursue them to disable it, to make usage of ollama more straightforward.

[torarnv]

Thanks @yaroslavyaroslav!!

[yaroslavyaroslav]

@torarnv @kodecraft share or tweet about the plugin I'd really appreciate that 🤝🏻

[yaroslavyaroslav]

@ yall ollama accepted the pr that aligns OpenAI alike API with all the others. So as long as the new build appears you should use the same config values for it as for ordinary OpenAI backend.